Bill Wester

Field notes

SRX site-to-site VPN stuck in IKE phase 1? Check these in order

, Juniper SRX

A site-to-site IPsec tunnel on an SRX that won’t come up is the most common call I get. The symptoms are almost always the same: no IKE security association, or one that forms and then immediately disappears. The causes vary, but they show up in a predictable order, and checking them in that order saves hours.

All addresses below are documentation examples.

1. Confirm what you’re actually seeing

Start with the two commands that tell you which phase is failing:

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

No IKE SA at all means phase 1 isn’t completing. An IKE SA with no IPsec SA means phase 1 is fine and the problem is in phase 2, which is usually proposals or proxy-IDs (step 6).

2. Is IKE traffic reaching the SRX?

Before touching the VPN configuration, confirm the packets are arriving. IKE uses UDP 500, and UDP 4500 once NAT traversal kicks in. An upstream router ACL, an ISP filter or another firewall in the path will block these silently.

A quick packet capture or a flow trace on the external interface answers the question in minutes. If nothing arrives from the peer, no amount of VPN configuration will help. I’ve seen this exact problem where the upstream filter only allowed one side to initiate, so the tunnel came up only when the remote peer started it.

3. Is the SRX listening for IKE on that zone?

The external zone, or the external interface within it, must allow IKE as host-inbound traffic:

set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services ike

If the tunnel terminates on a loopback, the zone holding lo0 needs this too, and any loopback firewall filter protecting the routing engine must permit UDP 500 and 4500 from the peer.

4. Do the IKE settings match the peer exactly?

Line up these items side by side with the peer’s configuration:

  • IKE version (v1 or v2) and, for v1, main or aggressive mode
  • Encryption, authentication, DH group and lifetime in the IKE proposal
  • Pre-shared key (retype it on both sides if in doubt; trailing spaces and special characters are common culprits)
  • Peer address and the external-interface the gateway uses

5. Do the identities match?

Many failures come down to identity. If the peer expects a hostname or a specific IP as the local identity and the SRX sends something else, phase 1 fails even when every proposal matches. Set it explicitly on both ends:

set security ike gateway GW-SITE-B local-identity inet 203.0.113.10
set security ike gateway GW-SITE-B remote-identity inet 198.51.100.20

Behind NAT, the local identity often needs to be the public address the peer sees, not the private interface address.

6. Phase 2: proposals and proxy-IDs

If phase 1 is up but phase 2 isn’t, compare the IPsec proposal (protocol, encryption, authentication, PFS group and lifetime) with the peer.

Then check proxy-IDs. A route-based SRX tunnel sends 0.0.0.0/0 for both local and remote by default. Policy-based peers, including many third-party firewalls, expect specific subnets. Set them explicitly to match:

set security ipsec vpn VPN-SITE-B ike proxy-identity local 10.10.0.0/16
set security ipsec vpn VPN-SITE-B ike proxy-identity remote 10.20.0.0/16

7. The tunnel is up but no traffic passes

Once both SAs are up, check the route-based plumbing:

  • st0.0 exists, is bound to the VPN with bind-interface st0.0, and sits in a security zone
  • There’s a route to the remote subnets pointing at st0.0
  • Security policies allow traffic between the internal zone and the zone holding st0.0
  • Source NAT rules aren’t translating traffic that should go through the tunnel

When the checklist doesn’t find it: traceoptions

Turn on IKE traceoptions and read the negotiation directly:

set security ike traceoptions file ike-trace size 1m files 3
set security ike traceoptions flag all

Then show log ike-trace while the peer tries to connect. The log names the failing proposal, identity or authentication step. Remember to remove traceoptions afterward.

What usually turns out to be the cause

In my experience, roughly in order: traffic filtered upstream, identity mismatches behind NAT, proxy-ID mismatches with policy-based peers, and pre-shared keys that aren’t quite identical. Proposal mismatches are the most commonly suspected cause, but they’re usually not the problem once someone has checked them once.