UFW VPN Exception When the Endpoint Address Changes

The client tries to reconnect and nothing leaves the machine, even though the same profile worked last week. The endpoint hostname now resolves to a different address, and the outbound exception still names the old one. That single stale permission is enough to turn a working kill switch into a total outage, and it is invisible in every status indicator the desktop shows. The repair is a small workflow rather than a one-line edit.

The Tunnel Reconnects, Then Nothing Leaves

An outbound rule that names a destination address is a snapshot, and DNS answers are not. When the provider rotates an address, the packet the client sends toward the new peer matches nothing and is dropped by the default deny. The client then reports a timeout, which reads like a server problem rather than a firewall one.

Pinning whatever address a public lookup returns makes today work and leaves tomorrow broken. That is a one-off edit, not a maintenance policy.

Describe the Exception You Actually Intend

Start by writing down the four values the rule needs: the approved endpoint name or address set, the transport, the destination port and the interface the packet leaves through. All four are part of the permission, and any of them can be wrong while the rule still looks plausible. A rule that is correct on three of them fails in exactly the same way as a rule that is wrong on all four. Write them down before typing the command, because a rule is only as good as the description behind it.

The command below shows the shape for one IPv4 UDP endpoint on a wired uplink. Replace both values with the ones you verified against the deployment.

sudo ufw allow out on enp3s0 proto udp to 192.0.2.44 port 1194
sudo ufw status verbose

That permission does not authorise arbitrary destinations on the same port, does not create a listener and does not cover TCP. The UFW manual page describes how address, interface and protocol narrow a rule, and the narrowing is the whole point.

Refresh It as One Workflow

Treat the exception as a resource with an owner and a transition, not as a command someone remembers to run. First obtain a candidate from the deployment's own resolver and endpoint inventory, and define deliberately how that name is resolved before the tunnel exists. Then validate the candidate against the intended protocol, port and address family before touching the ruleset.

Install the new narrow permission first, and confirm it loaded, because asking the client to use an address the firewall still blocks produces a failure that looks like a server fault. Keep unrelated rules untouched during the change.

Observe the client's transition through its supported reconnect path and confirm which remote address it selected. Updating DNS alone does not move an existing socket, and an endpoint-persistence setting can keep the client on the old peer long after the record changed.

Finally retire the obsolete permission on purpose, allowing for the approved overlap window while an old session is still active. Removing the old entry too early produces a brief outage; leaving it forever leaves a permission nobody can explain.

Retire the Old Permission on Purpose

Removal is where most of the risk sits, because the old rule is the only thing currently working. If installing the candidate failed, do not continue and delete the entry that still carries traffic. If the removal itself fails, record the stale permission as stale instead of declaring the policy current.

Repeat the whole review when the uplink changes from Ethernet to Wi-Fi, when the transport changes, or when a service rotates across several addresses. An interface-specific rule is supposed to stop matching after a network change, and that behaviour is correct even though it looks like a regression.

Prove the contract with harmless traffic afterwards. The approved endpoint must be reachable during setup, the protected application must work once connected, and unrelated direct traffic must stay blocked during an outage. Include both address families and one deliberately failed update attempt, since a connection that succeeds after a single pinned-address edit proves none of those cases.