In the last week or so we’ve seen several sites start returning a HTTP 406 error when Zero Trust is enabled using the WARP client; currently our team have to disable ZTNA to get into their accounts and switch WARP off completely if they need to use the affected site for any length of time.
All of these sites were working fine for months before approximately Wednesday/Thursday last week, we haven’t made any changes on our side.
After an initial investigation I think this might be related to redirects as the team are using Google Workspace for authentication and the failure is in the redirect to the landing page after the successful auth handshake.
I’ve attempted switching off all blocking rules (malware etc) and also adding specific bypass/allow rules to Zero Trust for DNS, Network and HTTP level independently and together - no joy.
Thanks, I’ve run a test and it doesn’t look to be blocking the Firefox auth calls. On Safari I think I caught some requests getting a 406 response but it didn’t block the login.
Unfortunately, while I would love to use Firefox, we need to use Chrome due to other apps & security controls so we can’t easily migrate the team to a new browser just for this.
I’ve just tried the following without success;
Adding the affected domain as a split tunnel for the WARP client - no good.
Cycling through Google Chrome DNS security options + switching off chrome DNS security
Google chrome via incognito
Switching off all security options in Google Chrome
It looks like the affected site is actually using Cloudflare, I’m starting to suspect this might be their firewall or WAF. I’m not that familiar with the Cloudflare CDN of WAF, but would it have rules which identify using Google Chrome + Cloudflare ZTNA as a security risk factor?