IPSec Tunnel to Zscaler with Zapp On - Captive Portal Detected Disabling


(Alex Fray) #1


I am currently trialing SD-WAN which will allow branch sites to use their local Internet bandwidth to connect to Zscaler as the default route. I have resilient IPsec tunnels configured to London and Amsterdam which are connected.

I have a laptop heavy estate which is Windows 10 using Zapp 1.4.0 to enable protection off-network, VPN (PAN Global Protect) and on-network. Zapp is configured for tunnel with local proxy mode for each network profile as was best practice. Zapp is on on-network because it is a no-default route environment so clients are routed to specific Zscaler ZEN ranges and NAT’d behind the DC firewall. ADFS is used as authentication.

When i connect my laptop to the SD-WAN site, Zapp prompts that a Captive Portal has been detected and disables the app. When i try and access the Internet i can only get to certain URLs and my traffic appears in the logs as the site IP range not the user. I was hoping that by leaving Zapp on on-trusted network it would authenticate the user traffic transparently and effectively allow me to do a tunnel-within-a-tunnel. Any ideas why i am getting the captive portal issue?


  • Tried turning off authentication at the SD-WAN site, made no difference
  • Turning Zapp off on-network is not an option as it will break existing users.
  • Adding users to a group is not scalable as the users will float between non SD-WAN and SD-WAN sites.
  • Tried upgrading my Zapp client to 1.4.2 to see if it was a bug, no change.
  • I can’t think of any logic for a forwarding statement as there is no local DNS so DNS server, DNS domain and host/IP resolution will be the same at any site.

Any ideas on how to resolve this or a better way to achieve this with the constraints?


(Alex Fray) #2

I might have resolved this. Testing so far seems to indicate I am in a tunnel-within-a-tunnel.

Location - authentication and ssl enabled
URL filtering rule - allow traffic from the branch site

Instantly the zapp connected on the laptop at the SD WAN site. What I’m unsure of is why this made a difference as there was a URL rule allowing user traffic. Also I thought captive portal detection was based on a 302 redirect, rewrite or a dns method of to force the traffic to the portal although there is no captive portal so was the zapp get confused? And why would adding a url filtering rule resolve this?

(David Creedy) #3

Hi Alex,

The captive portal detection is complex, but the requirements that we check are very basic:

First, we 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 yes, 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. In addition, 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.

(Alex Fray) #4

Thanks for the information David, that is really useful information.

I’ve gone back through the Zscaler logs and can see traffic from the SD-WAN site to http://clients4.google.com/generate_204 being blocked from user noauth-bypassurl which explains the captive portal detection issue and why introducing a new URL Filtering rule to allow traffic from the location (which allowed unauthenticated traffic rather than just user) resolved the issue. I didn’t see any traffic to the pac.myzscalercloud in the time frame though but i’m happy with the explanation.

thanks, and nice to meet you at Zenith live.