Forum Discussion
Split Tunnel Implemented. But, some of the traffic still going via VPN
Hi,
I am new to Microsoft Teams and I am wondering why some of Microsoft Teams traffic and going straight to the internet and some are going via VPN. We use Cisco AnyConnect and has configured dynamic split tunnel. What, I noticed is that traffic flow for Audio Calling, Video Calling, Sharing and Meetings are all going via VPN. But, the rest are going straight to the internet. Is this a normal behavior? I thought, that once we implemented Split tunnel all Microsoft Teams traffic are going straight to internet. Thank you.
note: We added all Microsoft Teams and Skype for Business Online addresses in the dynamic exclusion list
When you say
note: We added all Microsoft Teams and Skype for Business Online addresses in the dynamic exclusion list
what exactly do you mean, the DNS entries or the IP addresses? For media traffic it should be best to simply exclude UDP 3478-3481 so it always goes direct. That's the Optimise category that needs to avoid corporate networks.
As already pointed out, Teams client can't choose, it's all up to how the cisco VPN interacts with the clients routing table for the addresses that Teams is accessing.
- Hi Steven,
Thank you for reply. But, i have a follow up question for you and the community
We jut added the DNS entries.
Sorry, this a dumb question, I guess when you say "For media traffic it should be best to simply exclude UDP 3478-3481 so it always goes direct" You mean block those ports in ASA, right? May I know what are UDP ports "3478-3481" is used for? When I did a Wireshark trace the media is using UDP ports 50000-50019 range for Audio, UDP ports 50020-50039 range for Video and UDP ports 50040-50059 range for screen sharing. Thank you.DNS isn't sufficient, media traffic goes straight to IP addresses and doesn't make use of DNS. Look at Rule 11 in the Microsoft list Office 365 URLs and IP address ranges - Microsoft 365 Enterprise | Microsoft Docs
UDP 3478-3481 is the destination ports used for Teams media, 50,000 - 50,059 are source ports if you choose to configure Team to force those. It's generally not the case that you use source in a VPN/firewall.
You do need to review the Microsoft list very carefully, and for Teams to work fully you need to consider all the different sections (Teams relies on Exchange, SharePoint and the common services).
- Hi Andres and Ed,
Yes, we did try blocking the traffic in ASA and it forces Teams Media to go straight to Microsoft. But, in this scenario we are asking Teams to select the route instead of your network. Also, will this cause an issue as there is an unnecessary delay during the setup time. Is Teams designed to do this (routing decision) as well?
Another question: Not sure if this is relevant. Looking at the browser network activity (by pressing f12 in Edge Browser). I noticed these lines.
https://statics.teams.cdn.office.net/hashed/lazy-ng1-mod-calling-bot-service.min-409f922.js
https://statics.teams.cdn.office.net/hashed/Audio/Teams_Call_Ringing
https://statics.teams.cdn.office.net/hashed/Audio/Teams_Call_Ended
"statics.teams.cdn.office.net" is not included on our dynamic exclusion test as this is not on the MS Teams list. Also
pinging "statics.teams.microsoft.com" resolves to "s-0005.s-msedge.net [52.113.194.132]"
pinging "statics.teams.cdn.office.net" resolves to "s-0005.s-dc-msedge.net [52.113.195.132]"- Hello Vicente
*.cdn.office.net is treated as "Default"
"Default endpoints represent Office 365 services and dependencies that do not require any optimization, and can be treated by customer networks as normal Internet bound traffic."
I do not know about the internals of Teams making this routing decision but I can guess, that was probably included in the design- The CDN links are a good example of why everything doesn't have to be optimized. The CDN (Content Delivery Network) is responsible for things such as updating Teams. This is not time critical traffic and as such, nothing special needs to be done about it. It's okay if it is even a little slower than web browser traffic as it is an asynchronous download in the background.
Compare this against the media traffic which has to be optimized to provide suitable path during a call.
Teams doesn't really make a decision on where the data goes, That's DNSs job. Teams looks up the endpoint and starts sending traffic to it.
Now, if for some reason the other end doesn't respond, Teams may back down another protocol to get the data through. For instance, Media data wants to go UDP, but if it can't, it will switch to TCP and even HTTPS:.
Try using the tool at Microsoft 365 network connectivity test tool - Microsoft 365 Enterprise | Microsoft Docs and do this from multiple locations using multiple computers and both domain joined and non-domain joined machines with VPN on and off. I think you find it enlightening.
- Hello,
Is the traffic that you are seeing going still thru VPN categorized as Allow here?
https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide
also
"Signaling traffic is performed over HTTPS and isn't as latency sensitive as the media traffic and is marked as Allow in the URL/IP data and thus can safely be routed through the VPN client if desired."
"In certain scenarios, often unrelated to Teams client configuration, media traffic still traverses the VPN tunnel even with the correct routes in place. If you encounter this scenario, then using a firewall rule to block the Teams IP subnets or ports from using the VPN should suffice."
https://docs.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-vpn-securing-teams?view=o365-worldwide- In the first link that Andrew sent it the listing of the ports and traffic. There are categories like Optimize Required, Allow Required, etc. The article at https://docs.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-network-connectivity-principles?view=o365-worldwide#new-office-365-endpoint-categories says what you need to do for each of them.
So basic answer is yes, they can be split. But Microsoft recommends full bypass of any VPN solutions. And to meet in the middle, at least optmized required should be bypassing the VPN.
VPN normally encrypt the data, slowing it down. The generally take the longest route to a Microsoft Data Center., and by routing most of the traffic through a security monitored VPN, the security system really can't do much about it anyway.
And it is important that the workstation receive a DNS response based upon it's location, so that it can find through geo-based DNS, the closest location.
