"VPN tunnel down" threads divide cleanly into two kinds: Phase 1 never establishes (the IKE session itself), and Phase 1 is up but Phase 2 IPsec SA fails (or the tunnel is up and traffic simply does not flow). Juniper's own troubleshooting guide starts the same way this field method does — identify the phase that failed, then look only at that phase's causes.

Step 1: Which Phase Is Broken?

show security ike security-associations
show security ipsec security-associations

The first command shows IKE Phase 1 SAs; the second shows Phase 2 IPsec SAs and their st0 bindings. Four outcomes:

  • Neither exists — Phase 1 failure (network, proposal, PSK).
  • Phase 1 exists, Phase 2 does not — Phase 2 failure (proposal, proxy-ID or traffic-selector, PFS).
  • Both exist but tunnel is "down" per monitoring — check routes, policy and keepalives.
  • Both exist and idle — traffic-initiated bring-up: nothing has triggered it.

Phase 1 Failures

No Response at All

Nothing in show security ike security-associations and no logs from the peer means IKE packets (UDP 500, or 4500 with NAT-T) never arrive. Check: correct peer IP configured, any intermediate firewall or ACL permitting UDP 500 and 4500, and that the peer's external address matches the IKE gateway config. If either endpoint is behind NAT, NAT-T negotiation must succeed — mismatched NAT-T handling is a common silent killer.

Proposal or PSK Mismatch

The SA appears with state flags or logs show NO_PROPOSAL_CHOSEN or authentication failure. Compare, line by line: IKE version (v1 vs v2 — mixed is a classic), encryption, hash and DH-group on both sides, and the pre-shared key (a trailing space in a PSK is invisible and real). The responder's logs tell the truth; the initiator's often just show retries.

Phase 2 Failures

Phase 1 established, no IPsec SA: the quick selectors disagree. Check show log kmd for the responder's complaint:

  • Proxy-ID or traffic-selector mismatch — the protected networks in Phase 2 must match (or be covered by) the configured ones. A changed remote subnet without updating proxy-IDs is the most common Phase 2 failure after firewall changes.
  • PFS mismatch — one side demands PFS with a DH group the other does not offer.
  • Proposal mismatch — ESP encryption or hash differs from the IPsec policy.

Tunnel Up but No Traffic Flows

IPsec SAs exist, st0 is up, yet pings fail — the routing and policy layer:

  • A route through st0 is missing (or was replaced by a more specific route). show route for the remote subnet must point into st0.x.
  • Security policy between the relevant zones does not permit the traffic — the zone and policy guide covers the check.
  • MTU and fragmentation — small pings pass, large transfers stall. Clamp TCP MSS on st0 (set security flow tcp-mss ipsec-vpn mss 1350) and verify DF behavior; the same large-packet logic appears in our OSPF ExStart guide.

When Logs Are Not Enough: IKE Traceoptions

set security ike traceoptions file ike.log size 10m
set security ike traceoptions flag ike
set security ike traceoptions flag parsing
commit

Reproduce the failure, then read show log ike.log. The responder's log names the exact failing element — proposal, key, or selector — which turns guesswork into a one-line fix. Remove traceoptions afterward; on busy VPN gateways they generate significant load (see our high-CPU guide for why daemons like kmd punish leftovers).

Keep It Up: DPD and Bring-Up

For unattended tunnels, configure dead-peer detection so failures are noticed, and bring tunnels up without waiting for user traffic: set security ipsec vpn VPN-A establish-tunnels immediately. For a full working hub-and-spoke deployment to compare against, see our SRX hub-and-spoke VPN guide, and when NAT sits in the path, the SRX NAT troubleshooting guide explains how NAT-T interacts with sessions.