Specific sites are not blocked in Chrome when behind IPsec

Currently, when behind an IPsec tunnel, certain sites are not blocked in Chrome despite the proper URL filtering rules in place. QUIC protocol is also blocked under firewall control policy. This is only a problem when using Chrome. I verified that these same URL filtering rules work properly on Firefox and Edge. Two of the sites that I am seeing this with is Pandora.com and music.apple.com.

The only resolution is to enable SSL Inspection for those sites. At that point I had cleared all of Chromes data and then reauthenticated. After that, Chrome was blocking both of those sites. I shouldn’t need SSL inspection for these rules to work. Has anyone encountered this and found a fix?

1 Like

Actually you would need SSL inspection to see into these as both Pandora and APPLE are very strict on enforcing encryption on the client, auth and payload — to the point that by default in the Zscaler Tenants - there are entries for Default TLS-bypasses for known software level signed apps for multiple vendors that you can not really ever do full SSL decryption and inspection ------ however they will allow some other software areas of the products to provide for SSL de-cryption and inspection but only to known and trusted 3rd party signed CA s ----- if you are not using the default Zscaler root certs for SSL inspection I would recommend ensuring your ROOTCAs are supplied to the device’s to enable those features on managed devices via GPO policies, Software mgmt and device configuration systems, or MDMs

A solution has been found for this issue. First to review the issue at hand, when behind an IPsec tunnel and using location based URL filtering rules. Certain sites are not blocked (pandora.com, music.apple.com) within Google Chrome unless SSL inspection is enabled. The same effect was not observed in MS edge or Firefox. Both of these browsers had blocked Pandora with no SSL inspection.

There are 2 steps to take in order to block these sites in Chrome WITHOUT SSL inspection.

  1. Update your custom URLs as wildcards. In my case, this was changing pandora.com to .pandora.com within my custom URL category.
    MicrosoftTeams-image (2)

  2. Enable surrogate IP and change the duration to 8 hours. To do this, go to Administration > Location Management. From here, hit edit on your location or sub-location

Next you will want to scroll down and enable IP surrogate and set your idle time to disassociation to 8 hours.

This should now allow Chrome to block these sites without needing SSL inspection. In certain deployments from known locations, you can enable the Zscaler surrogate IP service to map a user to a private IP address so it applies the user’s policies, instead of the location’s policies, to traffic that it cannot authenticate, which includes:

  1. Applications that do not support cookies, such as Google Earth and Skydrive
  2. HTTPS transactions that are not decrypted
  3. Transactions that use unknown user agents

If a user browses the internet from multiple private IP addresses, the surrogate IP service maps all the private IP addresses to the user. The service also associates the transactions with the user in the logs.

Pandora could be 1 of them.

1 Like

Also for those struggling with this, we found the following article Configuring Policies for Unauthenticated Traffic | Zscaler. For our unauthenticated traffic this seemed to do the trick. Administration, Advanced Settings, “Enable Policy for Unauthenticated Traffic”