PersistentKeepalive parameter on the client side and ensuring symmetric return traffic paths through both VPS instances, you can force regular UDP heartbeat packets that prevent state table expiration on intermediate firewalls and routers.
Understanding Persistent Keepalive Behavior
WireGuard is designed to be connectionless, meaning it does not establish a handshake like TCP. Instead, it relies on periodic packet exchanges to keep NAT mappings alive. The PersistentKeepalive setting is crucial when a client sits behind a restrictive NAT or firewall that drops idle UDP flows after a few minutes. In a standard single-peer configuration, this works seamlessly because the client knows exactly which endpoint to contact. However, complications arise when a single client connects to two different VPS servers simultaneously, especially if only specific subnets are routed through each tunnel (split tunneling).
The core issue is that the operating system’s network stack may not correctly associate the keepalive packets with the correct peer interface if the routing tables are ambiguous. Without explicit keepalives, the connection appears dead to the remote VPS, and subsequent packets from the client are silently dropped by the intermediate network infrastructure until a new handshake occurs, which causes latency spikes and dropped sessions.
Why Split Tunneling Complicates Keepalives
In a split tunnel scenario, your client likely has routes directing traffic for Subnet A to VPS 1 and traffic for Subnet B to VPS 2. The problem often stems from how the kernel handles the default route versus specific subnet routes. If the client’s primary internet gateway is not the VPN interface, but the VPN interfaces are used for specific destinations, the keepalive mechanism might struggle to determine the outgoing interface for the UDP probe packets. This is particularly common on Linux systems where policy-based routing interacts poorly with WireGuard’s internal peer management.
Configuring Client-Side Keepalives Correctly
To resolve this, you must ensure that the PersistentKeepalive value is set in the [Peer] section of the client configuration file, not just the server files. This directive tells the client to send an empty encrypted packet to the peer every specified number of seconds. For most residential or mobile connections, a value between 25 and 30 seconds is optimal. It is frequent enough to keep NAT entries open but low enough to avoid excessive bandwidth usage.
- Edit the Client Config: Open your WireGuard client configuration file (usually located at
/etc/wireguard/wg0.confor similar). - Add the Parameter: Inside the
[Peer]block corresponding to each VPS, addPersistentKeepalive = 25. - Restart the Interface: Apply changes using
wg-quick down wg0followed bywg-quick up wg0.
This change forces the client to actively reach out to both VPS instances independently. Even if one path is temporarily congested, the other keepalive stream ensures that the respective NAT mapping remains valid. This approach is far more reliable than relying on application-layer heartbeats or waiting for data traffic to trigger the keepalive logic.
Verifying Routing Symmetry
Another critical factor in multi-VPS setups is ensuring that return traffic follows the same path as the outbound traffic. If your client sends a packet to VPS 1 via Interface A, but the response comes back via Interface B due to dynamic routing changes, the connection will fail. You should verify your routing tables using ip route show to confirm that specific subnets are bound to their respective WireGuard interfaces.
If you find that the default route is pointing to a physical NIC while VPN routes point to virtual interfaces, consider using policy-based routing. This ensures that traffic destined for VPS 1 always egresses through the correct tunnel interface, allowing the keepalive packets to traverse the exact same path as your application data. This symmetry is vital for maintaining stable connections across diverse network environments.
Checking for Intermediate NAT Issues
Sometimes, the issue lies not with the client configuration but with the network between the client and the VPS. Enterprise networks or certain ISPs may drop UDP packets that do not look like typical DNS or DHCP traffic. In such cases, increasing the keepalive interval slightly or enabling UDP encapsulation on non-standard ports can help bypass deep packet inspection filters. However, this is less common than simple routing asymmetry.
Troubleshooting Connection Drops
If the keepalive still does not work, check the logs on both the client and server sides. On Linux, use journalctl -u [email protected] to view real-time events. Look for messages indicating "peer failed to respond" or "handshake timeout." These errors suggest that the packets are being sent but not received, pointing strongly to a firewall or routing blockage rather than a configuration error.
Additionally, ensure that no other software, such as a secondary VPN client or aggressive power-saving modes on network adapters, is interfering with the WireGuard interface. Disabling wake-on-lan for the network adapter and ensuring that power management settings allow full performance can sometimes resolve intermittent connectivity issues that mimic keepalive failures.
Securely Accessing the Internet via 2-Hops WireGuard VPN on Windows 11 and Two VPS Servers provides additional context on managing complex multi-hop scenarios where routing decisions become even more critical. Similarly, Troubleshooting Wireguard Peer Unable to Access Internet Without DNS Entry highlights how misconfigured peers can lead to apparent connectivity loss despite successful tunnels.Frequently Asked Questions
Why does my WireGuard connection drop only during idle periods?
This happens because NAT devices and firewalls expire inactive UDP session entries after a timeout period, typically ranging from 30 seconds to several minutes. Without periodic traffic, the router forgets how to forward incoming packets back to your client, causing subsequent attempts to fail until a new handshake is initiated.
Can I use Persistent Keepalive on the server side instead of the client?
No, the PersistentKeepalive directive is intended for the client configuration. The server generally maintains open ports and does not need to initiate keepalives unless it is also acting as a client to another node. Setting this on the server has no effect on the client’s ability to traverse NAT.
What is the ideal value for Persistent Keepalive?
A value of 25 seconds is widely recommended as it balances battery life on mobile devices with the need to keep NAT mappings fresh. Values lower than 10 seconds may waste bandwidth, while values higher than 60 seconds risk connection drops during periods of high network latency or brief disconnections.
Does split tunneling affect the effectiveness of keepalives?
Split tunneling itself does not break keepalives, but it can complicate routing if the default gateway is not aligned with the VPN interface. If the OS cannot determine the correct outgoing interface for the keepalive packet, it may send it to the wrong place, causing the keepalive to fail effectively.
How do I verify if keepalives are actually being sent?
You can use tools like tcpdump or tshark on the client machine to monitor traffic on the WireGuard interface. Filter for UDP port 51820 and observe if small packets are being transmitted periodically, confirming that the keepalive mechanism is active and functioning as expected.