Microsoft recommends that Teams media traffic bypasses (or split-tunnels) VPNs. There are several reasons for this, so lets walk through the impact and some of the concerns that I’ve heard from customers.

Wonky Paths

The best path for your Teams media traffic is the shortest path possible. That could be directly to the other endpoint for 2 party calls, or it could be to the Teams cloud. VPNs interfere with this direct path. Consider a user who’s in LA, VPNd through New York. That’s an extra cross-continent trip, assuming that the traffic does egress to the Internet directly in New York and not go somewhere else first (I’ve seen stranger things!). If they’re placing a PSTN call to a local number, that traffic now needs to come across the continent.

If you’re travelling internationally and are connected via VPN, this path is even worse. If our user travels to Japan, they’re now VPNd back to New York. If they’re calling a local Japan number, that traffic now needs to come back across the world a second time.

Why would a user not just drop their VPN to resolve this? I’ve seen “always-on” configurations, and the user may need the VPN up to access an internal application during the call.

Bandwidth

A user who connects directly to the Internet has their bandwidth limited by their local connection (wifi, 5G/LTE or wired ethernet) and the ISP’s relatively short connection to the Microsoft network. A VPNd user now needs to add limitations at the VPN head-end, in additional to the one or two (or more) legs across the continent/world.

Latency/Processing Delays

This used to be a much larger concern than it is with modern hardware and encryption algorithms today, but it’s not a zero impact. Simply stated, it takes time for your device and the VPN headend to encrypt and decrypt your packets.

Packet Fragmentation

We’re getting pretty low down into the weeds of ethernet here, so I’ll trying to keep things less technical. Ethernet packets have maximum sizes that can vary at different points in the network. When a packet is too large, it gets broken into smaller packets. That can result in latency from processing, but also jitter if the packets don’t arrive in a nice smooth sequence so they can be reassembled. Encrypting packets generates a new packet with a larger size, which can contribute to this fragmentation.

DNS Resolution Woes

Teams uses Anycast DNS and a host (ahem, sorry) of other DNS techniques to help a client find the best resources in the Teams cloud. VPNs can, allegedly for security reasons, insist that the endpoints get its DNS resolution from the VPN head end. That breaks the intent behind how Microsoft has architected things, and results in the Teams client connecting to what can be a suboptimal resource. Consider our user in Japan, who is trying to host Teams meetings while on the road. Not only does their VPN dump their traffic to the Internet in New York, they’re receiving New York DNS records. This impact isn’t significant when the VPN is in place anyway, but it IS significant if the VPN is being bypassed for Teams traffic but the DNS resolution is still from New York.

Inspection Rejection

One of the concerns that VPNs are supposed to address is security, and so traffic is often heavily scanned as it reaches the VPN head end. No security software out there is smart enough to decrypt Teams traffic, scan it appropriately, and then re-encrypt is. Attempts to do so result in added latency, as well as dropped/rejected traffic because the security software doesn’t understand what it’s looking at. It’s a terrible experience to try and troubleshoot security systems that only *sometimes* reject Teams traffic.

Emergency Calling and Network Topology

It’s not so much the VPN that is the issue here, this is more of a cautionary tale on Emergency Calling configuration. You must NOT include your VPN IP range(s) in your LIS/Emergency Locations. Whatever the street address of your VPN headend (and thus the VPN IP range(s)), your caller is not there.

You should, however, include your VPN ranges in your Network Topology. Network Topology is where policies are assigned to network locations based on subnet. This should be done as its own site. What do I mean by that? If your VPN head end device is in your headquarters building, your VPN IP range(s) should NOT be assigned to the “HQ” site. Instead, create a “VPN – HQ” site and assign the IP ranges there. This lets you assign different policies to the VPN users vs HQ users.

Call Quality Analytics and Diagnostics

The Call Quality Dashboard (CQD) and other places in Teams can use a “building file” that lets Teams intelligently label and filter your facilities according to network subnets. It’s much nicer to see “HQ 2nd floor” than “10.10.11.27/24”.

When you build out this file to upload, you should again separate your VPN range(s) from HQ or whatever other building hosts the head end device. Otherwise, poor quality VPN calls with affect the quality rating and reports for the HQ building. It’s misleading.

Also, you should be aware that when you VPN, Teams can no longer establish if you’re using wired or wifi connectivity. As such, any metrics from these connections are reported as wired, which can mess with your reporting. There’s no real work around here, however you can minimize the impact of this by setting up VPN range(s) as separate sites.

Security Concerns

Alright, so that’s the technical impact of using a VPN with Teams. On to layer 8 of the OSI model, aka People, Policies, & Politics! There are a number of concerns that I hear from organizations about why they must have Teams traffic use a VPN. Most, if not all, of these concerns are based on legacy network design where there’s a firmly defined edge to the network. Remote users needed to access internal resources, and thou shalt not publish internal resources openly to the Internet, so users had to VPN. That’s a fair position, but it’s also an outdated position. Teams isn’t on your orgs internal network, and security has evolved significantly from this model.

There’s no point in “scanning” Teams traffic on an internal device before sending it to the cloud. Teams traffi is encrypted. No firewall or IDP system out there can decrypt, scan, and re-encrypt Teams traffic, and no firewall or IDP system out there could properly understand that traffic anyway, and they have zero knowledge of the inner workings of the Teams cloud, so would be unable to understand what it was protecting. Teams traffic is secured by Microsoft, and your dashboard/control panel for that is provided to you by Microsoft via policies, labels, reports, etc..

Final Guidance

My final guidance from my soapbox is, bypass/split tunnel Teams from your VPN. (While you’re at it, bypass everything else M365 too). It cannot add value, it does not add security, it breaks things, it decreases media quality, and it interferes with proper management and reporting.

You can review Microsoft 365 IP Address and URL web service – Microsoft 365 Enterprise | Microsoft Learn to find the IP addresses and URLs that you can use to configure your bypass. Some security vendors will provide you with a “M365” object that implements these for you to make things easy peasy. Note that while Microsoft does their best to not make changes to this list, some changes are inevitable. Keep an eye on your M365 Notification Center for insight into future changes. And finally, Introducing cloud.microsoft: a unified domain for Microsoft 365 apps and services – Microsoft Community Hub will no doubt bring changed and ultimately simplification to this area.