Microsoft Teams over VPN: Common Network Issues

A file download can survive a hiccup. A phone call cannot. That is the core reason Teams calls over a VPN go wrong in ways that email and web pages never do. This article is a practical troubleshooting piece for anyone who gets robotic voices, frozen faces or "your network connection is poor" banners when a VPN is on, and for the IT person asked to fix it.

We stay on the network side: which conditions real-time media needs, how a VPN can break each of them, how to tell which one you have, and what to change. For general performance of the wider Microsoft 365 suite, look at the separate piece on file and mail performance; and if your problem is a different meeting app, Zoom not working with a VPN covers that case.

Why a call is not like a download

When you download a file, a lost packet is simply sent again and the file arrives a moment later. Nobody notices. When you speak into a headset, each packet carries a few dozen milliseconds of your voice, and the other end needs it right now. If it is late, it is useless and gets skipped. If many arrive late or out of order, you hear gaps or robot sounds.

Three measurements matter, and a VPN can affect all of them.

• Latency. The time a packet takes to travel one way. Commonly cited guidance for conversation is that delays above roughly 150 milliseconds one way start to feel awkward, because people talk over each other. Cloudflare's explanation of latency is a good primer.
• Jitter. The variation in latency from packet to packet. A steady 80 ms is easier on a call than a path that swings between 30 and 200 ms.
• Packet loss. The share of packets that never arrive. Real-time media tolerates a little, and then quality drops quickly. Packet loss and VPNs covers how to recognise it.

Video adds one more factor: it needs more bandwidth than audio, so it suffers first when the link is crowded. Audio needs very little, and Microsoft's documentation lists current figures if you need exact numbers.

Symptom-to-cause table

Use the symptom to narrow the cause before changing anything.

What you hear or see	Likely cause	First thing to try
Robot voice, gaps in audio, video fine	Jitter or packet loss on the path	Move closer to the router or use a cable, then retest
Everyone talks over each other	High latency	Choose a nearer VPN location
Video freezes, audio continues	Not enough bandwidth, or loss on the video stream	Turn off camera briefly to confirm; close upload-heavy apps
Call connects but nobody can hear you	Media blocked or sent the wrong way	Check microphone permissions, then test without the VPN
Call drops after 20 to 60 seconds	Tunnel timing out or media path changing	Check the VPN's reconnect behaviour and Wi-Fi roaming
Chat works, calls do not	Media traffic is blocked while web traffic passes	Ask IT about the call ports
Sound is fine until screen sharing starts	Packet size or bandwidth problem	Test lower quality share, check MTU
Fine on mobile data, bad on home Wi-Fi	Wi-Fi quality, not the VPN	Fix the Wi-Fi first

Many people jump straight to blaming the VPN. The table is meant to stop that. Home Wi-Fi is the guilty party more often than anyone expects.

UDP, TCP and why the tunnel type matters

Teams, like most real-time systems, prefers UDP for media. UDP does not wait to retransmit lost packets, which is exactly what a live conversation wants. Teams can fall back to TCP, usually over port 443, when UDP is blocked, but retransmission and ordering delays make quality worse. Microsoft documents the ports and address ranges it uses, including a UDP range for media, so check the current page rather than trust a number copied into a forum post.

A VPN interacts with this in three ways.

1. The VPN blocks or mishandles UDP. Some networks and some VPN configurations do not carry UDP media well. The call then falls back to TCP and sounds worse.
2. The VPN itself runs over TCP. If the tunnel uses TCP, a lost packet inside it triggers retransmission that delays everything behind it, including media that did not want retransmission. This is sometimes called a TCP-over-TCP problem. The difference between the two transports is explained in OpenVPN TCP vs UDP; the same logic applies to any tunnel.
3. The call is relayed. When two endpoints cannot connect directly, the call passes through a relay. Adding a VPN can change which path is available and add another long leg.

The result is a call that works but with a detour or a slower transport. If your VPN app lets you choose a transport, keep the app's default unless your provider's support tells you otherwise.

A 10-minute test to find the cause

Do this once, calmly, rather than changing settings at random during a meeting.

1. Pick a test. Use a Teams test call, or call a colleague you trust, for about two minutes each time. Note how it sounds.
2. Test on your normal network without the VPN. Only do this where policy allows and the network is trustworthy. This is the baseline.
3. Test with the VPN on, nearest location. Compare with the baseline.
4. Test with the VPN on, a far location. If it is clearly worse, distance is a factor.
5. Test on a different network. Use mobile data from your phone as a hotspot. If the problem disappears, your Wi-Fi or home line is involved.
6. Test by cable. If you can plug in, do. If a wired connection fixes it, Wi-Fi is the cause.
7. Look at the call quality panel. Many versions of Teams show details such as round-trip time, jitter and packet loss during or after a call. Look at which number is poor. Menu names vary by version.
8. Write the results down with the times. Notes turn a vague complaint into something IT can act on.

