Split Tunneling for UCaaS — VPN Configuration That Doesn’t Kill Voice Quality

Split tunneling is one of those configurations that sounds optional until you watch a Teams or Webex deployment fall apart for remote users while everything works fine at the office. It isn’t optional. For any organization running UCaaS with a VPN, it’s a requirement.

This article covers what split tunneling is, why it matters specifically for cloud voice platforms, what to exclude from the tunnel, and how to implement it in Cisco AnyConnect — with notes on applying the same approach to other platforms.

The Problem With Full Tunnel VPN and Cloud Voice

A full tunnel VPN configuration routes all user traffic — every DNS query, every HTTPS request, every RTP stream — through the corporate VPN concentrator before it goes anywhere else. This made sense when everything a user needed lived inside the corporate network. It makes no sense for cloud-hosted platforms.

When a remote user on full tunnel VPN makes a Teams or Webex call, here’s what actually happens to their voice traffic:

Their RTP audio stream travels from their home connection to the VPN concentrator at the corporate office, then back out to the Microsoft or Cisco cloud infrastructure, then the return path reverses the same route. Instead of a direct connection from the user’s device to the nearest Microsoft or Cisco data center — which might be 20ms away — the traffic is hairpinning through a corporate network that could be hundreds of miles in the wrong direction.

The result is added latency, added jitter, and a VPN concentrator that was sized for secure data access now saturated with RTP streams it was never designed to carry. Voice quality degrades, calls drop, and the network team starts getting tickets that say “Teams doesn’t work on VPN” — which is accurate, but the fix isn’t Teams, it’s the VPN policy.

Split tunneling solves this by defining which traffic goes through the tunnel and which traffic goes directly to the internet from the user’s local connection. Corporate resources — file shares, internal applications, on-premises systems — still go through the tunnel. Microsoft 365 and Webex traffic bypasses it entirely and connects directly.

What Split Tunneling Actually Does

At the routing level, a VPN client with split tunneling maintains two paths simultaneously. Traffic destined for corporate IP ranges is routed through the encrypted tunnel to the VPN concentrator. Everything else — including UCaaS traffic — is routed through the local default gateway, which is typically the user’s home router or whatever network they’re connected to.

The VPN client enforces this by injecting specific routes into the client’s routing table when the tunnel is established. With full tunnel, a default route (0.0.0.0/0) points everything through the tunnel. With split tunneling, only specific corporate subnets get tunnel routes — everything else follows the local default gateway.

For UCaaS traffic this means:

Signaling to Microsoft and Cisco cloud infrastructure goes directly to the internet
RTP media streams take the shortest path from the user’s device to the nearest cloud media node
No hairpinning through the corporate VPN concentrator
VPN bandwidth is preserved for traffic that actually needs to traverse the corporate network

What to Exclude From the Tunnel

For Microsoft Teams, the domains and IP ranges in the Optimize category of the Microsoft 365 endpoint list are your split tunnel exclusions. These are the endpoints Microsoft explicitly identifies as latency-sensitive and inappropriate for proxy or VPN inspection. The full list is covered in Firewall Rules for Teams and Webex — for split tunnel purposes, the key exclusions are:

*.teams.microsoft.com
*.skype.com
13.107.64.0/18
52.112.0.0/14
52.122.0.0/15

For Cisco Webex Calling, the equivalent exclusions are:

*.webex.com
*.ciscospark.com
*.wbx2.com

Microsoft publishes a PowerShell script and an API endpoint specifically for pulling current Optimize-category IP ranges for VPN exclusion automation — worth using in environments where the exclusion list needs to stay current without manual updates.

Cisco AnyConnect — Split Tunnel Configuration

In AnyConnect, split tunneling is configured on the VPN headend at the group policy level. The approach is to define which traffic should bypass the tunnel, then apply it to the group policy as a split tunnel exclusion list.

There are two split tunnel modes in AnyConnect:

tunnelspecified — only traffic matching the ACL goes through the tunnel. Everything else goes direct. This is the standard enterprise approach — define your corporate subnets, everything else bypasses.

excludespecified — all traffic goes through the tunnel except what matches the ACL. This is the cleaner option for UCaaS specifically — you keep full tunnel behavior for everything and explicitly carve out the UCaaS traffic.

For a UCaaS-focused split tunnel on an existing full tunnel deployment, excludespecified is the right mode — it’s a surgical change that doesn’t touch existing tunnel behavior for corporate traffic.

A note on ASA headends: If you’re still running an ASA as your VPN concentrator, the IP-based ACL syntax below applies — but ASA hardware and software are in end-of-life progression as of 2024-2025. Cisco’s current platform is FTD. If an ASA upgrade is on your roadmap, factor that into your planning.

