Split tunneling controls which traffic from a connected VPN client traverses the encrypted tunnel and which traffic exits to the internet directly. Get it wrong and you either backhaul Netflix traffic across your WAN (paying for bandwidth and adding latency) or you create a security policy gap by letting corporate traffic skip your inspection stack. This article walks the three split-tunnel modes on Cisco ASA AnyConnect, the configuration for each, and the gotchas that bite engineers in production. All output is from a live ASAv 9.23(1) in the PingLabz ASA reference lab.
Before you decide on a split-tunnel policy, two preconditions need to be true on the gateway: a properly configured AnyConnect connection profile (covered in Cisco ASA AnyConnect SSL VPN Configuration and Cisco ASA AnyConnect IKEv2 VPN Configuration), and a clear understanding of which inside subnets clients legitimately need to reach.
The Three Split-Tunnel Modes
| Mode | What it does | When to use |
|---|---|---|
tunnelall | All client traffic, including internet-bound, is sent through the VPN. The corporate edge handles all egress. | High-security environments, BYOD with weak host posture, regulated networks where all traffic must be inspected. |
tunnelspecified | Only traffic destined to networks in the include ACL goes through the VPN. Everything else exits to the internet directly from the client. | The most common pattern. Performance-friendly, conserves WAN bandwidth, keeps Netflix off your firewall. |
excludespecified | All traffic goes through the VPN except destinations in the exclude ACL. The opposite of tunnelspecified. | Niche: when you tunnel-all by default but need to bypass a specific cloud SaaS or video conferencing platform that does not work well over the VPN. |
The default is tunnelall if you set nothing. Most production deployments override that to tunnelspecified.
The Configuration Pattern
Three pieces of config define a split-tunnel policy:
- A standard ACL listing the included (or excluded) networks.
- The
split-tunnel-policyattribute in the group-policy. - The
split-tunnel-network-listattribute referencing the ACL by name.
The first gotcha is that the ACL must be standard, not extended. Pasting an extended ACL silently fails and the client falls back to tunnelall. Always confirm the ACL type with show running-config access-list NAME.
Example: tunnelspecified (Most Common)
In our lab the inside subnet is 10.10.0.0/16. We want clients to reach that and only that across the tunnel. Everything else goes direct.
ASA-PERIM(config)# access-list SPLIT-TUNNEL standard permit 10.10.0.0 255.255.0.0
ASA-PERIM(config)# group-policy ANYCONNECT-SSL-GP attributes
ASA-PERIM(config-group-policy)# split-tunnel-policy tunnelspecified
ASA-PERIM(config-group-policy)# split-tunnel-network-list value SPLIT-TUNNEL
Verify:
ASA-PERIM# show running-config access-list SPLIT-TUNNEL
access-list SPLIT-TUNNEL standard permit 10.10.0.0 255.255.0.0
ASA-PERIM# show running-config | include split-tunnel
split-tunnel-policy tunnelspecified
split-tunnel-network-list value SPLIT-TUNNEL
split-tunnel-policy tunnelspecified
split-tunnel-network-list value SPLIT-TUNNEL
The duplicate output is because both our SSL group-policy (ANYCONNECT-SSL-GP) and our IKEv2 group-policy (ANYCONNECT-IKEV2-GP) reference the same SPLIT-TUNNEL ACL. That is intentional. One ACL, two consumers, identical behavior across both transport modes.
What happens at the client: when AnyConnect connects, it pulls the split-tunnel attributes from the gateway and installs route table entries on the client OS. The 10.10.0.0/16 route points at the VPN virtual adapter. Everything else uses the existing default route on the physical adapter.
Example: tunnelall
The strict-security default. Every packet from the client (DNS lookups, web browsing, streaming, software updates) is encapsulated and sent to the gateway. The corporate edge sees and inspects everything.
ASA-PERIM(config)# group-policy ANYCONNECT-SSL-GP attributes
ASA-PERIM(config-group-policy)# split-tunnel-policy tunnelall
ASA-PERIM(config-group-policy)# no split-tunnel-network-list value SPLIT-TUNNEL
The no split-tunnel-network-list line clears the include ACL because it is meaningless under tunnelall. Some engineers leave it in by accident; the ASA ignores it under tunnelall but it confuses the next person reading the config.
Two things to know about tunnelall:
- You must NAT the VPN pool to the outside. Client traffic egressing to the internet from the VPN pool needs to be source-NATed by the ASA's outside interface, otherwise return traffic is dropped at the ISP. This is a separate NAT rule from the inside-to-outside dynamic PAT, even though they look similar.
- Your edge bandwidth is now the VPN bandwidth. 200 connected employees streaming 4K video means 200 video streams hitting your WAN egress instead of the user's home ISP. Capacity-plan accordingly.
Example: excludespecified
This is the rare third option. Tunnelall by default, but exclude a specific destination set. Common use case: a SaaS application that is sensitive to round-trip latency (live video, voice) where the user's home internet path beats the corporate-backhaul path.
ASA-PERIM(config)# access-list TUNNEL-EXCLUDE standard permit 99.84.0.0 255.252.0.0
ASA-PERIM(config)# access-list TUNNEL-EXCLUDE standard permit 13.107.0.0 255.255.0.0
ASA-PERIM(config)# group-policy ANYCONNECT-SSL-GP attributes
ASA-PERIM(config-group-policy)# split-tunnel-policy excludespecified
ASA-PERIM(config-group-policy)# split-tunnel-network-list value TUNNEL-EXCLUDE
Two things to know about excludespecified:
- The ACL is destination-based, listing what to skip. Same standard-ACL syntax, but the semantic flips.
- The exclude list is fragile. SaaS providers reshuffle their CDN ranges constantly. An exclude ACL becomes stale fast. Most teams avoid this mode for that reason.
DNS and Split Tunneling
Half the support tickets for split-tunnel deployments are DNS-related. The client connects, can ping inside servers by IP, but cannot resolve internal hostnames. The fix is two attributes:
ASA-PERIM(config)# group-policy ANYCONNECT-SSL-GP attributes
ASA-PERIM(config-group-policy)# dns-server value 10.10.0.10
ASA-PERIM(config-group-policy)# default-domain value pinglabz.lab
ASA-PERIM(config-group-policy)# split-dns value pinglabz.lab corp.pinglabz.lab
dns-server tells the client which resolvers to use for tunneled queries. default-domain auto-appends to short hostnames. split-dns tells the client which suffixes to send through the tunnel; everything else goes to the local resolver. Without split-dns on a tunnelspecified policy, the client tends to use whichever resolver the OS prefers, and short-name lookups fail randomly.
NAT Exemption: The Other Half of the Puzzle
Even with split-tunnel correctly configured, the client cannot reach the inside subnet if the ASA's NAT rules translate VPN-pool traffic. Identity NAT (or NAT exemption) is required:
ASA-PERIM(config)# object network INSIDE-NET-FULL
ASA-PERIM(config-network-object)# subnet 10.10.0.0 255.255.0.0
ASA-PERIM(config)# object network REMOTE-VPN-NET
ASA-PERIM(config-network-object)# subnet 10.99.99.0 255.255.255.0
ASA-PERIM(config)# nat (inside,outside) source static INSIDE-NET-FULL INSIDE-NET-FULL destination static REMOTE-VPN-NET REMOTE-VPN-NET no-proxy-arp route-lookup
The no-proxy-arp + route-lookup options are important. They tell the ASA to translate without rewriting source/dest, and to honor the routing table for the actual forwarding decision. Full walkthrough including verification is in Cisco ASA Identity NAT / NAT Exemption for VPNs.
Verifying the Client's Routes
From the client OS, the easiest way to confirm split-tunnel is working as designed:
- Windows:
route printafter connecting. Look for entries under "IPv4 Route Table" with the VPN adapter index showing the included subnets. - macOS / Linux:
netstat -rnorip route show. Look for the included subnets with the AnyConnect tun interface as next-hop. - Both: trace a packet to an internal host and an external host. The internal one should hop through the VPN gateway; the external one should leave on the local LAN.
From the ASA side, packet-tracer can simulate a VPN-pool source IP traversing the ASA to confirm the NAT and ACL paths are clean. The output will show whether the NAT exemption rule is hit and whether the ACL phase passes.
Common Gotchas
The four mistakes that come up over and over:
- Extended ACL instead of standard. The
split-tunnel-network-listattribute requires a standard ACL. An extended ACL silently fails to apply, the client getstunnelallbehavior, and nobody notices until a manager asks why their Zoom calls are going through the data center. - NAT exemption forgotten. Split-tunnel is set, the client connects, but inside resources are unreachable. The Section 2 dynamic PAT rule is rewriting the VPN-pool source. Add an identity NAT rule in Section 1 to skip the PAT.
- DNS not configured. Hostname lookups fail or go to the wrong resolver. Set
dns-server,default-domain, and ideallysplit-dnsin the group-policy. - Local-LAN access is allowed by default. Even under
tunnelall, the client can reach its local LAN (the printer, the home router) unless you explicitly disable it withsplit-tunnel-policy excludespecifiedagainst an empty ACL or through the AnyConnect profile XML. For real lockdown, deny local LAN.
Key Takeaways
Split tunneling on Cisco ASA AnyConnect is three modes (tunnelall, tunnelspecified, excludespecified), one ACL (always standard), and one group-policy attribute. The most common production pattern is tunnelspecified for performance, paired with NAT exemption for the VPN pool and split-DNS for internal hostname resolution. The most common failure mode is an extended ACL silently being ignored, dropping the client into tunnelall.
For the full Cisco ASA reference, including site-to-site IPsec, NAT, ACLs, failover, and the troubleshooting tools, see the Cisco ASA pillar. For the connection-profile foundation that this article builds on, return to Cisco ASA AnyConnect SSL VPN Configuration; for the NAT side, Cisco ASA Identity NAT / NAT Exemption for VPNs shows the full Section 1 manual NAT pattern.
