ASA VPN hairpin: routing two tunnels through one interface

A remote user connects to the ASA, asks for a host behind a branch, and the ASA sends that request out the very interface the user arrived on. Nothing about that requires a second physical port. What it does require is four independent decisions that people tend to collapse into one: permission to hairpin, a tunnel that protects the right addresses, a NAT policy that preserves the source you promised, and an access policy that authorizes the service.

One packet, two tunnels

Follow the flow and the order of operations stops being mysterious. The packet arrives inside the remote-access tunnel, gets decrypted, and becomes an ordinary IP packet sourced from the client pool. The ASA then routes it, matches it against the site-to-site crypto ACL, encrypts it again, and sends it out the outside interface toward the branch.

The addresses below are illustrative, but the shape matters: the source is the pool, not the ASA's inside LAN.

remote client 10.77.0.20
  -> remote-access tunnel, terminated on ASA outside
  -> decrypted, routed, matched against site-to-site policy
  -> site-to-site tunnel, sent from ASA outside
  -> branch host 10.60.20.10

Two things follow. The client needs a route for the branch prefix through its remote-access connection, which means the split-tunnel or pushed route list has to include it. And the branch has to know how to return traffic to 10.77.0.20 or to whatever address your NAT design substituted.

Hairpin permission is global

The command people reach for is same-security-traffic permit intra-interface. It allows traffic to enter and leave the same interface, which is exactly what this path needs. It is also a global setting: enabling it changes behavior for other flows that happen to traverse the same interface twice.

That is why it belongs in a change record rather than a debugging session. Ask what else on the box could now take a same-interface path, and whether any of it should. On a busy edge with guest networks or overlapping partner tunnels, the answer is not automatically no. Write the reason next to the setting, because the next engineer will find the command and not the conversation.

Protection scope and NAT are separate

The site-to-site tunnel protects whatever its crypto ACL selects. If that ACL names the ASA's inside subnet as the source, the remote-access pool is not protected and the packet will either be dropped or sent in clear, depending on the platform's behavior for unmatched traffic. Add the pool to the protected flow when the design preserves pool addresses.

NAT then decides whether the pool address survives. Identity NAT keeps it, and the branch sees 10.77.0.20 as the source. Translation changes the contract: the branch now returns traffic to the translated address, and its own policy has to accept it. Rule order decides whether the crypto ACL matches before or after translation, so read the effective flow instead of assuming which one wins.

Do not delete the general internet PAT rules to make one transit case work. A targeted exemption or a deliberate identity rule is easier to explain and to reverse than a hole in the outbound policy.

Encryption is not authorization

A working tunnel only proves that two peers agree on keys and selectors. It says nothing about whether this user may reach that service. The VPN filter or group policy attached to the remote-access connection still has to permit the branch destination and port, and the interface ACL on the outside path still applies.

Test both directions of the answer. A connection that succeeds while a neighboring service should fail is more informative than one successful ping, because it shows the policy is selective rather than wide open. If the denied test succeeds, the tunnel is not the thing to blame; the policy is. Keep both results in the change record so the next person knows which behavior was intended.

Hairpin or a second interface

Hairpin transit keeps the design small and costs one global setting. A separate interface, or a route-based tunnel with its own virtual interface, isolates the transit path and gives you per-interface policy, at the cost of addressing and another crypto map or profile. Neither is more correct; they fail differently.

Route-based designs are a different arrangement, not a checkbox on the same configuration. If you move to one, the policy-based crypto ACL discussion above stops applying and the routing table starts doing the selection work.

Verify from the real client

An ASA-originated probe has a different source address and will not exercise the pool-to-branch path. Use packet-tracer to sanity-check the five-tuple, then open a real connection from the actual remote client, because the tracer simulates and does not replace the client's own routing and policy.

After a planned change, connect to a service that should work, then to one that should be denied, then confirm the branch's return route. The Cisco VPN hairpin NAT examples keep intra-interface permission, NAT and ACLs visibly separate, which is the mental model worth copying.