Interpretation is simple. If only the far VPN location is bad, choose a nearer one. If everything is bad on Wi-Fi and fine by cable, fix the Wi-Fi. If everything is fine without the VPN and bad with it even at the nearest location, the problem is in how the tunnel handles real-time traffic, and the fix belongs to whoever administers it.

Worked example: a support agent at home

Dara works in customer support from home, on a work laptop, five hours of Teams calls a day. Her company requires a VPN to reach the ticketing system. Her calls are choppy in the afternoons.

Step one, find the pattern. She keeps notes for three days. Calls are worst between 4 and 6 pm, which is when her family are home and streaming video.

Step two, rule out the VPN. With the VPN off, on her phone's hotspot, a test call is clean. With the VPN on and the hotspot, still clean. With the VPN on and home Wi-Fi at 5 pm, choppy. The VPN is not the culprit.

Step three, find the real problem. Her laptop is in the far corner of the house and uses a crowded 2.4 GHz channel. The call quality panel shows jitter spikes and some packet loss.

Step four, fix. She moves her work desk to a spot near the router, plugs in a cable with a cheap adapter, and asks the household to avoid large downloads during her shift. Jitter drops, and the calls are clean with the VPN on.

Lesson. The VPN was the suspect because it was the new variable, but it was innocent. Only the test sequence revealed that. In a second case with the same symptoms, the same sequence might have shown the VPN at fault, and the fix would have been different.

What users can change

Without admin rights, you can still do a lot.

• Choose the nearest VPN location. This is the single largest user-side lever.
• Use a wired connection or sit close to the router and prefer 5 GHz Wi-Fi where available.
• Close upload-heavy apps: cloud backups, large syncs, other video streams.
• Use a headset with a microphone. Poor microphones add noise that makes the codec's job harder.
• Turn off your camera when the link is weak. Audio is far more robust.
• Join from the Teams desktop app rather than a browser if you have the choice; apps often have better media handling.
• Restart the VPN connection and Teams after a network change. Roaming between access points can leave a call on a bad path.

If you are using a personal VPN for privacy on a public network and your calls suffer, you can pause it on a network you trust. Do not disable a work VPN against your employer's policy.

What IT can change

If you administer the VPN, these are the usual levers. Treat the list as options to evaluate, not a recipe.

1. Keep real-time media out of the tunnel where policy allows. Many organisations send Teams media straight to the internet via split tunneling and keep internal systems in the tunnel. The idea is explained in what split tunneling is. Microsoft's network guidance discusses this for Teams media; consult the current version.
2. Prefer a UDP-based tunnel for gateways that carry calls. This avoids retransmission stacking.
3. Check packet size. A tunnel adds headers. If packets exceed the path's limit and fragmentation or discovery fails, video and screen sharing hang. See the VPN MTU issue and RFC 1191.
4. Provision the gateway properly. An overloaded VPN gateway causes jitter for everyone at peak hours.
5. Mark and prioritise media if your network supports it. Quality-of-service marking can help on managed links, though it rarely survives the public internet.
6. Open the documented call ports on firewalls between the user and the internet.
7. Provide a nearby entry point for remote staff so they do not trombone through a distant head office.
8. Collect call-quality data over time. Patterns by hour, site and VPN node reveal capacity problems that single complaints hide.

Guidance such as NIST's telework security publication is a reminder that any change to routing must keep security controls in place, so make changes in agreement with your security team.

Common mistakes

• Blaming the VPN without a baseline test.
• Buying a faster internet plan to fix a jitter problem.
• Running Teams, a cloud backup and a large sync at the same time.
• Using weak Wi-Fi in a far room.
• Choosing a far VPN location by habit.
• Disabling a work VPN without permission.
• Changing five settings at once so that nothing can be attributed.
• Expecting a VPN to rescue a congested route. It sometimes helps, but it normally adds distance.
• Ignoring the call quality panel, which usually tells you which number is bad.

Summary

Teams calls are real-time, so they react to latency, jitter, packet loss and transport choices in a way that downloads never do. A VPN can add distance, overhead or a slower transport, but home Wi-Fi and crowded links are equally common causes. Run a short baseline test with and without the VPN, on Wi-Fi and by cable, read the call quality numbers, and change one thing at a time. Users can choose a nearer location and a wired connection; administrators can keep media out of the tunnel, check packet size and size the gateway.

If you want a personal VPN for public or hotel networks, you can see the pricing page at your own pace.