ASA Hairpin: Internet Exit or Site-to-Site VPN Leg?

Two remote-access users behind the same ASA can send traffic out of the same outside interface and get completely different treatment. One is going to a public website, so the packet needs source translation and an internet route. The other is going to a server behind a site-to-site tunnel that also terminates on that interface, so the packet needs identity, a matching tunnel selector and a return path to the client pool. Same-interface permission is a precondition for both and a solution for neither.

Two legs, one interface

Decide which leg you are building before you type a NAT rule, because the rules are not interchangeable. Leg A is client to internet: pool address in, translated public address out, back through the same interface. Leg B is client to a private prefix on the far side of another IPsec peer: pool address preserved, re-encrypted, and delivered to a peer that must know how to answer the pool.

What both need first is the same-interface permission. Without it the ASA refuses to forward a packet out of the interface it arrived on, and the failure looks like a routing problem rather than a policy one:

same-security-traffic permit intra-interface

That one line authorizes a forwarding arrangement, as the ASA NAT reference describes for same-interface paths. It does not add a client route, authorize a resource, translate an address or negotiate an IPsec selector, so expect to add three or four more things after it and do not read its acceptance as progress.

Leg A: the client wants the internet

For an internet exit, the pool address has to stop being private before the packet leaves. On an ordinary PAT design the rule translates the pool to the outside interface address, and the return state restores the client-facing flow:

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

Then confirm the client actually asked the ASA to carry that traffic. A split-tunnel exclusion sends the public destination over the phone's own connection, which never reaches the ASA at all, and no amount of NAT fixes a packet that was never sent. Check the group policy's split-tunnel list against the destination you are testing.

The rest of the leg is ordinary: a usable default or specific route out of the outside interface, an access policy that permits the flow, and DNS handled according to whichever resolver policy you chose. Add route-lookup here for the same reason as below, since the entry and exit interface are identical.

Leg B: the client wants a private site

This leg fails in more places, so write it in order. First the client route: the destination prefix must be in the split-tunnel list, or the client will not place it in the tunnel. Second the tunnel selector: the site-to-site crypto ACL must cover pool address to remote prefix, not just the local LAN to the remote prefix. Third identity, so the pool address is not translated into the internet PAT on the way past.

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

The far side is the part people forget to test. The peer needs a route back to the pool and a selector that includes it, and its own policy must permit the source addresses it will see. If the site is used to a translated view instead, that is a valid design, but then both peers, both selectors and both route tables have to agree on the translated addresses.

Check rule order as well. A broad PAT rule above the identity rule will translate the private exchange before the identity rule is ever evaluated, and the symptom is a site tunnel with no matching SA rather than a NAT error.

The test that tells you which leg you built

Use the ASA's own path evaluation instead of reading the configuration and hoping. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed shows the NAT decision, the route and the ACL result for one flow; repeat it with a private destination. If the NAT phase rewrites a private-to-private flow, you built leg A for a packet that needed leg B.

Two more commands close the gap. show nat detail prints the rule order that packet-tracer followed, and show crypto ipsec sa shows whether a selector exists for the pair you expect. A missing SA is a selector or peer configuration issue, not something the NAT rule can repair.

Verify each leg with the traffic it serves

Accept leg A with an ordinary public request from the client, and accept leg B with a request to a private resource that actually exists. Then repeat each with a denied resource, because "allowed" and "permitted by the access policy" are not the same evidence, and a hub-originated ping exercises neither client path.

Keep the two test records separate in the ticket: source address, destination, NAT rule that matched, and result. When the next report says "the VPN is broken", that pair tells you within a minute which leg regressed, and the answer is usually a route or a selector rather than the same-interface line everybody suspects first.