Wireless Access

Hi All,

 

I've got an issue i'm trying to work around and i've hit a wall so i though i'd try the brains trust.

 

We have a client who wishes to utlise Captive Portal authentication to allow users onto their "Guest" network. This captive portal uses an embedded credential to provide an " I Accept" style login to the controller. This all works ok.

 

The captive portal page is hosted on an external web server and the appropriate firewall pinhole in the captiveportal policy is done and working.

 

Once the user is authenticated, they are allowed to directly connect to local resources (i.e. public "walled garden" style setup) but if they want to access the internet they need to utlise a proxy server with authentication.

 

For most clients this works ok as the wpad / pac file discovery is permitted by the ACL. Windows and Apple devices work fine.

 

The issue we have is Android. As we know Android doesn't support auto-discovery of pac file configuration very well if at all so the only option is to explicitly specify the proxy server address in the android network profile.

 

This works great AFTER we have authenticated.

 

If the user sets the proxy and then disconnects, when they reconnect, the browser get stuck in a loop and redirects into itself (CP Page > Proxy > CP Page > Proxy etc).

 

The proxy uses port 8080 and i'm using the defalt captiveportal policy which does DST-NAT traffic from 8080 to 8088 as per the user guide.

 

I'm thinking that this isn't working because we have an external CP page but not quite sure where to go from here.

 

Anybody able to offer any suggestions?

 

We're running 6.3.x and have PEF licence etc.

 

Scott

 

Hi scott,

The problem is that you are trying to force a solution designed for corporate owned and managed devices onto guest devices, which you have no control over.

One thing that can be done, instead of getting the users to explicitly set the proxy settings, you can destination NAT all outbound port 80 traffic to the proxy ip and port (in your post authentication role).

This only works with port 80 traffic, port 443 will fail if you try to destination NAT it to a proxy.

The other solution is to use some sort of transparent proxy, WCCP, NGFW, or something like OpenDNS if your main interest is URL filtering.

Forcing guest users to authenticate with explicit proxies is just asking for trouble.

Hope this helps somewhat


Chris

Hi Chris,

 

Thanks for your response, i agree this solution is not the best. Despite my recommendations the customer has chosen to continue to use their explicit proxy configuration.

 

I'm trying to find a possible work around however i suspect this will just be too hard to implement.

 

Scott

A possible solution is to host the logon page back on the controller. This *will* trap all HTTP GET requests sent from the client, no matter how the client is configured. The welcome page can remain externally hosted. Of course, you will pay for this with a higher CPU load when many users try to logon all at once...

Have just had confirmation from the TAC that the proxy redirection that is built into the standard captive portal policy is only effective with a locally hosted login page.

 

The external page will not work when a proxy is explicitly defined.

 

Scott