FTD with AnyConnect — dynamic split tunneling (recommended):

group-policy GP-REMOTE attributes
 dynamic-split-exclude-domains value teams.microsoft.com skype.com webex.com ciscospark.com wbx2.com

Dynamic split tunneling on FTD is the better long-term approach — domain-based rules handle infrastructure changes automatically without requiring ACL updates when Microsoft or Cisco update their IP ranges.

ASA with AnyConnect — IP-based exclusion ACL:

access-list SPLIT-EXCLUDE standard permit 13.107.64.0 255.255.192.0
access-list SPLIT-EXCLUDE standard permit 52.112.0.0 255.252.0.0
access-list SPLIT-EXCLUDE standard permit 52.122.0.0 255.254.0.0

group-policy GP-REMOTE attributes
 split-tunnel-policy excludespecified
 split-tunnel-network-list value SPLIT-EXCLUDE
 split-dns none

The IP-based method works but requires manual maintenance as Microsoft and Cisco update their infrastructure ranges. Dynamic split tunneling on FTD eliminates that overhead entirely.

Other VPN platforms: The same concept applies to Palo Alto GlobalProtect, Fortinet FortiClient, and other enterprise VPN clients — the implementation varies but the configuration goal is identical. Define your UCaaS domains or IP ranges as tunnel exclusions and verify traffic is taking the direct path. Consult your platform’s split tunnel documentation for the specific syntax.

Verifying Split Tunnel Is Working

Configuring split tunneling and assuming it works are two different things. Verify it before go-live.

From the client — check the routing table: With the VPN connected, run route print on Windows or netstat -rn on Mac/Linux. You should see specific routes for corporate subnets pointing to the VPN tunnel interface. The Microsoft 365 and Webex IP ranges should not have tunnel routes — they should follow the default gateway through the local interface.

Trace the media path: Use tracert or traceroute to a known Microsoft 365 IP (13.107.64.1 for example) with the VPN connected. The first hop should be your local gateway — not the VPN concentrator. If the first hop is the VPN concentrator, traffic is still tunneling.

Check Teams network connectivity: Microsoft Teams has a built-in network assessment tool and the Teams admin center shows call quality data including media path. A direct media path shows significantly lower RTT than a hairpinned path through a VPN concentrator.

Check Webex network readiness: Cisco provides a Webex network readiness test at networktest.webex.com. Run it with VPN connected after configuring split tunneling — it validates connectivity to Webex media infrastructure directly and reports latency.

Common Mistakes

Configuring split tunneling but forgetting DNS. If your VPN pushes a DNS server configuration that routes all DNS through the tunnel, Teams and Webex domain resolution is still going through the corporate DNS path even if the traffic itself bypasses the tunnel. Verify that DNS for Microsoft 365 and Webex domains resolves via public DNS from the client when split tunneling is active.

Using IP-based exclusions on a list that goes stale. Microsoft and Cisco update their infrastructure. A static ACL built from a document that’s six months old may be missing current IP ranges. Use Microsoft’s endpoint API or dynamic split tunnel domain rules where your platform supports it. At minimum, schedule a quarterly review of your exclusion list against current published ranges.

Partial exclusions. Excluding signaling domains but not media IP ranges, or vice versa. Both need to bypass the tunnel. Signaling goes through TCP 443 to Microsoft and Cisco domains — if that’s tunneled and inspected, authentication breaks. Media goes to IP ranges over UDP — if that’s tunneled, quality degrades. Both layers need to be in the exclusion list.

Applying split tunnel changes to the wrong group policy. In environments with multiple VPN group policies for different user populations, the UCaaS exclusion needs to be applied to every policy used by employees who make calls. Missing a group policy means a subset of users still has their Teams or Webex traffic tunneled — and the intermittent nature of the failure makes it harder to diagnose.

Not verifying after deployment. The routing table check takes two minutes. The traceroute takes thirty seconds. Do both after configuring split tunneling on at least one client before declaring it done.

What Comes Next

With VPN sorted, the next topic in the Networking pillar is SIP fundamentals — understanding how VoIP call flow actually works at the protocol level. SIP Fundamentals for Network Engineers — How VoIP Call Flow Actually Works builds the protocol foundation that underpins everything from dial plan troubleshooting to reading SBC logs.

For firewall policy alongside your split tunnel configuration, Firewall Rules for Teams and Webex covers the full port and domain requirements for both platforms.

For a complete pre-deployment validation checklist that includes VPN and split tunnel verification, see Network Readiness Assessment for UCaaS.