Keep nftables Policy Stable While the VPN Interface Comes

Tunnels are disposable; policy should not be. On a Linux gateway an nftables rule that matches the tunnel interface by name can be loaded once and keep applying each time that interface appears. The interface still owns a lifecycle: it is created, it goes away, and the routes and translations around it follow their own schedule. Separating those owners is what keeps access stable during a reconnect.

A name match outlives the interface

nftables offers numeric interface-index matches and the dynamic name matches iifname and oifname. Rules using those names load cleanly even when the tunnel device has not been created yet, which is exactly what a boot-time ruleset needs. It stops matching if the interface is renamed and resumes when a new interface takes that name. A numeric index lacks that property, which is why the name form is the usual choice for a tunnel.

The name is a matching key, not evidence about who is on the other end. Peer authentication stays the VPN's job.

Read the chain before adding rules

Look at what the ruleset currently contains and where a new rule would sit, because order decides the outcome.

nft list ruleset
nft -c -f /etc/nftables.conf

The listing shows chains, rules and handles, and check mode validates a candidate file without loading it. A tunnel-only allowance placed after an earlier accept for the same flow changes nothing, since the first matching rule wins. That is why a late rule can look correct and have no effect. Read the chain in order and confirm the deny for client-to-uplink traffic still precedes anything broader.

Routes, translation and flows have other owners

Interface presence creates no routes, and it does not authenticate the peer. Those belong to the VPN manager, while translation has a third lifecycle.

conntrack -L -s 10.20.0.0/24 | head
ip route show dev vpn0

The conntrack listing shows existing flows with their original and translated tuples, and the route listing shows what the manager installed for the interface. NAT rules establish connection-tracking state on the first packet, so an established flow keeps its translation even after the rule changes. That is why a rule being updated and a flow using the new path are different statements. Decide which sessions must reconnect and leave unrelated flows alone.

Accept cold start, loss and recovery

Test the gateway with the tunnel absent at boot, then with it present, then after a drop and a return. Confirm that forbidden forwarding stays denied while the tunnel is missing, that a new allowed flow works once the peer is authenticated, and that recovery does not require flushing unrelated state. Do not clear the whole POSTROUTING chain or every conntrack entry as one profile's stop action, because other services share them. Record which component changed the interface, the route and the policy, rather than only that a start hook exited zero.

A policy that survives a reconnect is one whose owners are named and whose rules were tested with the tunnel both down and up. A hook that reports success proves only that the hook ran.