Who Owns the Address, Route, DNS and Firewall on a Linux VPN?

Two scripts fighting over the same route is the usual shape of a Linux VPN problem that gets filed as a routing bug. One component creates the tunnel device, another adds a default route, a third rewrites the resolver configuration, and a fourth reloads firewall rules. Any of them can undo another's work, and the winner is simply whoever ran last. The question worth answering is not which package to install but which component is authoritative for each piece of state.

Write that map down once and most reconnect failures stop being mysterious. Four objects matter: the device and its addresses, the routes and policy rules, the DNS configuration, and the firewall.

The device and its addresses

A tunnel device is created either by a manager that knows the profile or by a daemon someone started by hand. Both arrangements work on their own; mixing them does not. If NetworkManager owns the profile, let it own the device as well, and do not start an unmanaged OpenVPN process against the same tunnel name.

Record who removes the device when the session ends. A device that outlives its session is the most common source of stale addresses and of the confusion that follows them.

Routes and policy rules

Routes are where ownership conflicts do visible damage. A connection manager installs a default route for the tunnel plus a more specific route for the remote network; a hand-written script then adds its own default with a different metric and quietly wins or loses depending on timing. Decide which entries are connection-scoped, which are permanent policy, and which component refreshes them after a reconnect. Then make the other components stay out of that table.

Policy rules deserve the same clarity, because a rule pointing at a table nobody fills produces a black hole that looks exactly like a dead tunnel. If a rule exists to force traffic somewhere, the table it selects has to be maintained by the same owner.

DNS is always a separate owner

A resolver daemon runs as its own process under its own identity, so it does not inherit the tunnel's routing decisions by accident. When the VPN pushes DNS servers, something must translate that into per-link configuration the resolver honours, and something must take it away afterwards.

The myth here is that writing a nameserver into the profile changes where queries go. It changes what the resolver is told, not which socket the resolver uses upstream. Test with a query plus a route lookup instead of trusting the file.

Firewall state, and who restores it

Firewall rules are the most frequently overwritten object on a VPN host. A manager may add NAT or forwarding rules per connection while a boot-time firewall service reloads a saved ruleset and erases them. Choose one authority for policy and make the other a consumer of it, or accept that a reboot silently changes behaviour. Connection-scoped exceptions belong in a file the same owner loads, not in an iptables command typed during troubleshooting.

If rules must survive a reconnect, say so explicitly. If they must not, say that too, because the next engineer will assume whichever answer is more convenient.

Lifecycle: boot, reconnect, teardown

Give each of those three moments an owner. At boot, decide what prepares prerequisites and in what order. On a soft restart, remember that the device may survive while the session state does not, so a validator has to run rather than a creator. At teardown, remove only what this connection created, because resetting every route or flushing the whole firewall is not the same as retiring one tunnel.

For observation, ip monitor link address route shows kernel changes as they happen, but it reports events rather than intent: a deleted route says nothing about which process deleted it. Pair it with the ownership map and a confusing shutdown becomes a short list of candidates.

Exclusions carry a cost too. Marking an entire device class unmanaged to escape a conflict hands that state to nobody, which is a decision rather than a fix.