VPN Passthrough: What It Does and When It Matters

A router with a “VPN passthrough” setting is usually a router that is old, cheap, or both. The setting exists because two VPN protocols from the 1990s—PPTP and IPsec—break when their traffic is translated by NAT. If a machine on the LAN cannot establish a VPN connection to a remote server, and the router has a passthrough toggle, this page explains what that toggle does, when flipping it helps, and when the problem lies elsewhere.

The symptom is specific: the VPN client on a PC or phone fails to connect, or connects and then drops after a few seconds. Other internet traffic works. The failure is often intermittent—the tunnel establishes, then dies the moment the first data packet is sent. That pattern points at NAT mangling the VPN’s addressing or integrity checks, not at the VPN server or the client’s credentials.

What VPN Passthrough Actually Does

NAT (Network Address Translation) rewrites the source IP and port of every outbound packet so that many private addresses can share one public IP. For most protocols this is harmless. PPTP and IPsec are not most protocols.

PPTP wraps its data in GRE (Generic Routing Encapsulation). GRE is not TCP or UDP; it has no port numbers. NAT has no way to track a GRE session the way it tracks a TCP connection, so the return GRE packets arrive at the router with no mapping to the machine that sent them. The router drops them. PPTP also uses a TCP control connection on port 1723, which NAT can track, but the data channel is the GRE problem.

IPsec has two modes. In transport mode, the IP header is authenticated by the AH (Authentication Header) protocol or by ESP (Encapsulating Security Payload) with integrity checking. NAT changes the IP header, so the integrity check fails and the packet is discarded at the receiver. IPsec also uses UDP port 500 for IKE (key exchange) and UDP 4500 for NAT traversal, but if the VPN server or client does not support NAT-T, the ESP packets (protocol 50) arrive with no port information and NAT cannot map them.

A “passthrough” setting on a router does one of two things:

• It enables special handling for GRE and ESP so the router can track those sessions and forward them to the correct LAN machine.
• It enables IPsec NAT-T (UDP 4500) so that IPsec packets are wrapped in UDP and can be NATed normally.

On a modern router, this handling is built in and always on. The toggle is a legacy feature.

The Setting on Modern Routers

Most routers manufactured in the last decade do not expose a VPN passthrough setting at all. They handle GRE and ESP transparently, or they support NAT-T for IPsec. If a router has a passthrough toggle, it is usually in the “Advanced” or “Security” section, and it is often enabled by default.

If the toggle exists and is off, turn it on. That is the only case where the setting is the cause of the failure. If the toggle is already on, or if there is no toggle, the problem is something else.

When the Setting Is Irrelevant

There are several cases where VPN passthrough has no bearing on the connection:

• The VPN uses SSL/TLS (OpenVPN, WireGuard, SSTP). These protocols run over TCP or UDP with ordinary port numbers. NAT handles them without any special support. A passthrough setting does not apply.
• The router is behind a carrier-grade NAT (CGNAT). If the ISP assigns the router a private IP address (typically 100.64.0.0/10), the router’s public IP is shared with other customers. Inbound VPN connections from the internet will not reach the router unless the ISP provides port forwarding or a public IP. No router setting can fix that.
• The VPN server is on the LAN and the client is on the internet. This is an inbound connection. Passthrough is for outbound connections from the LAN to a remote server. For inbound, the router needs port forwarding or a DMZ, and the protocol must be one that can be forwarded (OpenVPN over TCP, for example). PPTP and IPsec inbound are difficult to forward and often unsupported.
• The failure is on the VPN server side. If the server’s firewall blocks the protocol, or the server does not support NAT-T, the client will fail regardless of the router.

Troubleshooting Steps

Work through these in order. Each step is non-destructive unless stated otherwise.

1. Confirm the VPN Protocol

Check the VPN client’s configuration to see which protocol it uses. If it is OpenVPN, WireGuard, or SSTP, skip the rest of this page—the router’s passthrough setting is not involved. The problem is elsewhere (firewall, server, or credentials).

If the protocol is PPTP or IPsec, continue.

2. Check the Router’s Passthrough Setting

Log into the router’s web interface and look for a setting named “VPN Passthrough,” “PPTP Passthrough,” or “IPsec Passthrough.” If it is off, turn it on and save. Then retry the VPN connection.

If the setting is already on, or if it does not exist, move on.

3. Test with a Different Network

Connect the same device to a different network—a phone hotspot, a friend’s Wi-Fi, a wired connection at work. If the VPN works there, the problem is on the original network, likely the router. If it fails there too, the problem is the client or the server.

4. Check for NAT-T Support

For IPsec, both ends must support NAT-T (UDP 4500). Most modern IPsec implementations do, but some older ones do not. If the VPN server is old or the client is an old OS, NAT-T may be disabled. There is no router setting that forces NAT-T; it is negotiated between client and server.

