UDP VPN Stalls When Idle: The Firewall Forgot Your Flow

The VPN connects, works for a while, and then stops passing traffic while the client still shows a session. Reconnecting fixes it, which makes it look like a client bug. It is usually a firewall or NAT device that dropped an idle UDP mapping and has no idea the tunnel still exists.

The symptom is consistent enough to diagnose: it appears after inactivity, not under load.

What an idle stall looks like

Measure it instead of describing it. Note how long the tunnel sits idle before traffic stops, whether a new outbound packet revives it, and whether the client interface still holds its address. If a fresh request from the client works but a reply to an existing flow does not, the mapping is the suspect. If nothing works until you reconnect, the client's session state is gone too.

Both are idle-related, and they need different fixes.

Write the timings down before you change anything. A report that it stops after roughly ten idle minutes is testable, while a report that it drops randomly is not. That difference decides whether you chase a timer or a routing change.

Find the device that forgot

Several devices can hold state for the same flow: the local router, an upstream translator, a cloud boundary and the host firewall. Each has its own timer, and the shortest one wins. A five-minute outage usually means one device was configured well below the others.

Do not assume a documented default is the timeout on your path. It is one device's default.

• Home router: often minutes, occasionally far less.
• Cloud NAT or load balancer: look up the documented idle timeout for UDP specifically.
• Host firewall: netfilter tracking timers apply per flow.

Check the timers on the actual path

On Linux, the netfilter tracking timers are visible and adjustable: sysctl net.netfilter.nf_conntrack_udp_timeout and net.netfilter.nf_conntrack_udp_timeout_stream. The second applies once traffic has been seen in both directions, which is why an established tunnel can outlive a bare probe.

RFC 4787 sets out UDP NAT behaviour and recommended minimums. It is the reference to quote when a vendor default looks unusually short.

Keepalive and reconnect are different tools

A keepalive keeps a mapping alive; a reconnect rebuilds a dead session. They solve different failures and are not interchangeable speed settings. WireGuard's PersistentKeepalive sends a packet at a fixed interval to hold the NAT binding open. OpenVPN's keepalive option does the same job in its own way. Neither helps if the device in the middle has already forgotten the flow and is dropping both directions.

Extremely frequent probes add work without fixing the wrong boundary.

Verify with a new request, not a page reload

After changing a timer or adding a keepalive, repeat the idle scenario exactly as before. Then make a genuinely new request from the covered application. A browser tab that was already loaded can render from cache and tell you nothing.

If the stall persists, move one hop outward and check that device's state table.