Split tunnel does not exempt a public host from ASA NAT rules

Split tunneling is usually described as a way to keep corporate traffic inside the tunnel and the rest of the internet outside the firewall. Both halves of that description are wrong in the same way. Split tunneling is a route decision made by the client, and a route decision says nothing about what happens to the packet after it reaches the headend.

One partner service on a public address, which insists on seeing your headquarters address, is enough to break the story.

The myth: split tunnel takes the firewall out of the path

The belief is that any destination outside the private ranges stays on the local internet connection, so the firewall never sees it and never needs a rule for it. That holds only while the destination is absent from the tunnel list. The moment an operator adds a public host to the split-include ACL, the client sends that traffic into the tunnel, and the ASA has to route, filter and translate it like any other decrypted flow. Nothing changed on the client except the destination list.

The client did not become a router. It followed the policy you handed it.

What a split-include route actually does

On a Cisco ASA remote-access setup, the group policy carries split-tunnel-policy tunnelspecified and a split-tunnel-network-list that names a standard ACL. Every permit line in that ACL is a destination the client should send into the tunnel, and everything else keeps using the local default route.

Adding one host is a single line, and it is the only part of the change the client can see: access-list RA-SPLIT standard permit host 203.0.113.20.

Reconnect the client afterwards. The policy is exchanged at connect time, so an established session keeps the old list and makes the change look as if it did nothing.

The packet arrives and leaves on the same interface

Now trace the flow after decryption. The packet entered on the outside interface through the VPN tunnel, its destination is a public address, and the routing table sends it back out that same outside interface toward the internet. Traffic that enters and exits one interface is dropped unless the ASA is told to allow it, which is what same-security-traffic permit intra-interface does. Without it the connection fails in a way that looks like a routing problem and is not one.

That setting is global. It permits hairpinning for every flow that needs it, not only for this partner host, so it belongs in a reviewed change instead of a quick test.

Why a destination-scoped PAT is not optional

The source address on the decrypted packet is still the client VPN address, typically from a pool such as 10.77.0.0/24. That address has no route on the public internet, so the partner either never answers or answers to nowhere.

Translation fixes the source and leaves the destination untouched. With the objects already defined elsewhere, a manual rule scoped to this destination has this shape:

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

The destination static portion matters. Dropping it turns the rule into a broad translation that can match far more traffic than intended, and a broad identity rule earlier in the order can beat this one entirely. Check show nat detail and the section order before assuming your rule is the one matching.

Interface PAT also means the partner sees the ASA interface address, which may be translated again upstream. If the contract names an address, confirm it end to end rather than at one hop.

Prove it with the right test destination

Use the partner host itself, not a generic what-is-my-ip page. That page is almost certainly outside the split list, so it reports your local internet address and says nothing about this path. Open a fresh connection to the partner service and ask them what source they observed, or run packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed and read the NAT and route stages line by line. A traceroute from the client is a weaker check, because it shows the path that already happened rather than the policy that chose it.

Then check what should not change. An ordinary website must still leave from the local connection, and a private resource inside the tunnel list must still be reachable. A change that fixes the partner and breaks either of those is a different bug.

The working version of this design is short: one host in the split ACL, hairpin permission, one destination-scoped PAT rule. Everything else in the story is the myth.