IPsec Through an ASA: NAT-T, ESP Pass-Through, and Why the Tunnel Won't Come Up

There are two completely different things people mean when they say "IPsec and the ASA," and confusing them is the fastest way to spend an afternoon chasing a tunnel that was never yours to fix. In one case the ASA is the VPN endpoint: it terminates the tunnel, decrypts the traffic, and the crypto config lives on the box. In the other case the ASA is a middle device, a firewall sitting between two VPN peers that terminate the tunnel somewhere else, and its only job is to let the encrypted traffic pass through cleanly. The commands, the failure modes, and the fixes are different for each. This article draws the line clearly, then digs into the pass-through case, where NAT-T and ESP handling produce the classic "Phase 1 up, Phase 2 down" symptom. It is part of the PingLabz Cisco ASA series and the wider IPsec VPN collection.

A note on sourcing before we start. The endpoint behavior below comes from the same live CML lab as the rest of this ASA series (an ASAv 9.24(1) terminating a real IKEv2 tunnel). The pass-through walkthrough is explained from the ASA configuration plus the NAT-T packet behavior captured in our dedicated IPsec NAT traversal lab, cross-referenced here rather than re-captured end to end. Where a claim rests on that other capture, it is called out.

Job One: The ASA as VPN Endpoint

This is the case most of the ASA VPN material covers, including our LAN-to-LAN IKEv2 walkthrough. The ASA owns the crypto: it has an IKEv2 policy, an IPsec proposal, a tunnel group with the pre-shared key, a crypto ACL, and a crypto map bound to the outside interface. Traffic arrives in the clear on the inside, the ASA encrypts it, and it leaves as ESP toward the peer. Verification lives in show vpn-sessiondb, which aggregates the IKE and IPsec halves of the session on the box itself.

The defining characteristic of the endpoint role: the encrypted packets originate and terminate on the ASA. There is no third device whose IPsec the ASA has to "get out of the way" for. When people say the ASA "has a VPN," this is almost always what they mean. Keep this picture clean in your head, because the pass-through role inverts almost every assumption in it.

Job Two: The ASA in the Middle

Now change the picture. Two other devices form the VPN, one on the inside of the ASA and one out on the internet, or one on each side of the firewall. The ASA terminates nothing. It just needs to forward the IPsec between them without dropping it. This is where firewalls historically caused grief, because IPsec is not a friendly protocol to inspect or translate.

An IPsec VPN in the classic form is two separate things on the wire: IKE, which negotiates the tunnel over UDP 500, and ESP, which carries the encrypted data as IP protocol 50. A stateful firewall like the ASA is comfortable with UDP 500 because it is ordinary UDP with ports it can track. ESP is the problem child. It is its own IP protocol, not TCP and not UDP, and it has no port numbers at all. To a firewall that wants to build a stateful entry keyed on a five-tuple, ESP is opaque.

Before we fix it, pin down the difference in one place, because everything downstream depends on which role the ASA is playing.

inspect ipsec-pass-thru: Opening the ESP Pinhole

The ASA's answer is an application inspection engine that watches the IKE negotiation and opens a temporary pinhole for the matching ESP flow. You enable it in the modular policy framework.

policy-map global_policy
 class inspection_default
  inspect ipsec-pass-thru

Here is what that one line does. When inspect ipsec-pass-thru is active, the ASA watches for the IKE exchange (UDP 500) between the two VPN peers. When it sees a successful negotiation, it dynamically opens the ESP pinhole so protocol 50 can flow between exactly those two hosts. It also cleans the flow up when the IKE session ends. The payoff: a VPN between two devices on either side of the ASA works without you writing a static access-list line to permit ESP, and without leaving protocol 50 wide open all the time. The inspection ties the ESP permission to a real, observed IKE negotiation.

Without this inspection (or a manual ESP permit), the IKE half succeeds because UDP 500 is allowed, but the ESP half is silently dropped because the firewall has no entry for protocol 50. That mismatch is the root of the symptom everyone eventually meets.

The NAT-T Complication

The pinhole handles a clean pass-through. Add NAT to the picture and it gets harder, which is where NAT Traversal (NAT-T) comes in. Suppose the inside VPN endpoint sits behind the ASA's PAT (Port Address Translation), sharing a public address with everything else inside. PAT works by rewriting source ports so it can demultiplex return traffic. But raw ESP has no ports. There is nothing for PAT to rewrite and nothing to key the translation table on, so PAT cannot track multiple ESP flows behind one address. The translation simply cannot be built.

NAT-T is the fix, and it is elegant. When the peers detect a NAT device in the path during IKE, they wrap the ESP payload inside UDP on port 4500. Now the "ESP" traffic is really UDP, it has ports, and PAT can translate it like any other UDP flow. The IKE negotiation itself also moves to UDP 4500 once NAT is detected. The deep mechanics, including the NAT-detection payloads and the UDP encapsulation on the wire, are captured and dissected in our IPsec NAT traversal lab; the short version is that NAT-T turns an untranslatable protocol into an ordinary UDP flow.

