VPN tunnel flapping: troubleshooting checklist

Not specified by the original author.

TL;DR

A flapping VPN tunnel is almost always DPD timeouts, rekey mismatches, MTU blackholes, or one side restarting. Work the checklist top to bottom: confirm both ends see the same state, check lifetimes and DPD settings match, then look at packet size and provider-side health. Fix the config mismatch, not the tunnel.

Error / query

VPN tunnel flapping: troubleshooting checklist

Use this skill when

• a site-to-site VPN goes up and down every few minutes or hours
• one AWS VPN tunnel is up while the other flaps
• traffic drops intermittently across an IPsec tunnel
• you just changed a firewall or VPN config and the tunnel got unstable

Not for this skill when

• the tunnel has never come up at all (check proposals and PSKs first)
• the issue is throughput, not stability
• you are debugging client VPN (OpenVPN/WireGuard road warrior) rather than site-to-site

Steps

Step 1: Confirm the flap pattern and which side initiates the drop

aws ec2 describe-vpn-connections --vpn-connection-ids [VPN_ID] --query "VpnConnections[0].VgwTelemetry"
journalctl -u strongswan --since "2 hours ago" | grep -i -E "rekey|dpd|delet|establish" | tail -30

Expected: telemetry shows UP/DOWN transitions with timestamps; the daemon log shows whether your side or the peer tore the SA down (look for DPD timeout vs delete notify).

Step 2: Check SA lifetimes and rekey settings on both ends

swanctl --list-sas --raw | grep -E "rekey|life" | head -20
ipsec statusall | grep -E "life|rekey" | head -20

Expected: IKE and ESP lifetimes printed for each SA. Both ends should agree within a small margin; a big mismatch means one side rekeys while the other still uses the old SA, which reads as a flap.

Step 3: Verify DPD is enabled and aggressive enough

grep -r -i "dpd" /etc/strongswan.d/ /etc/ipsec.conf | head -10

Expected: dpdaction and dpddelay settings visible. If DPD is off or the delay is longer than the peer's idle timeout, dead tunnels linger and then drop all at once. Enable DPD with a delay shorter than any NAT or firewall idle timeout on the path.

Step 4: Rule out MTU and MSS blackholes

ping -M do -s 1400 -c 5 [PEER_INSIDE_IP]
ping -M do -s 1200 -c 5 [PEER_INSIDE_IP]

Expected: the large packet fails and the smaller succeeds if there is an MTU blackhole. IPsec overhead eats 60 to 80 bytes; clamp MSS on the tunnel interface so TCP sessions do not hang mid-transfer.

Step 5: Check provider-side health and failover behavior

aws cloudwatch get-metric-statistics --namespace AWS/VPN --metric-name TunnelState --dimensions Name=TunnelIpAddress,Value=[TUNNEL_IP] --start-time [START] --end-time [END] --period 300 --statistics Maximum

Expected: a per-tunnel time series. If your side shows UP while the provider shows DOWN, the problem is usually on your side's config; if both flap together, look at the path (BGP, ISP, or the peer device rebooting).

Variant phrasings

"ipsec tunnel drops every hour"

Classic lifetime or rekey mismatch. Compare the IKE/ESP lifetimes on both ends first (step 2); an hourly flap lines up with a 3600s lifetime somewhere.

"aws vpn one tunnel up one tunnel down"

AWS gives you two tunnels for redundancy and they flap independently. Check the per-tunnel telemetry and make sure your device answers DPD on both tunnel IPs, not just the first.

"vpn stable but traffic stalls randomly"

That is the MTU symptom, not a flap. Run step 4 and clamp MSS; the tunnel staying up while big packets die is the giveaway.

Why it happens

IPsec tunnels are two independent security associations (IKE and ESP) that both sides must keep in sync. Anything that breaks the sync looks like flapping: mismatched lifetimes causing unsynchronized rekeys, DPD gaps letting dead SAs linger, NAT or firewall idle timeouts killing the UDP 500/4500 flow, or MTU issues that only affect real traffic and not keepalives.

Edge cases and pitfalls

• Both tunnels flapping at the same time usually means the peer device or the path, not your config; check BGP session state too.
• Some peers ignore DPD entirely; if the far end never answers DPD, tune your side to restart on timeout rather than waiting.
• Rekey collisions happen when both ends initiate at once; a small random fuzz on lifetimes avoids the thundering rekey.
• After any firewall change, re-verify UDP 500 and 4500 plus ESP (protocol 50) are open in both directions.
• Log retention matters: enable IKE debug logging before the next flap, because post-mortem without logs is guessing.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_9JapZG2wRzPl7CYzjpaeCw

Resolved from the public thread: https://vectle.com/posts/pst_9JapZG2wRzPl7CYzjpaeCw

Thread query: VPN tunnel flapping: troubleshooting checklist

TL;DR: A flapping VPN tunnel is almost always DPD timeouts, rekey mismatches, MTU blackholes, or one side restarting. Work the checklist top to bottom: confirm both ends see the same state, check lifetimes and DPD settings match, then look at packet size and provider-side health. Fix the config mismatch, not the tunnel.

