I've been running a Cloudflare Tunnel for our internal dev and staging environments for about six months now, and overall it's been solid for HTTP/HTTPS traffic. However, we've recently rolled out Cloudflare Teams for secure access and started enforcing WARP for all user connections, and now we're hitting a consistent, major issue: Microsoft Teams calls are dropping constantly when the Tunnel/WARP client is active.
The setup is pretty standard. We have a `cloudflared` daemon running on a few ingress nodes, advertising several internal services via a Tunnel. Our `config.yaml` is nothing fancy:
```yaml
tunnel: our-tunnel-id
credentials-file: /etc/cloudflared/credentials.json
ingress:
- hostname: git.internal.company.com
service: http://10.0.1.10:3000
- hostname: staging.app.company.com
service: http://10.0.2.50:8080
- service: http_status:404
```
The problem isn't with those web services. It's with the Teams desktop client itself when the user is connected via the WARP client with our Teams configuration. The call will connect, video/audio is fine for about 45-60 seconds, then it completely dies. The other party remains connected, but our tunnel-user drops. No reconnection attempt, just a hard fail. This happens 100% of the time.
Things we've tried and ruled out:
* Our internal network bandwidth/latency. It's fine, and calls are perfect when the user disconnects WARP and uses the corporate VPN (Tailscale, in our case).
* Cloudflare Teams policies. We've tried creating a specific policy for the `teams.microsoft.com` domain and setting it to "Do not inspect" (using both HTTP and network filters). No change.
* Split tunneling rules in the WARP client settings. We've added the entire `13.107.64.0/18` Microsoft range and `52.112.0.0/14` to the bypass list, but the calls still drop.
* Different WARP client modes (Gateway with DoH, Gateway without DoH, just WARP). The issue persists whenever the tunnel is involved in the routing path.
The real kicker is that normal web traffic, SSH over the tunnel (to bastions), and even other UDP-based applications don't seem to have this problem. It's specifically real-time media in Teams.
My current theory is that there's some aggressive TCP or UDP timeout or session handling within the tunnel daemon or on Cloudflare's edge that isn't compatible with the long-lived, multiplexed connections Teams uses for its media streams. The 60-second fail smells like a deliberate timeout somewhere.
Has anyone else battled this and found a concrete solution? I'm looking at packet captures next, but I'm hoping someone has already done the legwork and found a magic combination of Teams policy rules, WARP settings, or cloudflared arguments that keeps the calls alive.
Automate everything. Twice.
Yeah, that sounds super familiar! We ran into something similar last quarter when we first moved everyone over to WARP. The constant dropping around the minute mark was a dead giveaway.
For us, it wasn't a Tunnel issue per se, but a Teams-specific split tunneling problem within the Teams configuration. By default, WARP tries to route *all* traffic, including the heavy UDP streams for Teams media, through Cloudflare. That adds latency and can cause timeouts. We had to explicitly exclude Microsoft's media endpoints.
Did you check your Zero Trust policies under Network -> Split Tunnels? You might need to add the Teams UDP IP ranges (like 13.107.64.0/18 and others) to the "Exclude" list. It made a night-and-day difference for our call stability. 😅
Let me know if you've already tried that and I can dig up what our second culprit was.
Split tunneling is the obvious first check, sure. But I've seen cases where excluding Microsoft's IPs still doesn't fix it because WARP's MTU handling mangles the packets anyway. The advertised routes are fine, but the underlying tunnel interface is set to 1280.
Quick test: drop the MTU on the client's WARP interface. If calls stabilize, there's your real problem. Cloudflare's docs are weirdly quiet about this.
> constant dropping around the minute mark
That's usually a keepalive or timeout firing. Could be the Teams service detecting the altered path and killing the session.
-- old school
Oh, that sounds exactly like what we dealt with last month. We got so many help desk tickets about calls freezing right around the minute mark.
We had the Microsoft IPs excluded in split tunneling already, like user837 said, but it turned out we also had to exclude the specific domains Teams uses for signaling. Adding *.skype.com and *.teams.microsoft.com to the "exclude" list in our Zero Trust DNS policies finally stopped the drops for us.
Maybe the initial connection works, but the session renewal or signaling dies? Good luck
Interesting that it's only the tunnel-user side that drops. That detail makes me wonder if it's a client-side resource or timeout issue, not just a network path problem.
Have you checked the client's WARP logs for any forced disconnection events when the drop happens? We saw a similar pattern where the WARP client itself would reset the virtual interface, killing all live connections, due to a local policy conflict.
Your config is HTTP only. Teams calls use UDP and a separate signaling path. That won't touch your tunnel's ingress rules at all. The problem is the WARP client's default routing.
Check the WARP session logs on an affected client. You'll likely see high packet loss for the UDP streams after ~60 seconds. Start with the Microsoft IP ranges for media, but also verify MTU. Cloudflare's tunnel interface defaults to 1280, which can cause fragmentation and drops.
Numbers don't lie.
Yep, the tunnel config is a red herring. People always fixate on ingress rules when the real culprit is the client routing everything through a 1280 MTU pipe.
> Check the WARP session logs
Good luck getting anyone to actually do that. They'll spend three days tweaking YAML instead of running a 30-second ping test with DF bit set.
The 60-second pattern screams keepalive death. Even if you exclude the IPs, the signaling traffic still takes the tunnel and chokes on fragmentation. Lowering the MTU on the WARP interface is usually the only thing that sticks.
If it ain't broke, don't 'upgrade' it.
You're absolutely right about the MTU, but the 1280 default isn't arbitrary. It's the IPv6 minimum required MTU, and Cloudflare's network is dual-stack. The real issue is that Teams' media streams often use larger packets, and when they get fragmented over the tunnel, the reassembly can fail silently on the client side or get dropped by intermediate hops.
I've found that merely lowering the MTU on the WARP interface can create path MTU discovery black holes for other traffic. A more surgical approach is to set a lower MSS via the WARP client's `service_mode` configuration, which forces TCP connections (including the signaling) to advertise a smaller segment size and avoids fragmentation in the first place. The UDP media, however, is still at the mercy of the interface MTU.
That sixty-second timeout is almost certainly a signaling keepalive failing. The media might be excluded, but if the TCP control path is fragmented and losing packets, the session tears down.
Latency is the enemy
Oh wow, that 45-60 second drop pattern is exactly what I read about last week while setting up our first tunnel. I'm still new to this, but everyone here mentioning MTU makes a lot of sense.
So if the WARP interface is set to 1280, would a simple ping test with `-l 1400 -f` to a Teams endpoint actually show the problem? I'm trying to learn what to check first before changing configs.
Also, is the fix just for the user's local WARP client, or do you have to change something on the Tunnel server side too?
That ping test is a great first step. Using `-l 1400 -f` to a Teams endpoint will show if packets larger than 1280 are being blocked, which confirms the MTU issue.
For your second question, the fix is usually client-side. The tunnel server side config typically doesn't control the WARP client's interface MTU. You can adjust it locally with a command or via the WARP client configuration.
One caveat: some networks have firewalls that block ICMP, so a failed ping test might not be definitive. It's still a useful quick check.