The consequence for the firewall rule is specific and easy to get wrong: when NAT-T is in play, the ASA must permit both UDP 500 (initial IKE, before NAT detection) and UDP 4500 (IKE and ESP after NAT detection). Permit only 500 and you have set the trap that produces the most famous failure signature in IPsec.

Why the Tunnel Won't Come Up: Phase 1 Up, Phase 2 Down

Here is the scenario that fills forum threads. The two peers negotiate IKE over UDP 500. It succeeds. Both ends report Phase 1 complete, the SA is established, everything looks healthy at the control-plane level. Then no data flows. Pings across the tunnel fail. The encrypted traffic goes nowhere.

The reason is that IKE and ESP travel differently. If the firewall permits UDP 500 but not the path ESP actually needs (either raw protocol 50 or, under NAT, UDP 4500), then Phase 1 completes because its packets got through, but the ESP data plane is dropped. Phase 1 up, Phase 2 down. In our NAT traversal capture, permitting only UDP 500 produces exactly this fingerprint: the IKE exchange lands, the tunnel appears established, and every data packet dies at the firewall because the UDP 4500 encapsulated ESP was never allowed.

The trap is convincing because the half that succeeded is the half you look at first. Phase 1 status is the top line of most VPN verification, so a green Phase 1 reads as "the VPN works," and attention drifts to routing or the far end. But the counters tell the truth. If Phase 1 is up and the IPsec packet counters are not incrementing, or traffic leaves encrypted and nothing comes back, suspect the data-plane path, not the negotiation.

The Endpoint Can Need NAT-T Too

One more wrinkle keeps the two roles from being perfectly clean: even when the ASA is the endpoint, NAT-T can still enter the picture if there is a NAT device between the ASA and its peer. Modern ASA code enables IKEv2 NAT-T handling as part of normal operation, so when the two endpoints detect NAT in the path they encapsulate ESP in UDP 4500 automatically. This is why, in the endpoint captures elsewhere in this series, you may see the session running over UDP 4500 rather than raw ESP. The lesson generalizes: any time NAT sits between two IPsec peers, expect UDP 4500 and make sure every firewall on the path (including the endpoint's own outside ACL) permits it.

The distinction that still matters is responsibility. As the endpoint, the ASA negotiates NAT-T itself and you verify it in the session database. As the middle device, the ASA is not a party to the negotiation at all; it is a bystander that must nonetheless let the negotiated UDP 4500 (or protocol 50) through. Same protocol behavior, completely different position in the conversation.

Diagnosing It

The distinguishing questions come in order. First: is the ASA the endpoint or the middle device? If the crypto config is on the ASA, it is the endpoint, and show vpn-sessiondb is your verification. If the ASA has no crypto map and two other devices own the tunnel, it is the middle, and your job is the forwarding path.

For the middle case, walk the path: Is inspect ipsec-pass-thru present, or is there an explicit permit for ESP or UDP 4500? Is there a NAT device between the peers, which forces NAT-T and therefore UDP 4500? Does the firewall permit both UDP 500 and UDP 4500? A "Phase 1 up, Phase 2 down" report with a NAT device in the path is UDP 4500 being blocked until proven otherwise. For a structured approach to the whole class of these faults, the IPsec VPN troubleshooting guide works through the phases in sequence so you localize the break instead of guessing.

On the ASA itself, the middle-device role has its own set of read-outs that keep you honest. show service-policy inspect ipsec-pass-thru confirms the inspection is applied and counts what it has acted on, which is your first check that the pinhole logic is even running. The connection table (show conn) is where the UDP 500 and, under NAT-T, UDP 4500 flows between the two peers should appear; if you see the IKE flow but no data-plane flow, that lines up precisely with the "Phase 1 up, Phase 2 down" story. And packet-tracer, run from the inside host toward the outside peer on UDP 4500, will tell you which rule or NAT statement drops the encapsulated ESP before it ever leaves the box. The point of naming these is not to memorize output but to build the habit: prove the data-plane path exists rather than trusting a green Phase 1.

Key Takeaways

• Two different jobs: the ASA as VPN endpoint terminates the tunnel and owns the crypto (verify with show vpn-sessiondb); the ASA as a middle device only forwards someone else's IPsec. Identify which one you are dealing with before troubleshooting.
• ESP has no ports: IKE is UDP 500 and is easy for a firewall; ESP is IP protocol 50 with no ports, so a stateful firewall cannot naturally track it.
• inspect ipsec-pass-thru opens the ESP pinhole: it watches the IKE negotiation and dynamically permits the matching ESP flow, so a VPN pair either side of the ASA works without a static ESP permit.
• NAT-T wraps ESP in UDP 4500: when the inner endpoint is behind PAT, raw ESP cannot be translated, so the peers encapsulate ESP in UDP 4500. The ASA must then permit UDP 500 and UDP 4500.
• Permit only UDP 500 and you get "Phase 1 up, Phase 2 down": IKE completes, the tunnel looks established, but the data plane dies because the ESP path (UDP 4500) was blocked. Read the IPsec counters, not just Phase 1 status.

Next steps: the Cisco ASA pillar indexes every ASA lab, the IPsec VPN hub covers the protocol from the ground up, and the NAT traversal lab shows the UDP 4500 encapsulation on the wire that this article's failure mode depends on.