5. Check the ISP’s Network

If the router’s WAN IP is in the 100.64.0.0/10 range, the ISP is using CGNAT. In that case, outbound VPN connections may work (the client initiates), but inbound connections will not. For outbound PPTP or IPsec, CGNAT can still break them if the ISP does not handle GRE or ESP. Contact the ISP to ask whether they support PPTP or IPsec passthrough. If they do not, the only fix is a business plan with a public IP.

6. Check the Windows Firewall

On a Windows machine, the built-in firewall may block GRE or IPsec. Open an elevated Command Prompt and run:

netsh advfirewall firewall add rule name="PPTP" protocol=47 dir=in action=allow
netsh advfirewall firewall add rule name="IPsec ESP" protocol=50 dir=in action=allow

These commands add inbound allow rules for GRE (protocol 47) and ESP (protocol 50). The output should say “Ok.” for each. This is safe and reversible; to remove the rules later, use netsh advfirewall firewall delete rule name="PPTP" and similarly for the IPsec rule.

If the VPN still fails, remove those rules—they are not the cause.

7. Test with a Direct Connection

If the router has a DMZ feature, temporarily place the VPN client’s IP in the DMZ. This forwards all inbound traffic to that machine, bypassing NAT. If the VPN works then, the router’s NAT is the problem. Remove the DMZ entry afterward. This is a diagnostic step, not a permanent fix.

8. Update the Router Firmware

Router firmware updates sometimes fix NAT handling bugs. Check the manufacturer’s site for a firmware file that matches the router model. Flashing firmware is riskier than other steps; follow the manufacturer’s instructions exactly. A failed flash can brick the router.

Comparison: When Each Fix Applies

What People Get Wrong About VPN Passthrough

The most common mistake is assuming that a VPN passthrough setting is the universal fix for any VPN failure. It is a natural assumption: the setting’s name suggests it enables VPNs. In reality, the setting only affects two legacy protocols, and on modern routers it is either absent or already enabled. A user who spends an hour hunting for a toggle on a router that does not have one is not stupid—the name is misleading.

Another common error is confusing outbound and inbound VPN. Passthrough is for outbound connections. If the goal is to connect to a home VPN server from outside, the router needs port forwarding, not passthrough. The two are often conflated in forum posts.

A third misdiagnosis is blaming the router when the ISP is the culprit. CGNAT is invisible to the user; the router shows a public IP that is actually shared. No router setting can overcome CGNAT. The fix is an ISP change, not a router change.

Finally, some users believe that disabling NAT or placing the router in “bridge mode” will solve VPN issues. Bridge mode turns the router into a dumb modem, which may help if the router’s NAT is broken, but it also disables all routing and firewall features. It is a drastic step that should only be taken after confirming the router is at fault.

When the Problem Cannot Be Fixed from the Router

If the ISP uses CGNAT and does not support GRE or ESP passthrough, no router setting will help. The only options are to request a public IP from the ISP (often a business plan) or to use a VPN protocol that works over CGNAT, such as OpenVPN or WireGuard.

If the VPN server does not support NAT-T, and the client cannot be configured to use it, the connection will fail regardless of the router. The server administrator must enable NAT-T or use a different protocol.

In both cases, the equipment that needs changing is not the router. The reader should contact the ISP or the VPN provider, not keep adjusting the router.

Related Pages

• For a deeper explanation of NAT and why it breaks certain protocols, see What Is NAT? and Port Forwarding.
• If a second tunnel is the problem rather than the first, see Multiple VPN Connections.

FAQ

What is VPN passthrough?

VPN passthrough is a router feature that allows PPTP and IPsec VPN traffic to traverse NAT. It enables the router to forward GRE and ESP packets correctly. On modern routers, this is usually built in and always on.

Why does my VPN fail when the passthrough is on?

If the passthrough is on and the VPN still fails, the problem is likely elsewhere: the VPN protocol is not PPTP or IPsec, the ISP is using CGNAT, the server does not support NAT-T, or the client’s firewall is blocking the traffic. Follow the troubleshooting steps to isolate the cause.

Do I need VPN passthrough for OpenVPN or WireGuard?

No. OpenVPN and WireGuard use standard TCP or UDP ports, so NAT handles them without any special support. The passthrough setting is irrelevant for those protocols.

How do I know if my ISP is using CGNAT?

Check the router’s WAN IP. If it is in the range 100.64.0.0 to 100.127.255.255, the ISP is using CGNAT. You can also search online for “what is my IP” and compare the public IP to the router’s WAN IP; if they differ, CGNAT is likely in use.

Can I fix VPN passthrough on a router that doesn’t have the setting?

If the router lacks the setting, it likely handles VPN traffic automatically. If VPN still fails, the issue is not the passthrough setting. Try updating the router firmware, checking the Windows firewall, or contacting the ISP about CGNAT.