Teams calls dropping after ~5 mins on SWG (M5400) – WebSocket & session timeout issue? 100

Hey everyone,

Testing an SWG M5400 (v13.0.120) in explicit proxy mode to replace our old proxy. All M365 services worked fine on the old setup, but we're hitting issues here:

-Teams calls consistently drop around the 5-minute mark.

-Outlook has intermittent sync/connection hiccups.

-connectivity.office.com flags issues on Media Connection, TCP Connection, and WebSocket.

What we've done so far:

-Added Microsoft IPs/URLs to the allowlist per MS documentation.

-Added SSL Decryption exclusions for all M365 traffic (policy is otherwise Decrypt All).

-Confirmed upstream FortiGate isn't blocking anything.

The ~5-minute drop makes me suspect an aggressive TCP keep-alive or idle timeout (300s) on the SWG, or something messing with long-lived WebSocket sessions.

Has anyone run into this on 13.0.x? Any specific timeout tweaks or settings needed for Teams/WebSockets on this box?

Thanks in advance!

Yes — your 300-second suspicion is very plausible, but there is one important distinction: Teams media traffic and Teams signaling/WebSocket traffic should not be treated the same way through an explicit proxy.

Microsoft specifically notes that Teams uses long-lived bidirectional WebSocket connections, and recommends allowing WebSockets; if WebSockets fail, Teams falls back to HTTP long polling, which can increase latency and bandwidth.

Also, Microsoft documents that proxy/firewall TCP idle timeouts in the 100–300 second range can cause problems for long-lived Microsoft 365 connections, including Outlook.

What I would check on your M5400

1. Check the 300-second timeout first

On the SWG, look for the settings related to:

TCP connection timeout
TCP idle timeout
HTTP/HTTPS connection timeout
Persistent connection / Keep-Alive timeout
WebSocket timeout
Upstream server connection timeout

If you find 300 seconds, temporarily increase it substantially, e.g. 1800 seconds or 3600 seconds, for testing.

Don't change everything at once. Change the suspected idle/persistent connection timeout and test a Teams call for 10–15 minutes.

2. Make sure WebSocket is actually permitted

Your SSL-decryption exclusion is good, but SSL bypass alone doesn't guarantee that the SWG is handling WebSocket correctly.

The path should effectively be:

Client → Explicit Proxy → Microsoft 365

with WebSocket upgrade requests allowed.

Look specifically in the SWG logs for:

HTTP/1.1 101 Switching Protocols

A successful WebSocket connection normally gets the 101 Switching Protocols response.

If you see:

101

initially and then approximately 300 seconds later FIN/RST, that would be a very strong indication of a timeout/connection-management problem.

3. Teams calls are a separate issue

This is particularly important.

Microsoft Teams media uses UDP, including the documented Teams media ranges/ports. Current Microsoft documentation lists Teams media IP ranges and UDP ports such as 3478–3481.

Microsoft also recommends that Teams media traffic be routed appropriately rather than forcing it through unsuitable proxy paths.

So I would test this separately:

Teams signaling/control

HTTPS 443
WebSocket
Explicit proxy

Teams real-time media

UDP
3478-3481
Microsoft Teams media IP ranges

If your explicit proxy is only handling HTTP/HTTPS, don't assume that your Teams call media is going through the same path.

4. Your connectivity.office.com results are very useful

The fact that it reports:

❌ Media Connection
❌ TCP Connection
❌ WebSocket

while normal M365 browsing works strongly suggests this isn't simply an M365 URL allowlist problem.

I'd concentrate on the connection behavior of the SWG, rather than adding more Microsoft URLs.

Microsoft itself says Teams connectivity problems commonly trace back to firewall/proxy connectivity and that the required URLs/IPs/ports need to be permitted.

5. Do one very useful A/B test

This will tell us a lot.

Create a temporary test policy for one test PC:

Test PC
   |
   |-- NO explicit proxy --> Internet

Run:

Teams 15–20 minute call
Outlook
connectivity.office.com

Then:

Test PC
   |
   |-- M5400 explicit proxy --> Internet

Run exactly the same tests.

If:

Direct = OK

and

M5400 proxy = Teams drops around 5 min

then you've isolated the problem to the SWG/proxy path.

6. Even better: packet capture at the 5-minute mark

During a Teams call, capture the connection and look around:

04:55
04:59
05:00
05:01

You're looking for:

FIN
RST
TCP retransmissions
WebSocket close
proxy-generated termination

If the SWG sends a RST/FIN almost exactly at 300 seconds, that's considerably stronger evidence than simply observing that the call drops at 5 minutes.

My troubleshooting order

I would do it in this exact order:

A. Find the M5400 TCP/HTTP/WebSocket idle timeout.

B. If it's 300 seconds, temporarily increase it to 1800/3600 seconds.

C. Confirm WebSocket 101 Switching Protocols succeeds.

D. Check SWG logs at the exact 5-minute failure for the connection termination reason.

E. Verify Teams UDP media traffic is not being unnecessarily forced through the explicit proxy.

F. Run the direct-vs-proxy A/B test.

G. Only after that investigate FortiGate/NAT/ISP.

One thing I would not do yet

I wouldn't keep adding more Microsoft URLs/IPs to the allowlist. Your symptoms — particularly Teams ≈ 5 minutes + Outlook intermittent + WebSocket failure — fit a connection handling/timeout problem much better than a simple missing-domain problem.

I couldn't find a public Sangfor document specifically confirming a known M5400 v13.0.120 300-second Teams bug, so I wouldn't label this a confirmed version-specific defect yet. The Microsoft documentation does, however, directly support your concern about long-lived TCP/WebSocket connections and 100–300-second proxy/firewall idle timeouts.

If you send me screenshots of the M5400 timeout/connection settings (or the relevant SWG configuration page), I can tell you exactly which settings to change and what values to use, step-by-step.