Fix VPN drops when remote office traffic spikes

I know that spinning wheel on a VPN tunnel is maddening

Your remote office VPN drops right when everyone starts working—uploads fail, calls stutter, and you get the blame. I've been there, and the fix is usually simpler than you think.

Step 1: Fix the MTU size on both ends

The number one reason VPNs drop under load? Packet fragmentation. When your MTU is set to the default 1500, big packets get chopped up and the VPN can't reassemble them fast enough. Here's what I do:

1. On the remote office router (say a Cisco 2911 or FortiGate 60F), go to the WAN interface settings.
2. Change MTU from 1500 to 1400. Yes, just drop it by 100. For IPsec VPNs, 1400 is safe. For PPTP or OpenVPN, try 1300.
3. On the main office router (the VPN endpoint), do the same. Both ends must match.

Here's the command for a Cisco router:

interface GigabitEthernet0/0
ip mtu 1400
ip tcp adjust-mss 1360

And for FortiGate (GUI): Network → Interfaces → edit your WAN → set MTU to 1400.

Step 2: Enable TCP MSS clamping

This stops packets from being too big before they hit the tunnel. On the router, set the TCP MSS (maximum segment size) to 1360 if MTU is 1400. The formula is MSS = MTU - 40 (for IP and TCP headers).

On pfSense: Firewall → Rules → edit your WAN rule → set MSS to 1360. On SonicWall: match the MTU setting in the VPN policy.

Step 3: Check your firewall's NAT and timeouts

A lot of remote office VPNs drop because the firewall is killing idle sessions or NAT is misconfigured. Go to your firewall's advanced settings and:

• Increase UDP timeout for VPN traffic (ESP and IKE) to at least 300 seconds (5 minutes).
• Disable SIP ALG if you're using VoIP through the VPN—it messes with packet inspection.

On a typical FortiGate: Config → System → Advanced → set UDP idle timeout to 300. On Cisco ASA: timeout conn 1:00:00 and timeout udp 0:05:00.

Why this actually works

When traffic spikes, the VPN has to handle more packets at once. If any packet is bigger than the tunnel's path MTU, it gets fragmented. Fragmented packets are processed slower, and if the firewall has a low timeout, the tunnel drops. By lowering MTU, you force packets to stay small. MSS clamping makes sure TCP doesn't try to send big chunks. And longer timeouts give the tunnel room to breathe during bursty traffic.

Less common causes (when the fix above doesn't work)

VPN encryption overhead

Some encryption algorithms add extra headers. AES-256-GCM is more efficient than AES-256-CBC. If you're using old encryption, switch to GCM. It reduces overhead by about 20 bytes per packet.

Router CPU overload

Older routers (like Cisco 800 series) can't handle encryption at high speeds. Check CPU usage during drops. If it's above 80%, you need a hardware upgrade or offload encryption to a dedicated VPN appliance.

Double NAT

If the remote office has two routers (one from ISP, one from you), the VPN might be fighting with double NAT. Put the ISP modem in bridge mode or set the remote router's VPN to use a static IP.

How to stop it from happening again

• Test MTU with ping: ping -f -l 1472 [remote gateway IP] (Windows) or ping -M do -s 1472 [remote gateway IP] (Linux). Start at 1472 and lower until you get no fragmentation. Use that number + 28 for MTU.
• Monitor VPN throughput with tools like PRTG or Zabbix. Set alerts for packet loss > 1%.
• Keep firewall firmware updated—vendors fix VPN bugs every quarter.

One last thing: if you're using a consumer-grade router (like Netgear or Linksys) for VPN, stop. They can't handle more than 10-20 users. Get a proper business router like Ubiquiti EdgeRouter or MikroTik.