About ggarrison

Interesting - I opened up a support case about this very issue but appearntly they're still researching the problem or think it's being caused by a security rule that PAN is applying. Currently being experienced when users attempt to go to www.foxnews.com or www.bing.com. Entering in the URL's without the "www." works just fine and presents a CP page for people to authenticate against (using standard block page). Traffic that is from unidentified users is supposed to be CP'ed - the block page with the underscores instead gives the computers IP as the user id and does not prompt for CP. Running 4.1.3. ... View more

Since you dont have any vlans at all (just a physical lan) and probably wont be able to change how the access network looks like my idea was something like: 1) A regular interface, for example 192.168.0.254/24 (which you add in dhcp as default gw so regular clients will use 192.168.0.254 as default gw to reach Internet or whatever and before they are let out they must use the captive portal). 2) A subinterface (or another physical interface), 192.168.0.253/??, which the ssl-vpn clients would connect to. Its the last part which im not sure if its possible to accomplish on a PA (due to ip range collissions and such). As sdarapuneni said if you enable both captive portal and ssl-vpn on the same interface then the PA will force both to be valid (meaning ssl-vpn users would still get a captive portal). Im thinking if it would be possible to trick PA into this support by using vrouter and/or dnat/snat in combination? A workaround could be if you setup something like: 1) 192.168.0.254/24 for regular clients (captive portal) on int1. 2) 10.0.0.254/24 for ssl-vpn clients on int2. Connect both to your access network and in the dhcp put up static leases based on mac address. This way a regular client will get a 192.168.0.x ip and 192.168.0.254 as default gw and your known ipad (etc) clients gets a 10.0.0.x ip and 10.0.0.254 as default gw. Because this ip "separation" isnt a true separation (they are all on the same vlan anyway) the only way for a client who gets a 10-ip to reach internet is either to auth using ssl-vpn OR go through 192.168.0.254 and use the captive portal - either way they must authenticate in order to leave your access network. Of course this doesnt fulfill any demands regarding strong auth (since you use captive portal) but your case doesnt seem to involve being 100% sure of who did what (because in order to use captive portal your access network must be secured/hardedened aswell like using protected vlan so clients cannot steal each other ip/mac addresses and such but also since if a user gets hold of another users login/pass they will use that instead of their own) but rather make it easier for your trusted clients to use your access network. ... View more