What VPN Passthrough Is and Why It Barely Matters Now
Short answer
VPN passthrough lets older VPN protocols — PPTP, L2TP and IPsec — work through a router that uses NAT, which otherwise mangles them. Modern protocols like WireGuard and OpenVPN do not need it because they run inside ordinary UDP or TCP, which NAT handles fine. If your VPN fails, passthrough is almost never the cause.
On this page
VPN passthrough is one of those router settings that generates far more troubleshooting advice than it deserves. Forum answers still recommend enabling it for VPN problems in 2026, which has been wrong for roughly as long as WireGuard has existed.
It is a compatibility workaround for a problem that modern protocols designed around.
The problem it was built to solve
Your router does Network Address Translation. One public IP address from your provider is shared across every device in the house, and the router keeps a table mapping outgoing connections to the device that made them. When a reply arrives, the router consults that table to work out where it goes.
That table is keyed on port numbers. A TCP or UDP packet carries a source and destination port, which gives the router something to match on.
Older VPN protocols do not cooperate:
- PPTP carries its data in GRE, a protocol that sits at the same level as TCP and UDP rather than inside them. GRE has no ports.
- IPsec in its native mode uses ESP, which also has no ports.
- L2TP is usually wrapped in IPsec, inheriting the same problem.
A plain NAT router receiving a GRE or ESP reply has no idea which device it belongs to, so it drops it. The tunnel establishes and then dies, or never completes at all.
VPN passthrough is the router inspecting these protocols specifically and tracking their session identifiers instead of ports. Three separate toggles normally appear, because each protocol needs its own handling.
Why modern protocols do not need it
WireGuard and OpenVPN both run inside ordinary UDP (OpenVPN can also use TCP). From the router’s point of view, a WireGuard tunnel is just a UDP conversation on a port, indistinguishable from a video call or a game.
NAT handles that without any special case. Nothing to enable, nothing to configure, and it works through multiple layers of NAT including the carrier-grade NAT many mobile and fibre providers now use.
IPsec has also largely solved its own problem. NAT-Traversal wraps ESP inside UDP on port 4500, which makes it look like any other UDP traffic. Almost every IKEv2 client negotiates this automatically. In practice the only time passthrough is genuinely load-bearing is an old L2TP/IPsec corporate setup that has not been touched in years.
| Protocol | Needs passthrough? | Why |
|---|---|---|
| WireGuard | No | Plain UDP |
| OpenVPN | No | Plain UDP or TCP |
| IKEv2 with NAT-T | No | ESP wrapped in UDP 4500 |
| L2TP/IPsec without NAT-T | Yes | Raw ESP, no ports |
| PPTP | Yes | GRE, no ports — also, do not use PPTP |
Why the advice persists
Worth a moment, because it explains a lot of bad troubleshooting generally.
Around 2010, VPN passthrough was a genuinely load-bearing setting. Corporate VPNs were PPTP or L2TP/IPsec almost universally, home routers varied in whether they handled those protocols, and “enable VPN passthrough” was correct advice that fixed real problems for a lot of people.
That advice got written down, copied into forum replies, and copied again. The protocols underneath changed completely; the advice did not, because nothing removes a forum post from a search index. You will find the same pattern with “disable QoS” and “change your MTU to 1492”, both of which were right for the DSL era and are now applied indiscriminately.
The practical lesson is to check what your VPN client is actually using before following any router advice. If the protocol dropdown says WireGuard, every suggestion involving GRE, ESP or passthrough is addressing a problem you do not have.
Where the setting lives
If you genuinely need it, it is usually under Advanced → NAT Forwarding → VPN Passthrough, Security → VPN Passthrough, or occasionally Firewall → ALG. The exact label varies more between firmware versions than between manufacturers, so search the admin page rather than following a path from a forum post.
You will typically see PPTP Passthrough, L2TP Passthrough and IPsec Passthrough as three independent toggles. On most consumer routers all three ship enabled, which is why enabling them rarely changes anything — they were already on.
What to check instead when a VPN fails
Passthrough is close to the bottom of the list. In rough order of likelihood:
- Wrong protocol for the network. Some networks block UDP or non-standard ports entirely. Switch the client to OpenVPN over TCP on port 443, which looks like ordinary HTTPS traffic.
- A stale route from a previous session. The client crashed and left the routing table pointing at a dead adapter. Restart the client, then the device.
- MTU mismatch. Pages half-load and large transfers stall while small requests work. Lower the MTU to 1400 in the client’s advanced settings. How a VPN tunnel is constructed explains why the packet size changes.
- Double NAT. Two routers in series, usually your provider’s box plus your own. Put the provider’s box in bridge or modem mode.
- DNS resolving outside the tunnel. Looks like a connection problem but is not; checking whether the VPN is actually working separates the two.
The one case where it still bites
Running two or more devices on the same network connecting to the same L2TP/IPsec or PPTP server simultaneously. Even with passthrough enabled, many routers can only track a single session of these protocols at a time, because the identifiers they rely on are not unique per client.
The second connection kicks off the first, repeatedly, which looks like a flaky server rather than a router limitation. There is no setting that fixes this on consumer hardware. The answer is to move to a protocol that does not have the problem, which in 2026 means asking whoever runs that VPN server to modernise it.
Realistic expectations
If someone tells you to enable VPN passthrough to fix a WireGuard or OpenVPN connection, they are repeating advice from an era that ended around 2018. The toggle is almost certainly already on, and turning it on again will change nothing.
Leave it enabled. It costs nothing, and the one day you need to connect to an ancient corporate L2TP server, it will be there.