The damage model
Full tunnel drags media: client -> VPN concentrator -> corporate egress -> Microsoft -> (maybe back near the client's city). Each stage adds latency, jitter, and a congestion point sized for file shares, not RTP; the concentrator doubles every remote call's bandwidth (in+out). Result: remote calls degrade precisely when remote work peaks — and the fix cannot be bought, only routed.
The three split-tunnel models
- Exclude by IP (recommended): the Optimize ranges (13.107.64.0/18, 52.112.0.0/14, 52.122.0.0/15) route OUTSIDE the tunnel at the client. Three routes, testable, covers media and the heaviest signalling.
- Exclude by app: send teams.exe traffic outside — seductive, but browser joins, rooms devices and the new client's process model make app-matching fragile. Use as a supplement, not the design.
- Inverse split (include-only VPN): tunnel ONLY corporate destinations; everything else direct. Cleanest long-term; a bigger security-model conversation.
Security objections have a grown-up answer: the excluded destinations are Microsoft's authenticated, encrypted service ranges — CASB/inspection ambitions for that traffic die on SRTP anyway (previous concept), and Conditional Access still governs the sessions.
What to watch (proofs)
- The routing truth on a client:
route print(orGet-NetRoute) during VPN — the Optimize prefixes must point at the LOCAL interface, not the tunnel. Screenshot = deployment evidence. - The behavioural truth: capture during a VPN-connected test call — media to 52.112/13.107 leaving the physical NIC, not the tunnel adapter. (Client media log's interface-selection lines say the same without Wireshark.)
- Fleet-level: CQD's VPN dimension (it flags VPN-connected calls) — poor-call % for VPN vs non-VPN users converging is the success metric; divergence returning means a VPN client update re-enrolled full tunnel (it happens quietly and often).
- Concentrator relief: VPN gateway throughput graphs before/after — the reclaimed headroom is the infrastructure win worth reporting.