I am pretty new to Zscaler, I have completed all the administrator and professional training other than the practical lab. I just started a new job in an environment that seems to have daily issues with Zscaler. They have been using Zscaler since last November.
We are having a lot of issues with o365 applications and when I look at logs while from a quick view it doesn’t seem anything is being blocked, I can point out blocks of sometimes 2-6 events of a specific user attempting to login.microsoftonline.com in the same second. Has anyone seen and resolved this before? It isn’t just that specific request I see, users in our environment are generally producing a little over half of their logs as bandwidth loss to Microsoft services every day as far back as I have gone.
We have all the o365 default configurations in place that come with enabling One Click in Administration > Advanced Settings. I have read through several articles on here dating back to 2017 covering issues with o365. I have seen disable loopback restriction in the app profile, set the MTU to 1370 in the forwarding profile, and I have read that people are still coming to the conclusions of SSL Bypassing everything in regards to Microsoft o365 applications/services? I don’t understand the reasoning in going zero-trust to just punch a bunch of holes in the service with SSL Bypasses…
My main reason for this post is I want to know if everyone that came to the conclusion of bypass all went through the configurations available in the administrator portal? Cloud applications status, Tenant Profiles, SaaS Application Tenants, and Partnership Integrations (specifically Microsoft Cloud App Security) all seem like configurations should be in place here specific to our environments.
I am in an environment that seems to have really just taken the deployment configurations and ran with it, and there is a process to making changes here. So before I motion to change I am just really trying to hone in on what exactly needs to be changed. Any input would be great, and I am willing to answer any questions.
Relevant info - ZIA - ZCC - tunnel2.0 - PAC file
Hi Ryan, please email me with your company name and contact details. I would like to get you engaged with your RSM and SE to help resolve these issues.
I can say that I do not have this experience, but I am also not using One-Click.
Per my client’s security posture, only a few apps in 365 are permitted from this enclave, so I have everything that is permitted in a dedicated URL category. Not a fun way to manage it, but it is what it is. The only thing I bypass for SSL inspection is Teams because of its real-time nature.
Thanks for your reply. I will keep this in mind in my support session this afternoon. For one click, it is hard to identify if it is performing as intended as it explicitly labels some of the applications we are having issues with in url & cloud app control. And while some of the application transactions complete, the same application will fail larger transactions without reflecting anything negative via the logs.
The Office 365 one-click setting is based on Microsoft’s guidance that the traffic should not be TLS inspected. Additionally, plenty of sites use certificate pinning, or other non decryptable ciphers that must be bypassed.
In addition to the contact being offered up previously, opening a support ticket would be good too.
I see tunnel 2.0 in your info. Is this traffic being put through a GRE or IPSec tunnel?
Try DTLS and TLS. Try it with a tunnel 1.0 profile to see how it behaves. Try using a different Zscaler datacenter to see if that has any impact in your testing.
I see you tried a lower MTU. I would go even lower as a test or look at pcaps to see the quality of the traffic. That login packet has a do not fragment bit set. If it is fragmented it will be dropped. Other things can happen too like incorrectly mapped GEO information for IPs and Microsoft services hosted in regions that are not near a customer, etc. I have seen this happen where the DNS at MSFT was resolving to a DC in Europe from the US. Definitely have support take a look.
We are a heavy O365 shop & long time Zscaler customer. We don’t see the issues you describe. We are using the O365 one-click but we also had custom rules in play before the one click option even existed to that may play a factor. We have a mix of site tunnels, & road warriors using ZCC .
We are not using tunnel 2.0. If there are specific domains you want to know if we bypass from SSL, I’m happy to check, feel free to PM me.
The company I work for ‘did’ have much of the same issues you’re describing when we were running Tunnel 1.0, but when we migrated over to 2.0 they all cleared up.
Since you’re already on 2.0 I am thinking there’s some configuration issue somewhere.
I think I am getting closer to resolving this issue. We are in tunnel, Z-Tunnel2.0 mode and I think there is a conflict between app PAC file and the forwarding profile PAC that is assigned to the app profile. I think tunnel with a local proxy mode is needed to enforce the forwarding profile - system proxy settings with a pac.
Tunnel w/ local proxy should massively reduce the amount of call outs we are getting on our users from their applications to our idP.
An odd occurrence that is happening to our users is they will either resolve in different geographic locations than they are in or stop communication with the DC specified in PAC file and in stead of falling back to the next DC in the PAC they will take what is appearing to be different routes to the nearest ZIA public service edge.
I would prefer if a moderator does not shut this thread down until I update with what has solved this. That should be beneficial to any users that stumble upon this document when diving into their logs and seeing Microsoft traffic. Any further feedback, is greatly appreciated.