VPN on the Router vs a Port Forward: Which One Wins?

The router terminates the VPN itself, and an old forwarding rule still sends the same UDP port to a machine on the LAN. Only one of those can be the real endpoint, and the kernel does not arbitrate. Destination translation rewrites the packet before the local service is consulted, so the VPN process waits for traffic that has already been sent elsewhere. The task is to decide who owns the port, then make the rules agree.

One port, two claimed owners

A VPN server running inside the router needs an inbound permission that leads to its own socket. A destination-NAT entry for the same port leads somewhere else entirely: a LAN address and a forwarding decision. Those are different endpoints with different logs and different failure modes. The usual clue is that one address family works and the other does not, because the leftover entry was written for a single family and never revisited.

Write down the claim before editing: family, external address, transport, port, and the translated target.

Translation runs before the local check

Destination NAT changes the packet's target in the prerouting stage, before the kernel chooses between local delivery and forwarding. Once the target is a LAN host, the packet takes the forward path. Input rules for the router's own socket are never consulted, which is why the VPN log stays empty while the client times out.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

That ordering is the entire mechanism, and appliance interfaces hide it behind checkboxes without changing it. The destination owner still decides which path a packet takes.

If the LAN host is the intended endpoint, the forward is correct and the router should not also be listening on that port.

Keep one mapping and remove the other

List the NAT entries for that port and family and pick the survivor:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

A TCP entry with the same number is irrelevant to a UDP failure, and treating them as one object leads to deleting the wrong rule. When the local socket should win, the owner of the conflicting mapping removes or rewrites that one entry, and the inbound permission for the router's own port stays in place. Unrelated forwards, the management path, and a copy of the ruleset should all survive the change.

If the VPN lives on a separate host, the forward is the right object. A service in a container or virtual machine may need a published port even when the box is called the router, so trace the socket and its namespace rather than the label on the case.

Confirm the owner from outside

Test each family separately, because an IPv6 connection that terminates on the router says nothing about an IPv4 connection that a stale rule redirects. Read the receiving service's log to see which endpoint answered, and treat the client's success message as weak evidence. A new flow is required for a meaningful test. Send a probe from an outside host with nc -zvu 203.0.113.7 1194 and read the winner log with journalctl -u openvpn@server -n 20. The router listener logs the connection itself, while a LAN host logs it in its own service.

Connection tracking keeps existing flows on their original mapping, so an established session can outlive the rule you just fixed.

Once the intended endpoint answers with its normal identity checks, test a private resource behind the tunnel. Reaching the outer listener is only the first hop; inner routing and application authorization are separate outcomes.