ZAPP On - Captive Portal Detection
The forwarding mechanism like GRE/IPSec Tunnel to Zscaler with Zapp On will be the best approach if we doesn’t default route to the gateway. Few DNS mapping might be required at local DNS server like pac server - pac.zscaler.net, Mobile.zscaler.net, clients4.google.com, Mobilesupport.zscaler.com, d32a6ru7mhaq0c.cloudfront.net, ocsp.digicert.com, crl3.digicert.com, crl4.digicert.com etc. Most importantly the global ZEN IPs will be advertised inside the infra.
The captive portal detection is complex, but the requirements that we check are very basic:
· First, ZAPP attempt to connect to http://clients4.google.com/generate_204 - This page is guaranteed to return a 204-response code. Typically, a captive portal will return 302, but some of them return a 200 and re-write the page contents. Essentially if we get anything but a 204, we trigger captive portal.
· Second, some captive portals know this and will return a 204 with their own page contents, so we do one additional check, which is to download the cloud default pac file and try to parse it. If it’s not parsable it generally means they are replacing the page contents with their own page.
So, in summary captive portal will trigger if:
1. Do we not get a 204-response code from the first test?
2. Do we get a 204, but the default pac file is not actually a pac file.
If you can make these conditions match ok then you should never see Captive Portal.