Teams has lots of IP addresses, did you add all the IP’s or just any on firewall. its so frustrating.
We have all recommended IPs for TEAMs in Firewall for LAN subnets. Its now stable after doing htis. Anyways, traffic is now not going via Zscaler, so have stability.But TEAMs has many issues in combination with Zscaler.
I’m curious, has anyone fully found a fix for this issue? We are in a similar situation, almost identical using Zscaler 1.0, with global protect. This issue only happens on specific devices, but we have not been able to find exactly what devices are unique. Only happens when the user is connected to VPN. We split tunnel out Teams and office FQDN’s, but Also send these FQDN’s down zscaler (They are not excluded). Zscaler FQDN’s are split tunneled as well, so all traffic egressing to Zscaler should follow this route and not down our global protect tunnel.
However, we are noticing in certain occasions (deployed to roughly 30,000 users for ZCC) 3-5 times per day we get another random issue with a new user. The only fix at the moment is to entirely remove zscaler from the machine, and restart global protect. We’ve also noticed that sometimes the exclusion of outlook.office365.com fixes the issue, but only after zscaler and global protect are restarted, and only for outlook. No fixes for teams.
We are at a loss! Any help would be greatly appreciated. We are using ZCC version 18.104.22.168
PS: We’re also investigating potential links to 32bit office suite, and Dell laptops. As these are the only thing we’ve been able to find that is unique about the devices.
Happy to provide feedback. Thank you,
I just wanted to come back and give an update. I feel I owe it to other customers, as well as to Zscaler. A couple of months ago, we worked with Zscaler and switched everyone in our testing pool over to Tunnel 2.0 and the problems we were experiencing with ZCC and O365/M365 authentication when connected to VPN had completely gone away. My recommendation is for all to make the switch to Tunnel 2.0 wherever possible. Hopefully, this helps by re-affirming what others have already said.
Thank you so much for taking the time to update the status! If that was the solution would you mind marking the best answer if you can? I believe Constantin mentioned that a while back but not sure if that was the most relevant given the timeframe of this post.
We are also moving to Tunnel 2.0 but have chosen to look at bypassing Teams using the Application Bypass in the App Profile.
Would you mind potentially providing the zscaler resource you used to troubleshoot this?
Though Zscaler 2.0 may have fixed it for the majority of users in this thread, it’s simply not possible for our organization at the time being, unfortunately. So hearing that teams will just be broken on tunnel 1.0 is extremely worrisome, as it’s also what we have been finding in our testing. Of our roughly 7,500 users that use VPN to connect, 300-400 are having the problems noted in this article. We still cannot fully find the relationship between the two, but know that it only happens when on Global protect VPN, and Zscaler 1.0.
Any guidance as to what you have already tried for 1.0 with any success would be helpful, or even a root cause if it has been found.
Thank you so much for your response! @Ben_Garrison your input would also be incredibly helpful.
Is this considered resolved if the issues still persist in Tunnel 1.0?
I can look to find someone here that might be able to chime in. It appears that the solution for the original question was to convert to Tunnel 2.0. So for that use case and purpose of the post, that is a viable solution so it would be “solved”.
To your point though, we still need to dive into functionality with Tunnel 1.0 as you mentioned, not everyone can migrate to Tunnel 2.0. If this is a wide scale impact, I would think that this would be a known issue with our teams. Let me shake some trees and see what comes of it
So do you want me to mark as resolved or not. I agree with others, it does not resolve the issue with Tunnel 1.0 so for those who cannot avoid Tunnel 1.0, this will continue to be a problem. Constantin was the first person who mentioned switching to Tunnel 2.0 as a fix, back in December 2020. So that would be the one I would mark as a solution.
I used our Account SE to help walk through a Tunnel 2.0 test just pointing at my account, as well as the account of another user I knew had the problem regularly. Once I was sure the problem was resolved, I broadened the scope. That would be my recommendation.
By the way, I can also update this topic. We have found a way to make the Microsoft Login Services and therefore O365, work with Z-Tunnel 2.0 DTLS.
We adjustedt the MTU size to 1370, which increased the performance while still making sure every service is working.
Here is the orginal article: ZTunnel 2.0, DTLS/TLS, MTU - Client Connector - Zenith (zscaler.com)
No worries, if you don’t feel it’s resolved then by all means, let’s leave it as is. I reached out to some internal teams on this topic. I will monitor and look to update as soon as I get more information.
Challenge is that I cannot personally repo. Which makes it difficult to share the pain ha.
After much thought, I have marked the solution with Constantin’s original solution of switching to Z-Tunnel 2 (ZT2). Even though this problem persists with Z-Tunnel 1 (ZT1), the only solution appears to be to move away from ZT1. That sentiment was not only echo’d by Support, but also by our Account SE on several occasions. It is the only thing that has worked for us. Rather than have people move through 45 replies to get to this conclusion, the solution is now in a handy place.
For those who want to persist on finding a solution for ZT1, my suggestion would be to fire up a new topic specific to ZT1 and simultaneously open a support ticket and engage your account SE. This is a frustrating problem, and hopefully you have some luck where I didn’t in resolving this with ZT1. If possible though, you might fire up a ZTunnel 2 App Profile and just migrate people when/if they experience the problem.
Robling, I am curious, as I have ran into similar issues and want to see if within the Application Profile > radio button for “Disable Loopback Restriction” is configured to be enabled or not.
The issue I had was around the restriction from Microsoft to not allow UWP programs to talk to the loopback interface. Enabling “disable loopback restriction” fixed my problem.
If you have it disabled today, I would attempt to test it out.
@Mgilliland we no longer experience the issue as we migrated our entire user pool over to Tunnel 2.0. In answer to your question, our Tunnel 2.0 profile has “disable loopback restriction” not enabled.
A post was split to a new topic: O365 Connection issues using Tunnel 1.0
That would be very good! Let’s just make sure that we specify that we know switching to Tunnel 2.0 is an option (linking this thread) but that we want to try and find a solution for use cases that cannot switch to Tunnel 2.0!
I split the post to a new topic for this in regards to Tunnel 1.0