Troubleshoot a Flapping IPsec VPN Tunnel on Juniper SRX

A site-to-site IPsec tunnel that goes up and down in quick succession is one of the most disruptive faults on an SRX because it breaks sessions that were working seconds ago and fills the log with identical messages. The diagnosis is a fixed sequence: find out whether the whole device is affected or only one tunnel, read the syslog, then check the three usual suspects — IKE state, VPN monitor configuration and the underlying interface.

Step 1: one tunnel or all tunnels?

set system syslog file messages any info
show log messages | match "IKE|VPN|ipsec"
show security ike sa
show security ipsec sa

If all VPNs are flapping, stop looking at the tunnel configuration and look at the internet connection and the SRX interfaces. If only one VPN flaps, the problem is local to that peer, its proposal set, or the path between them.

Step 2: read the transition, not just the failure

VPN up/down events in show log messages tell you whether the tunnel is being torn down by a negotiation failure or by dead-peer detection. Look immediately before each down event for a proposal mismatch, an IKE negotiation timeout, or a DPD/VPN-monitor timeout — each points at a different fix.

Step 3: VPN monitor and ICMP

VPN monitor is the most common cause of an otherwise healthy tunnel flapping. If the remote peer blocks ICMP echo, the monitor declares the tunnel dead and tears it down, then rebuilds it, then repeats. Either re-enable ICMP between the two peer addresses or reconfigure VPN monitor with sensible source-interface and destination-IP options so the probe reflects a path that actually exists:

set security ipsec vpn SITE-B vpn-monitor
set security ipsec vpn SITE-B vpn-monitor optimized
set security ipsec vpn SITE-B vpn-monitor source-interface ge-0/0/0.0
set security ipsec vpn SITE-B vpn-monitor destination-ip 203.0.113.5

Step 4: interface and MTU

show interfaces ge-0/0/0 extensive | match "Error|CRC|drop|flap"
show interfaces ge-0/0/0.0 detail
show security flow session tunnel

Physical errors on the WAN interface look exactly like VPN instability from the far end. At the same time check MTU: an interface carrying both IPsec (with its extra headers) and full-size frames will fragment or drop large packets, which some applications interpret as a dead tunnel. Confirm the tunnel interface MTU accounts for the ESP overhead, and test with a size-sweeping ping.

Step 5: non-Juniper far end

If the peer is not a Juniper device, compare proposal and policy parameters line by line: encryption and hash algorithms, DH group, lifetime in seconds versus kilobytes, and whether PFS is enabled on both sides. A lifetime mismatch is a classic cause of a tunnel that is perfectly stable for exactly one rekey interval and then flaps forever.

Related reading: Junos SRX flow session debugging, SRX chassis cluster failover, Post-quantum cryptography in IKEv2.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/vpn-ipsec/topics/task/srx-troubleshooting-flapping-vpn-tunnel.html