Web Server Goes Dark When the VPN Client Connects

A service that disappears the moment a VPN client connects is usually not being blocked, it is answering through the wrong interface. The request arrives on the physical NIC, the daemon writes a reply, and the routing table hands that reply to the tunnel, since the tunnel has taken over the default route. The remote client never sees an answer to a connection it opened, so it waits and then reports a timeout. No firewall rule is involved anywhere in that sequence.

The Symptom: Requests In, Replies Out the Wrong Door

The tell is an inbound connection that fails while everything else on the host works. Another giveaway is a host reachable from the LAN but not from the internet, or one that works until the tunnel reconnects and then stops. In each case the forward direction behaved and the return direction did not, which points at routing asymmetry rather than at policy.

Confirm it by watching where the reply goes, not by watching the request arrive.

Capture on the physical interface and on the tunnel device at once. If the request appears on the physical interface and the reply appears on the tunnel, the diagnosis is finished. A reply that appears nowhere means the service never accepted the connection, which is a separate investigation with a separate cause.

Two Default Routes and One Routing Decision

A client that installs a default route adds a second entry with a better metric than the LAN gateway. Some clients install two half-range routes instead, which cover the same space more specifically and win the lookup the same way. Either technique leaves ordinary outbound packets choosing the tunnel interface.

That choice is made by destination alone. The kernel does not ask where a packet came from unless a policy rule tells it to. So the reply to a public client address is handed to the tunnel, whose far end receives a packet with a source address it does not own and discards it or forwards it somewhere useless. On Linux, strict reverse-path filtering can also drop the original request before your service ever sees it, which looks identical from the outside. Both symptoms come from the same missing association between an incoming flow and its reply.

The tunnel behaves correctly throughout. It was told to carry the default route and it does exactly that.

Fix the Return Path Without Breaking the Tunnel

Three durable shapes of repair exist, and the choice depends on how much of the host's own traffic should stay inside the tunnel. Excluding the service's destination or port is the smallest change. Policy routing by source or mark is the most precise. Source translation is the bluntest and the easiest to explain two years later.

Choose by what the host must do, not by which snippet you found first.

Excluding a destination suits a service with a stable public address, and binding the daemon to the physical address rather than to every address makes that exclusion safer. A policy rule selecting a table by source keeps the host's own connections inside the tunnel while returning service replies through the WAN gateway. Masquerading replies to the WAN interface reaches the same path at the cost of hiding the client's address from the service logs. An ad-hoc default route change is a diagnostic and not a configuration, because the client rewrites routes on every reconnect.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

When the Host Also Routes for a LAN Behind It

One hop further out, the same asymmetry returns with more moving parts. Traffic reaches the router from the internet, is forwarded to an internal device, and that device's only path back is the tunnel, so the answer reaches the original client from the provider's own address. Connection tracking then meets a reply for a flow it never saw start, and discards it. The client, meanwhile, sees nothing at all.

Two changes repair it: destination translation so the inbound connection reaches the internal device, and source translation so that device's reply appears to come from the router itself.

On router firmware the usual expression is a policy rule pinning the port-forward to the WAN side while the router's own traffic rides the tunnel. Without source translation, that reply is addressed to the external client and the internal device simply has no route to it. Test three things separately, because they fail for different reasons: a connection arriving from outside, one the host originates itself, and a name lookup.