IPsec Pass-Through on a Home Router: What It Really Does

Router pass-through switches are forwarding concessions for a device behind them, not VPN services. It does not enroll the router as a client, hold credentials, or push every appliance in the house through a remote exit. What it does is shape how one protocol crosses address translation and filters. Once that is clear, the switch becomes easy to test and easy to leave off.

What the Router Is Actually Doing

The router sits between a client and an IPsec peer, forwarding packets it was never designed to understand. Vendors implement the feature in at least three ways: a protocol helper that tracks or rewrites state, a filter exception that stops dropping ESP, or a compatibility mode aimed at older clients. The label in the web interface rarely says which of the three you have. Only the firmware notes or a packet capture will tell you.

A helper can also make things worse. Assistance written for an older flow sometimes interferes with a client that already handles translation correctly. When a modern client works with the option off, leaving it off is the better configuration.

Pass-through never gives the router the peers' keys. It still sees the outer addresses and ports, and it still applies its own forwarding policy to them.

NAT and NAT-T Decide the Path

IPsec was not built to survive address translation, so the standards added a wrapper. NAT traversal encapsulates ESP inside UDP, letting an ordinary NAT table carry the flow, and the negotiation agrees on that switch during IKE (RFC 3948). IKE itself uses UDP 500, while the encapsulated path typically uses UDP 4500.

That is why a firewall rule allowing only protocol 50 is not enough on a translated path. Blocking 4500 breaks the case the wrapper exists for, and blocking 500 stops the negotiation before any tunnel forms. Both directions matter, since a stateful router usually permits the reply only after it saw the request. Reaching a port is not the same as finishing authentication, and neither is the same as forwarding protected traffic.

Older arrangements differ enough that a guide written for them can mislead. When a client offers both modes, test the one your peer documents rather than the one with more search results.

Find the Failing Stage

Split the problem into negotiation, authentication, child protection and inner forwarding, then gather evidence for one stage at a time. A reboot that temporarily changes the result proves only that some state was involved.

sudo tcpdump -ni any 'udp port 500 or udp port 4500'
ip xfrm state list
ip xfrm policy list

The capture shows whether the exchange reaches the peer and whether replies come back, which separates a filtering problem from a credential problem. The state listing shows established security associations, so an empty list after an attempt points at negotiation rather than at routing. The policy listing shows which selectors are installed, which is where an off-subnet destination gets excluded. Read both xfrm outputs before touching the router, because they describe what the host believes rather than what the router allows.

If packets leave and nothing returns, move the capture to the router's WAN side. Comparing the two captures localises the drop without guessing.

Turn Off What You Do Not Need

A single working laptop does not prove the router handles several clients at once. Each client creates its own translation state and its own negotiation, and some helpers track only one flow. Test the number of simultaneous sessions you actually need, from the networks you actually use. If the second client fails while the first thrives, that is the finding rather than a flaky tunnel.

Keep the option enabled only when a capture shows it is needed. Record the firmware version beside the result, since these behaviours change between releases. The goal is a client tunnel you verified, not a switch you enabled hopefully.