Call it what it is: the full-tunnel VPN configuration most of our clients pushed during the 2020 shutdown has outlived the emergency that produced it by nearly two years, and in a good third of the estates we support it is still logged in the change record as "temporary — pandemic response." Nobody scheduled a review date; nobody believed the arrangement would survive the summer. It did. Two years into hybrid work, the question we keep getting isn't whether split-tunnel VPN belongs in a modern Microsoft 365 network design — that argument settled itself a year ago — it's why so many networks still hairpin Teams calls and SharePoint sync through a datacenter proxy never sized for this.
This note is the permanence conversation, not the pilot pitch. The industry settled on split tunnel for Microsoft 365 traffic a while back and moved to the next argument: how much of the rest of your egress belongs on the same path. We cover the Optimize category, proving the change worked, where a private circuit earns its cost, and the objections we still hear from people who haven't seen the compensating controls.
The pattern that got us writing this down: a regional insurer's helpdesk queue in January showed choppy Teams-audio tickets clustering at 9 a.m. and 1 p.m. daily, tracking almost perfectly with VPN concentrator utilization, not internet circuit graphs. The VPN was the bottleneck, by policy, not failure. Nothing was broken; something was just still configured for a crisis that had ended.
The emergency configuration nobody scheduled a review for
Full-tunnel was a reasonable emergency call: one set of controls, one egress point, one thing to explain to auditors on short notice. It was never meant to carry a company's entire cloud traffic indefinitely, and the bill for treating it as permanent shows up every quarter.
Concentrator and firewall throughput sized for a minority of remote workers on a given day is now sized for all of it, all day — an expensive refresh, or a saturation ceiling that shows up as latency for everyone, not just the person with a bad home connection.
Web proxies and secure web gateways built to inspect general internet traffic do not know what to do with a media codec: SSL interception, a scan, and a re-encrypt step get added to traffic that was encrypted and time-sensitive for entirely different reasons, and most fall real-time media back to a TCP relay when UDP won't traverse cleanly — the audio equivalent of driving in second gear.
The exception itself never got decommissioned, because "temporary" configurations are exactly the ones nobody schedules a decommission ticket for. We've opened change records this year for VPN profiles whose only supporting documentation was a Teams chat from March 2020.
What actually sits in the Optimize category
Microsoft has published a categorized endpoint list for years: Optimize, Allow, and Default. The category — not the product name — should drive routing; it's worth being precise about what actually qualifies as Optimize rather than working from a two-year-old emergency-era spreadsheet.
Optimize is the narrow list: Teams real-time audio, video, and screen-sharing media; core Exchange Online mail protocols; and SharePoint Online/OneDrive's primary sync and access endpoints — the highest-volume, most latency-sensitive destinations in the estate. The guidance for all of them is identical: no proxy, no TLS inspection, no rate-limiting, shortest path to the nearest Microsoft edge, because everything past that edge already rides Microsoft's own backbone. Allow covers the rest of Microsoft 365, still tolerant of a proxy hop; Default is everything else, treated like any other internet destination.
Teams media wants UDP, primarily ports 3478 through 3481, and DSCP tags (audio EF, video/screen-share AF41) need to survive to the WAN edge on the managed side of the connection — past whatever QoS policy nobody has touched since the phone system ran on a T1.
We stopped maintaining that list by hand; Microsoft publishes it as a queryable service:
Invoke-RestMethod "https://endpoints.office.com/endpoints/worldwide?clientrequestid=$(New-Guid)" |
Where-Object { $_.category -eq 'Optimize' } |
Select-Object serviceArea, urls, ips, tcpPorts, udpPorts |
Format-Table -AutoSize
Run it quarterly, diff it against the split-include list, and put the diff on someone's calendar — Microsoft adds and removes entries, and a static list is quietly wrong by the second quarter.
Getting DNS to actually cooperate
Split tunnel only works if the DNS answer for those Optimize names points somewhere close. Get the routing right but leave resolution going over the tunnel to an internal resolver, and the client still asks a resolver in your datacenter's region where the nearest front door is, then routes efficiently to the wrong place.
The usual culprit on Windows is the Name Resolution Policy Table left over from a DirectAccess or Always On VPN build. NRPT rules exist so specific namespaces — your internal domain — resolve through the tunnel's DNS server while everything unmatched falls through to the local adapter's own resolver. The mistake we find most often is a catch-all rule that routes every query, Microsoft 365 included, back through the tunnel:
# Namespace "." captures every DNS query regardless of split-tunnel routing --
# the most common leftover from a 2020-era forced-tunnel build
Get-DnsClientNrptRule | Select-Object Namespace, NameServers, Comment
If that returns a catch-all entry, the routing is already correct and DNS is quietly undoing it.
Once DNS is fixed, don't take the improvement on faith. Check two sources before calling a rollout finished: the Call Quality Dashboard in the Teams admin center, which shows round-trip time, jitter, and packet loss per segment without anyone filing a ticket, and the connectivity test tool in the Microsoft 365 admin center's health section, which flags whether a location is reaching the nearest Microsoft peering point. Treat the rollout as incomplete until the dashboard agrees, not until the complaints stop — that just means people gave up submitting tickets.
Where a private circuit still earns its keep
Microsoft's own guidance has said the same thing for years: ExpressRoute is not the recommended path for Microsoft 365 traffic, and a circuit bought specifically to carry Exchange, SharePoint, and Teams usually solves the wrong problem. Once traffic reaches a nearby Microsoft peering point it is already on Microsoft's global network; a private circuit just adds a hop first, rarely beats a good local breakout, and does nothing for Teams media, which negotiates its own path regardless.
A circuit still earns its keep with real Azure IaaS/PaaS dependency — domain controllers extended into Azure, SQL Managed Instance, a Virtual WAN hub genuinely carrying production traffic — or with sustained bulk data movement like large SharePoint/OneDrive migration waves, where fixed-circuit economics beat variable internet transit. It also wins at branch locations where local internet is genuinely bad or expensive.
| Path | Teams media | Edge inspection | Typical driver |
|---|---|---|---|
| Local breakout (Optimize) | Best — shortest path | None; unsupported | Default choice |
| ExpressRoute | No better; media ignores it | Azure-bound traffic only | Azure IaaS/PaaS, bulk data |
| Full VPN tunnel | Worst — extra hop, inspection | Full, at real cost | Rarely the right 2022 default |
Read the table as an argument for narrowing scope, not abandoning the circuit. Most estates we support keep ExpressRoute for Azure and still send Optimize traffic out the nearest breakout — the two decisions are independent, and conflating them is how organizations pay for a circuit quietly carrying no Microsoft 365 traffic that benefits from it.
The objections that still land on our desk
"If it doesn't transit the proxy, we can't inspect it." True, and not the control point inspection was ever going to give you here. DLP policies configured in the Microsoft 365 compliance center apply at the service layer, inside Exchange Online, SharePoint, and OneDrive, regardless of network path. If a DLP program only exists as a network-layer proxy rule, split tunnel isn't creating that gap; it's exposing one that already existed.
"We need to inspect it for compliance." Microsoft doesn't support TLS inspection of Teams media or the Optimize category, and attempting it produces the exact call-quality tickets that started this conversation, because breaking and re-establishing TLS defeats the certificate pinning and media key negotiation Teams depends on. The audit trail compliance teams actually need lives in Azure AD sign-in logs and the unified audit log, not a packet capture.
"This is a bigger attack surface." The Optimize list is a narrow, named, Microsoft-published set of FQDNs and IP ranges, not a hole punched to the general internet. The control point for "right user, compliant device, allowed action" is Conditional Access, which doesn't care which network path the packets took.
"We're moving to Zero Trust anyway." We agree with the direction and disagree with the timeline. Every SASE and ZTNA vendor pitching us this quarter is selling a genuine multi-year identity and application-inventory project, not a first-quarter fix. Split tunnel is the bridge that makes this year tolerable while that project gets scoped properly.
Turning the exception into an architecture decision
None of this is finished until it's written down somewhere other than a two-year-old chat thread.
Close the original change ticket. Whatever labeled the emergency configuration "temporary" needs a successor record stating what the permanent architecture is, who owns it, and when it was decided — with this year's date, not 2020's.
Decide, on purpose, what happens to the old full-tunnel profile. Keeping it as a documented, rarely used option — a legal hold, an incident-response window — is defensible; leaving it as the silent default because nobody revoked it is not, even though the two look identical in the routing table.
Give the Optimize-list diff an owner and a calendar slot; Microsoft revises that list without much ceremony, and a configuration correct in February isn't guaranteed to be correct in August.
Rightsize the concentrator and proxy capacity no longer carrying Teams media and SharePoint sync. Across the estates we run day to day — several past 15,000 Microsoft 365 mailboxes, Hyper-V footprints past 400 virtualized servers — freeing that traffic routinely frees enough throughput and licensing that a budgeted refresh turns out unnecessary, at least for a cycle.
Tell the helpdesk, in one paragraph, what changed and why the VPN icon staying connected no longer means Microsoft 365 traffic is going through it. That paragraph prevents more confused tickets than any amount of architecture documentation nobody outside IT will read.
If you're facing this
If your split-tunnel exception is still filed under a 2020 change ticket, if nobody can tell you which endpoints are actually driving your VPN concentrator's utilization graph, or if security's only objection is "we've always inspected everything," that's a permanence conversation worth having before the next capacity refresh gets budgeted for the wrong architecture. We help Microsoft-centric networks make this decision on purpose — inventory first, metrics before rollout, a rollback path that's documented rather than assumed. Bring us your current routing table and a quarter of Teams call-quality data, and we'll tell you honestly whether you have an architecture or just an exception that never got closed out.