I have a problem running Microsoft Teams on MacOS with twingate. Microsoft Teams doesn’t play nice with split tunnels, sending traffic down any adapter it can, even if it isn’t supposed to. I had hoped twingate would handle this, but it doesn’t. When I connect to Twingate, my Teams client stops working (status updates don’t work, messages won’t send (or are delayed)).
Does anyone else have this problem or know the solution?
Hi @OVJB,
It is possible that Microsoft Teams is communicating to several domains on the backend so you might need to add all applicable domains it uses as Resources for the Twingate Client to intercept the right traffic. Do you have a list of corresponding domains declared as Resources in Twingate? Could you share it?
I’d like all this traffic to remain outside the tunnel - I don’t need Teams traffic getting routed through my corporate network. There is an article from Microsoft on this, but I don’t know how to do this with twingate. https://learn.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-vpn-implement-split-tunnel?view=o365-worldwide#howto-guides-for-common-vpn-platforms
The issue is that Teams will send traffic down the tunnel even when told not to. Here is a thread from another VPN vendor about this (there are others posting about this if you look around). Traffic not honouring the split tunnel configurati... - Pulse Secure Community
The solution seems to be to DENY this traffic from the tunnel - knowing it will come across even if the route table says not to. I’m wondering if this is possible with twingate…
Thanks for the help!
It would seem like an exclude rule would work here, but you are right Twingate doesn’t have exclude rules.
Instead we rely only including those resources you want to have go through our tunnel.
It seems like those resources names include a set of IPs that you could exclude if we allowed it.
Is that correct?
So your last statement makes me think that you could add the Teams’ IPs and block all TCP and UDP traffic. Normally I would expect that to mean the connection will just be denied, and I think it will. You mention if we DENY that traffic Teams will figure out another route. I hope that is the case, but I am doubtful. I think what you mean there is to exclude IPs that are being included.
Is there any way to be more specific in the include rules thereby not including the IPs we do not want? Can you share what you have as resources now that are related to Teams?
Let’s keep at it. I suspect there is something we can do if we dig in somewhat.
This ended up being an issue with my local antivirus - Symantec Antivirus. While the Teams issue still seems to be a problem, I’ve switched to another AV and it is working fine.
2 Likes