The problem it was invented to solve
A home router performs network address translation: many devices behind one public address, with the router rewriting port numbers to keep track of which reply belongs to which device. That works because TCP and UDP carry port numbers the router can rewrite.
PPTP and IPsec do not use ports in the ordinary way. PPTP carries its data inside GRE, protocol 47, which has no port field at all. IPsec in its native mode uses ESP, protocol 50, likewise. A router with nothing to rewrite cannot tell which internal device an inbound packet belongs to, so it drops it, and the tunnel fails to establish or dies seconds later.
VPN passthrough is the router vendor’s workaround: special-case handling that inspects these protocols and tracks sessions by something other than a port number. PPTP passthrough follows the GRE call ID. IPsec passthrough follows the ESP security parameter index. Neither is elegant, and both were bolted on because the alternative was telling customers their VPN did not work.
Why it is almost certainly irrelevant to you
WireGuard runs over plain UDP, usually on port 51820. OpenVPN runs over UDP 1194 or TCP 443. Both are ordinary transport protocols with ordinary port numbers, so NAT handles them the way it handles everything else. There is nothing to pass through.
Every provider we cover ships WireGuard and OpenVPN. None requires PPTP, and PPTP should not be used regardless: its MS-CHAPv2 authentication was broken comprehensively in 2012 and has been unsafe for anything since. If a VPN service still advertises PPTP as a feature, that tells you something about the service.
So the practical answer to "should I enable VPN passthrough" is that it will not hurt and it will not help, unless you are connecting to a corporate IPsec gateway that predates the current decade.
Avoid
- Enabling passthrough to fix a WireGuard or OpenVPN problem — it addresses neither
- Using PPTP because passthrough made it connect; connecting is not the same as being secure
- Assuming a disabled passthrough setting is why a modern VPN app fails to connect
When it genuinely still matters
Corporate remote access is the real remaining case. Plenty of enterprise IPsec gateways still expect native ESP, and a home router with IPsec passthrough disabled will break that connection while leaving everything else working. If your work VPN fails at home but succeeds when tethered to a phone, the router is the first thing to check.
The other case is multiple simultaneous connections to the same gateway. Early passthrough implementations could track exactly one session, so a second device connecting to the same corporate endpoint would knock the first one off. Most modern routers handle several; some budget models still do not, and the symptom is one person in the household dropping whenever another connects.
- Corporate IPsec gateways that do not support NAT traversal, standardised in RFC 3947 back in 2005
- Older site-to-site tunnels between office locations
- Any setup where you cannot change the protocol because you do not control the far end
What to do instead
If you control both ends, use WireGuard. It sidesteps the entire problem, is considerably faster than anything it replaces, and needs no special router handling. Every provider we cover offers it.
If the far end is a corporate gateway you do not control, ask whether it supports NAT traversal — IPsec over UDP 4500, which wraps ESP inside UDP precisely so NAT can handle it. It was standardised in RFC 3947 back in 2005 and works with IKEv1 as well as IKEv2, so gateway age is not the excuse it is often made into.
If neither is available, enable IPsec passthrough and accept that you are relying on vendor-specific special-case code whose quality varies considerably between router models.