L2TP/IPsec Through NAT: What Actually Breaks and Why

The claim that NAT breaks L2TP/IPsec is half true and therefore useless. Address translation is normal, NAT traversal exists precisely to survive it, and millions of clients connect from behind a router every day. What breaks is a specific stage of a specific exchange: IKE never gets an answer, the encapsulated tunnel is dropped by a policy that only permits one protocol, or the translation mapping expires while the tunnel is idle. Once you know which stage you are in, the fix is usually a single rule or a keepalive rather than a new VPN design.

The myth is the wrong question

The useful question is not "does NAT break this" but "which part of the exchange is being translated, and what does the device doing the translation do with it". L2TP/IPsec is a layered protocol: IKE negotiates, ESP protects, and L2TP carries PPP inside that protection. Address translation interacts with each layer differently, and the failure signatures are distinguishable if you look at the negotiation stage rather than the error dialog.

A router that browses the web successfully proves only that TCP with source port translation works. It says nothing about UDP 500, UDP 4500 or protocol 50, and those are the three things this deployment depends on.

Stage 1: IKE has to get an answer at all

The first exchange goes to the responder on UDP 500. If no reply comes back, nothing else matters: the pre-shared key, the proposal and the credentials are all unread. Watch for the request and the response rather than inferring from the client's timeout:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

A request with no response usually means a firewall or the upstream carrier is dropping the packet, not that the server rejected it. A response with a notify payload naming a proposal or a certificate problem means the packets arrived and the negotiation failed on content, which is a different repair entirely.

When both peers sit behind translation, the initiator only has to reach the responder, so most client-side deployments work from stage 1. Server-side hosting is where the inbound problem starts, and it is the reason the two situations should never be discussed as one.

Stage 2: encapsulation changes what the firewall sees

ESP is an IP protocol, not a TCP or UDP port, and ordinary port address translation has no port field to rewrite in it. That is why NAT traversal moves the protected payload into UDP 4500: the encapsulation gives the translating device something it knows how to translate. Once that happens, a firewall rule written only for UDP 500 permits the negotiation and drops the tunnel, which produces the confusing result where the log shows a successful phase 1 and no traffic.

The IKE exchange itself can also move to UDP 4500 after a NAT is detected, which surprises people who have allowed 500 and nothing else. Allow both ports in both directions on the path, and remember that a stateful firewall may keep the flow only as long as it sees traffic.

Protocol 50 still matters on paths without translation, and on paths where a middlebox is configured to permit it. If you are diagnosing by elimination, disable the hypothesis rather than adding rules in bulk: allow 500, 4500 and ESP, confirm the tunnel comes up, then remove what turned out to be unnecessary. A rule nobody can explain is a rule nobody will remove when it becomes the cause of the next outage. Write the narrowing into the change record along with the stage it fixed, so the next engineer starts from your evidence instead of from the same rule of thumb.

Stage 3: the mapping expires and the tunnel dies

A translating device keeps state for the flows it forwards, and that state has a lifetime. An L2TP/IPsec tunnel carries little traffic when nobody is using it, so an idle tunnel can outlive its mapping and stop receiving return traffic. The client stays convinced it is connected, the server sees nothing, and the first symptom is usually an application timeout rather than a VPN error.

Dead peer detection and NAT keepalives exist for this, and both ends have to be willing to send them. If your server is behind translation, the Windows-side requirement is a documented registry setting that makes the server assume UDP encapsulation for its own outbound packets; without it, the responder sends ESP that the translating device cannot map back. That is a server configuration issue, not a client one.

A WAN address change produces the same outcome from a different direction: the mapping is rebuilt around a new address, and the old security association is now pointed at a tuple that no longer exists. Reconnection behaviour belongs to the client implementation, which is why "reconnect after the router reboots" works on one client and needs a manual toggle on another.

Hosting behind carrier-grade NAT is a different problem

If you want to host an L2TP/IPsec server at home and reach it from outside, the requirement is unsolicited inbound reachability, and that is not what NAT traversal provides. A carrier-grade NAT in front of your router means there is no port you can forward that will make you reachable, because the public address is shared and the mapping is outbound-only.

No IPsec pass-through checkbox changes that, and no amount of client configuration compensates for it. The supported answers are an address that is actually reachable, a hosted endpoint, or an architecture where every participant makes an outbound connection. The UDP encapsulation specification solves the translation problem for flows that exist; it does not create an inbound path where the carrier does not offer one.

So compare networks rather than guessing. Take the same device and profile to a different permitted network and watch which stage fails there. If it works elsewhere, the difference is in the path, and that narrows the search to the three stages above instead of the entire configuration.