Why Port Forwarding Breaks Behind a VPN

Port forwarding tells your router to send unsolicited inbound connections on a given port to a specific device on your network. It works because your router holds the public address the internet reaches you at. Connect a VPN and that stops being true: inbound connections now arrive at the VPN server’s address, and your router’s rules never get consulted.

The rules are not wrong. They are simply not on the path any more, which is why re-checking them endlessly gets you nowhere.

What forwarding does normally

Translation is one-way by default. When a device on your network reaches out, your router notes the connection and knows where to send the reply. When something on the internet initiates a connection to your public address, there is no note — the router does not know which of your devices it is for, so it drops it.

A forwarding rule supplies the missing information in advance: traffic arriving on this port goes to this device. That is what makes a game server, media server, or remote-access service reachable from outside.

The whole mechanism depends on your router holding the address the internet contacts. That is the assumption a VPN breaks.

What changes when the tunnel comes up

Your traffic leaves from the VPN server’s address, so that is where anyone trying to reach you goes.

Outbound connections still work, because the tunnel creates a return path for anything you initiate. Inbound connections fail at the VPN server: it received a connection on some port with no instruction about which of its many connected users it belongs to, so it drops it. Your router never sees the attempt.

There is a second complication on the device itself. With the default route pointing into the tunnel, a service listening on your machine may send its replies out through the tunnel even for connections that arrived on the local network — producing connections that establish and then behave strangely. The two-adapter arrangement behind this is described in why a VPN gives you two IP addresses.

The other reason it might not work

Carrier-grade NAT breaks forwarding on its own, with no VPN involved. If your provider puts many customers behind one shared public address, your router does not hold a reachable address either, and the provider’s translation layer has no rule pointing at you.

The symptom is identical to the VPN case, so establish which one you have before troubleshooting. Compare what your router reports as its WAN address against what the internet reports for you: if they differ, you are behind carrier-grade NAT and forwarding was never going to work regardless of the VPN.

It is also possible to have both problems at once, in which case the VPN is the more tractable of the two.

Working out which layer is failing

Test in a fixed order so each step eliminates one possibility.

1. Disconnect the VPN and test. If forwarding works, the VPN is the cause and the rest of this applies. If not, the problem is upstream of the VPN entirely.
2. Compare your router’s WAN address with your public address. A mismatch means carrier NAT.
3. Test from inside your own network. If the service is unreachable even locally, the problem is the service or the device’s firewall, not forwarding.
4. Check the device’s own firewall. Operating system firewalls block inbound connections by default and are a frequent cause independent of everything above.
5. Check whether the VPN client blocks local network access. Some clients do, which breaks local reachability while the tunnel is up.

Most time lost to this problem is lost by re-editing correct router rules. The ordering above prevents that by testing the assumptions the rules depend on before the rules themselves.

The options that actually work

Ranked by how well they preserve what you wanted.

A VPN provider that supports inbound port forwarding. Some do: they assign you a port on the server and route inbound traffic on it through your tunnel. This is the only approach that keeps the tunnel up and makes the service reachable, and it works even behind carrier NAT. Many providers deliberately do not offer it, so it is a selection criterion rather than a setting.

A dedicated address with inbound support. Where offered, this gives you a stable address at the provider’s location that can accept connections — the practical case made in shared vs dedicated VPN IP addresses.

Split tunnelling to exclude the service. Keep the tunnel for everything else and route the specific application or device outside it, so it uses your router’s address and existing forwarding rules. The tradeoff is that this traffic is not protected — see split tunnelling for the general mechanism.

A relay or tunnel service for the specific application. Remote-desktop and camera products commonly offer one. It avoids network surgery and works from behind almost anything.

Run the VPN on the router with care. Putting the tunnel on the router means all devices are behind it, so this does not fix inbound reachability by itself — but router firmware often lets you exclude specific devices from the tunnel, which achieves split tunnelling at the network level.

What not to do

Do not disable the tunnel and forget. If the reason you run a VPN is that you do not want your address exposed, turning it off to make a service reachable exposes both the address and everything else. Exclude the one service instead.

Do not open more ports than the service needs. Forwarding removes the router’s default protection for whatever it covers. One port for one service, pointed at one device.

Do not use the universal automatic-forwarding feature as a fix. It lets applications open ports without asking, which is convenient and a poor security posture, and it does not work through a VPN anyway.

The summary worth remembering

Forwarding is a rule on the device that holds your public address. A VPN moves that address to a machine you do not administer, so the rule is on the wrong box.

Everything that works follows from that: either get the VPN provider to hold a rule for you, or keep the relevant traffic on your own address. There is no third option, and no amount of correct router configuration will produce one.