PiVPN Connection Drops Exactly 3 Minutes After Successful Setup

A PiVPN connection dropping exactly three minutes after establishment is typically caused by stale NAT table entries or aggressive firewall timeouts clearing the UDP state before the session can sustain itself. This specific timing indicates that the router or the Raspberry Pi’s own netfilter rules are aggressively pruning inactive or semi-active connections, effectively killing the tunnel just as it becomes usable. The most common culprit is the iptables rule managing packet forwarding not accounting for the keep-alive nature of OpenVPN, leading to premature termination of the client's data stream.

Understanding the Three-Minute Timeout Symptom

The precise three-minute (180-second) drop is a strong indicator of a stateful inspection timeout rather than a general network instability. When a VPN client connects via UDP, the initial handshake establishes the tunnel, but subsequent traffic may appear "idle" to intermediate firewalls if no continuous heartbeat is detected at the IP layer. Many consumer-grade routers and even the Raspberry Pi’s default Linux networking stack have a default UDP connection tracking timeout set to 180 seconds. If the VPN client does not send packets frequently enough to refresh this state, the firewall drops the entry, severing the connection. This behavior is distinct from random disconnects caused by poor Wi-Fi signals or ISP fluctuations, which usually occur at irregular intervals. It also differs from authentication failures, which happen immediately upon connection attempt. By recognizing this pattern, you can focus your troubleshooting on the persistence of the connection state rather than the quality of the link itself. For users experiencing similar intermittent connectivity issues with other VPN protocols, such as WireGuard, checking related documentation on Troubleshooting No Internet with Self Hosted Wireguard VPN on Raspberry Pi Behind the Router may provide additional context on how different protocols handle NAT traversal differently.

Adjusting Firewall and Netfilter Timeouts

The primary solution involves modifying the connection tracking timeout for UDP traffic within the Linux kernel on your Raspberry Pi. You need to ensure that the nf_conntrack_udp_timeout and nf_conntrack_udp_timeout_stream values are increased beyond the standard 180 seconds. This can be done temporarily via the command line to test if it resolves the issue, or permanently by updating sysctl configurations. Run the following commands to check the current timeout values:

sysctl net.netfilter.nf_conntrack_udp_timeout
sysctl net.netfilter.nf_conntrack_udp_timeout_stream

If these return 180, you should increase them to something like 600 seconds (10 minutes) to allow for longer periods of inactivity without dropping the connection. To apply this change immediately, use:

sudo sysctl -w net.netfilter.nf_conntrack_udp_timeout=600
sudo sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=600

To make these changes persistent across reboots, add the following lines to /etc/sysctl.conf:

net.netfilter.nf_conntrack_udp_timeout = 600
net.netfilter.nf_conntrack_udp_timeout_stream = 600

After editing the file, apply the changes by running sudo sysctl -p. This adjustment ensures that the firewall maintains the state of the UDP tunnel for a longer duration, preventing the premature three-minute cutoff.

Configuring OpenVPN Keep-Alive Settings

While adjusting system-level timeouts helps, configuring the OpenVPN server and client to send more frequent keep-alive packets is often more robust. OpenVPN has built-in mechanisms to keep the tunnel alive even when no application data is being transmitted. The keepalive directive forces the server and client to ping each other at specified intervals, refreshing the state in any intermediate firewalls or NAT devices. In your PiVPN configuration files, located typically in /etc/openvpn/easy-rsa/pki/ or managed via the pivpn command-line tool, ensure that the keepalive directive is present. A typical configuration looks like this:

keepalive 10 60

This setting instructs the VPN to send a control channel ping every 10 seconds and restart the connection if no data is received from the peer for 60 seconds. This frequency is sufficient to keep NAT tables warm on most routers. If you are using a custom .ovpn profile, verify that this line is included in the client configuration as well. Consistent keep-alives reduce reliance on system-level timeout settings and provide a more reliable connection experience.

Checking Router-Specific NAT Traversal Settings

Sometimes the issue lies not with the Raspberry Pi, but with the router sitting between the client and the server. Some routers have aggressive NAT pinhole expiration policies that do not align with standard Linux connection tracking. If you have access to your router’s administrative interface, look for settings related to "NAT Pinhole," "ALG" (Application Layer Gateway), or "UPnP." Disabling SIP ALG or FTP ALG can sometimes interfere with VPN traffic, so try disabling these features if they are enabled. Additionally, ensure that your router’s firmware is up to date, as older versions may have bugs related to UDP state management. If you are using a complex network setup with multiple subnets, refer to guides on Troubleshooting OpenVPN Connection on Raspberry Pi for Specific Device Subnet to ensure that routing tables are correctly configured to support the VPN subnet. Misconfigured routes can sometimes cause packets to loop or drop, mimicking timeout behaviors.

Verifying Client-Side Configuration

Finally, ensure that the client device connecting to your PiVPN server is configured correctly. Some mobile operating systems, particularly iOS and Android, have aggressive battery-saving features that suspend background network activity. If the phone goes to sleep, it may stop sending keep-alive packets, causing the connection to drop. On Android, ensure that "Unrestricted Data" is allowed for the OpenVPN app. On iOS, check that the VPN profile is set to always-on if possible. For desktop clients, verify that the configuration file matches the server’s parameters exactly, including the cipher, digest, and port. Mismatches here usually result in immediate failure, but subtle differences in MTU settings can cause fragmentation issues that lead to timeouts. Try adding tun-mtu 1500 or fragment 1300 to the client config to see if packet size issues are contributing to the drop.

Frequently Asked Questions

Why does my VPN work for exactly 180 seconds?

This duration corresponds to the default UDP connection tracking timeout in many Linux kernels and consumer routers. Once this timer expires without fresh packets, the firewall assumes the connection is dead and drops the state entry.

How do I make sysctl changes permanent on Raspberry Pi?

Add the desired parameters to the /etc/sysctl.conf file and then run sudo sysctl -p to reload the configuration. This ensures the new timeout values persist after a reboot.

Can router firmware cause this specific timeout?

Yes, some routers have their own independent NAT timeout settings that may differ from the Linux kernel defaults. Updating your router firmware or adjusting its specific NAT pinhole settings can resolve conflicts.

What is the purpose of the keepalive directive in OpenVPN?

The keepalive directive sends periodic pings between the client and server to maintain the tunnel state. This prevents intermediate firewalls from interpreting the connection as idle and closing it prematurely.

Does disabling battery saver mode help on mobile devices?

Absolutely. Mobile OSes often restrict background network access to save power. Ensuring your VPN app has unrestricted data permissions allows it to continue sending keep-alive packets even when the screen is off.