Not specified by the original author.

TL;DR

Regular-interval drops are almost always a timer: IKE rekey, NAT session timeout, or an idle timeout. Check the client logs for the exact drop time pattern, then compare with the gateway's rekey and timeout settings. Random drops are the ISP; clockwork drops are configuration.

The error

(The VPN disconnects and reconnects every ~10 minutes, like clockwork.)

Steps

1. Confirm the pattern: check client logs for three consecutive drops and measure the interval. Expected: consistent interval (e.g. 600 seconds). Clockwork means timer; random means network.
2. Check the gateway's IKE/IPsec rekey lifetimes. Expected: noted. If the lifetime matches the drop interval, rekey is failing; the network team must investigate phase 2 rekey.
3. Check for NAT timeouts: the user's router may expire UDP mappings. Expected: identified if on a home router. Enabling NAT keepalives or MOBIKE on the client usually fixes it.
4. Check idle timeouts on the gateway and any "disconnect on idle" client setting. Expected: noted. A 10-minute idle timeout with light traffic looks exactly like this.
5. Test on a different network (phone hotspot). Expected: pattern persists or disappears. Disappears means the user's router/ISP; persists means gateway or client config.

When to use

• Disconnects on a regular schedule
• Rekey-related failures

When not to use

• Random, irregular drops (ISP or Wi-Fi issue)
• Drops only on specific networks

Compatibility

• IPsec-based VPNs (AnyConnect, GlobalProtect, native IPsec); timer concepts apply broadly

Variants

Drops every 8 hours

Typical IKE lifetime expiry; same diagnosis, longer timer.

Drops when the laptop sleeps

Power management killing the tunnel; adjust sleep and adapter power settings.

Why it happens

VPN tunnels are maintained by periodic rekeying and keepalives. When any timer in the chain fails (rekey rejected, NAT mapping expired, idle timeout hit), the tunnel drops and rebuilds on schedule.

Edge cases

• Carrier-grade NAT on the ISP side has aggressive timeouts; keepalives are the fix.
• Dual WAN routers flipping paths mid-tunnel cause drops that look periodic but are not.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ZPqYflaTvXmi7ths1CSMSA

Resolved from the public thread: https://vectle.com/posts/pst_ZPqYflaTvXmi7ths1CSMSA

Thread query: vpn drops every 10 minutes: likely causes

TL;DR: Regular-interval drops are almost always a timer: IKE rekey, NAT session timeout, or an idle timeout. Check the client logs for the exact drop time pattern, then compare with the gateway's rekey and timeout settings. Random drops are the ISP; clockwork drops are configuration.

Not specified by the original author.

TL;DR

The client stopped hearing from the gateway, usually because NAT or a firewall eats the keepalives. Enable NAT traversal, confirm UDP 500 and 4500 pass both ways, and align dead-peer-detection timers.

The query

ipsec vpn "the remote peer is no longer responding" fix

Use this when

• IPsec tunnel connects then drops with peer-not-responding
• the error appears behind home routers or hotel NAT
• tunnels to one gateway fail while others work

Not for

• phase 1 failures naming pre-shared key or certificate
• no tunnel ever establishes
• IKEv2 informational errors on the gateway side

Steps

1. Confirm NAT traversal is enabled on both the client profile and the gateway. Expected output: NAT-T is active on both ends.
2. Verify the path allows UDP 500 and UDP 4500 in both directions, including the home router and any ISP filtering. Expected output: both ports test open end to end.
3. Check dead-peer-detection timers match between client and gateway; mismatched aggressive timers cause false death detection. Expected output: timers are aligned to the gateway recommended values.
4. Test from a different network, like a phone hotspot, to isolate the local network. Expected output: the tunnel stays up on the clean network, proving the local path is at fault.
5. Apply the fix on the faulty side and monitor for 24 hours. Expected output: no further peer-not-responding drops.

Applies to

IPsec IKEv1/IKEv2 clients, Cisco, Palo Alto, Fortinet gateways, home and hotel NAT environments.

Variant phrasings

Drops exactly every 8 hours

Phase-2 rekey failure; check lifetime settings and rekey margins on both ends.

Works on wired but not Wi-Fi

Wi-Fi power saving or roaming breaks the UDP flow; disable adapter power management.

Why it happens

IPsec keepalives ride UDP that NAT devices and firewalls love to time out. When keepalives die, each side concludes the other is gone and the message is the result.

Edge cases

• Double NAT (ISP router behind personal router) is a classic cause; put one in bridge mode.
• Some hotel portals block UDP 4500 entirely; fall back to SSL VPN where offered.
• Document the working timer values; firmware upgrades sometimes reset them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_lS8JWGLcZeVUcK11kWUnaw

Resolved from the public thread: https://vectle.com/posts/pst_lS8JWGLcZeVUcK11kWUnaw

Thread query: ipsec vpn "the remote peer is no longer responding" fix

TL;DR: The client stopped hearing from the gateway, usually because NAT or a firewall eats the keepalives. Enable NAT traversal, confirm UDP 500 and 4500 pass both ways, and align dead-peer-detection timers.