First: diagnose the pattern
Before fixing anything, identify the pattern. Look at the VPN client's logs (WireGuard: wg show + system log; OpenVPN: the client log file). Note the disconnect timestamps. Three patterns map to three different causes:
- Periodic, predictable (every N minutes, consistent): NAT-table timeout. See Cause 1.
- Random, correlated with traffic spikes (large downloads, video calls): MTU clipping. See Cause 2.
- Random, not correlated with anything: ISP throttling or kernel issues. See Cause 3.
Cause 1: NAT-table timeout (most common, ~60% of cases)
What's happening: your VPN traffic transits at least one router with NAT (Network Address Translation). Every NAT entry has a timeout — if no packet flows for ~30 seconds, the entry is evicted. When the tunnel tries to send packets again, the NAT box doesn't know where to send return traffic and the tunnel appears broken until a new entry is established.
Symptom: VPN drops every 1-5 minutes, very consistently. wg show shows the last-handshake timestamp growing stale.
Fix: add PersistentKeepalive = 21 to your WireGuard config (or --keepalive 10 60 to OpenVPN). This sends a tiny ~32-byte packet every 21 seconds to keep the NAT entry alive. 21 seconds is the sweet spot — most consumer NAT timeouts are 30+ seconds, so 21 gives 9 seconds of slack; bandwidth cost is negligible (~1.5 bits/second).
Cause 2: MTU clipping on PPPoE / CGNAT
What's happening: your underlying network has a smaller MTU than your VPN client assumes. WireGuard's default MTU is 1420 (1500 - 80 bytes of WG headers). If your ISP runs PPPoE (1492 MTU underneath), CGNAT (often less), or any path with smaller MTU, large packets get fragmented or dropped silently. Small packets work; large packets (video, file transfers) hang.
Symptom: VPN works for SSH and chat but breaks during downloads / video / large file transfers. Connection appears to "freeze."
Fix: set MTU explicitly in your VPN client config. MTU = 1380 in WireGuard config is safe for most Indian ISP PPPoE / CGNAT conditions. Less aggressive than the maximum, but more reliable. MeshWG generates configs with MTU=1280 by default for this exact reason.
Cause 3: ISP rate-limiting VPN UDP
What's happening: some ISPs detect known VPN UDP flows (typically port 1194 for OpenVPN, 51820 for WireGuard) and rate-limit them aggressively. The tunnel doesn't necessarily disconnect, but it slows to single-digit Mbps and may appear unstable.
Symptom: tunnel works perfectly on one network, abysmally on another (same hardware, same config). Throughput tests inside the tunnel show 1-5 Mbps despite a much faster underlying WAN.
Fix: change the VPN's listen port to something non-default. ListenPort = 51847 or 51842 instead of 51820 typically avoids the throttle. Some ISPs are more aggressive and require switching to TCP-based VPN (OpenVPN/TCP over 443) entirely.
Cause 4: WiFi network change
What's happening: you move between WiFi networks (home → coffee shop → office) and the VPN doesn't re-establish cleanly on the new network's underlying interface.
Symptom: VPN works on the old network, doesn't work on the new one until you manually disconnect / reconnect.
Fix: use a VPN client that handles network changes well. WireGuard and Tailscale handle this elegantly; OpenVPN takes 2-30 seconds depending on keepalive settings; IPsec is the worst case. If you roam often, prefer WireGuard-based products.
Cause 5: Kernel bugs or client version
What's happening: the WireGuard kernel module on your OS has a known issue. Common on older Linux kernels (5.5-5.8 had a couple of edge-case bugs around peer rotation) and certain combinations of Windows + specific VPN clients.
Symptom: disconnects correlate with specific kernel events (sleep/wake, fast NIC failover, system updates).
Fix: update to current kernel / current VPN client. Most kernel-side WG issues are resolved by 5.15+; on Windows, use the official WireGuard for Windows client v0.5.x or later. Avoid running multiple WireGuard implementations simultaneously (kernel module + wireguard-go) — they sometimes fight over the same interface.
Cause 6: DNS resolution failures
What's happening: your VPN endpoint is specified as a hostname (e.g. peer.example.com) and DNS resolution fails — perhaps because the VPN tunnel is supposed to handle DNS but it's down, creating a chicken-and-egg loop.
Symptom: initial tunnel fails to come up; reconnect attempts also fail. Pings to the hostname time out.
Fix: in your VPN client config, use an IP address rather than a hostname for the endpoint — or ensure DNS resolution works without the VPN being up (don't put your only DNS server behind the VPN).
Cause 7: Overnight IP rotation or router reboot
What's happening: your ISP rotates your public IP overnight (common on residential / CGNAT), or your router auto-reboots for firmware updates.
Symptom: VPN works during the day, disconnects between 2-5 AM, comes back on its own (or doesn't until manual reconnect in the morning).
Fix: persistent keepalive + auto-reconnect on the VPN client side handles IP rotation transparently for WireGuard. For OpenVPN, ensure --persist-tun and --ping-restart are set. For router auto-reboots, schedule them outside business hours or disable the auto-reboot feature.
When to switch VPN tools
If you've tried all seven fixes and the VPN still drops, the problem may be the VPN product itself:
- Frequent issues on OpenVPN → switch to WireGuard. WireGuard's connection model is structurally less prone to the disconnects this guide covers.
- Frequent issues on a router-vendor's own VPN UI → consider a managed mesh. Consumer router VPN implementations are highly variable in quality; managed mesh products (MeshWG, Tailscale, NetBird) ship more reliable defaults.
- Frequent issues across multi-branch deployments → consider router-based managed mesh. For SMB multi-site, MeshWG's defaults (persistent keepalive 21s, MTU 1280, CGNAT relay built in) eliminate the four most common branch-VPN disconnect causes structurally.
Frequently asked questions
Why does my VPN keep disconnecting every few minutes?
The most common cause is NAT-table timeout on a router between you and the VPN server. UDP-based VPN protocols (WireGuard, OpenVPN-UDP) rely on a NAT entry being active in every intermediate router; if no packet flows for ~30 seconds, that entry expires and the tunnel falls silent until the next outbound packet re-establishes it. Set PersistentKeepalive=21 (seconds) on your VPN client to send a tiny keepalive packet every 21 seconds. This is the single most common cause of 'VPN disconnects every few minutes,' and the fix is one configuration line.
Why does my VPN disconnect when I move between WiFi networks?
Most VPN clients re-establish the tunnel when the underlying network interface changes. WireGuard handles this well — it sends new handshakes from the new IP automatically. OpenVPN typically takes 2-30 seconds depending on its keepalive settings. IPsec is the worst case, often requiring a full re-IKE which takes longer. If roaming is your primary use case, WireGuard-based VPNs (Tailscale, MeshWG, raw WireGuard) handle it most cleanly.
Why does my VPN slow down before disconnecting?
Two common patterns. First, MTU clipping: if the VPN's packet size exceeds the underlying network MTU (typical on PPPoE / CGNAT), large packets are dropped silently, retransmits accumulate, throughput collapses, and the connection appears to die. Fix by setting your VPN client's MTU to ~1380 (vs the default 1420). Second, ISP throttling: some ISPs detect VPN UDP flows and rate-limit them; this manifests as 'works fine for a minute then crawls.' Switch to a different listen port (not 1194 or 51820), or use TCP-based VPN if available.
Why does my VPN disconnect overnight?
Three common causes. (1) ISP-side IP rotation: residential and CGNAT ISPs sometimes rotate your public IP overnight; if your VPN config has a static endpoint pointing at a similarly-affected server, both sides need to discover the new IPs. (2) ISP-level keep-alive timeout: some ISPs reset long-running UDP flows after 12-24 hours regardless of activity. (3) Router reboot: some consumer routers auto-reboot nightly for firmware update reasons. Persistent keepalive on the VPN client side handles (1) and (2); enabling auto-reconnect on the router handles (3).
How do I tell what's causing my VPN to disconnect?
Start with the VPN client's logs. WireGuard: 'wg show' shows last-handshake timestamps per peer — a stale timestamp means the tunnel has been silent. OpenVPN: the client log shows 'TLS Error' or 'Connection reset' messages with timestamps. Correlate with what was happening on the network at that moment (laptop sleep, network interface change, ISP outage). If the disconnects are periodic (every N minutes consistently), the cause is almost always NAT timeout — fix with PersistentKeepalive=21. If they're random / correlated with traffic spikes, suspect MTU clipping or ISP throttling.
Does MeshWG help with these disconnect issues?
Yes, structurally. MeshWG's defaults handle the four most common disconnect causes automatically: persistent keepalive set to 21 seconds on every generated configuration, MTU set to 1380 (safe under most Indian ISP PPPoE / CGNAT conditions), CGNAT relay built in for double-NAT scenarios where peers can't directly handshake, and 24/7 support if a disconnect pattern doesn't match these common causes. For SMB multi-branch deployments where 'why does the VPN keep dropping at branch 3?' is the recurring question, MeshWG's defaults eliminate most of those calls.
Next steps
If you're tired of debugging VPN disconnects across branches, MeshWG's defaults handle them automatically — free for 2 routers, indefinite.