SRX Site to Site VPN: Route-Based IKEv2 Configuration, Verification and Interop Gotchas

An SRX site to site VPN is easiest to build and debug as a route-based IKEv2 tunnel bound to an st0 interface. You match proposals with the peer, route the remote LAN into st0.0, and permit traffic with address-book-based security policies. Most failures come from a proposal mismatch, a traffic selector mismatch with a policy-based peer, or a missing ike host-inbound service on the external zone.

This guide is written against the Junos OS 23.4 train on the SRX300 line and vSRX. We have not tested every command on every release. Run commit check, verify in a lab, and confirm each statement with ? completion on your version before production. If a tunnel that used to work has failed, the Troubleshooting hub is a better starting point.

If you are still choosing hardware, read our small business firewall comparison first.

Plan Both Ends Before You Type

Write the parameters down once and use the same sheet on both firewalls. In our experience, most failed first tunnels are transcription errors between two GUIs or two CLIs.

The LAN prefixes must not overlap. If both sites use the same range, renumber one before you build the tunnel. NAT inside a VPN works, but it turns every future troubleshooting session into a puzzle.

Why IKEv2 Fails the Way It Does

IKEv2 negotiates in two initial exchanges defined in RFC 7296. IKE_SA_INIT agrees the IKE proposal and runs Diffie-Hellman. IKE_AUTH proves identity with the pre-shared key and, in the same exchange, creates the first child SA that carries your traffic.

That second detail causes a classic delayed failure. The first child SA is created without a fresh Diffie-Hellman exchange, so a PFS group mismatch does not show up at build time. The tunnel comes up, passes traffic, and then fails at the first child SA rekey near the IPsec lifetime. If a new tunnel dies after roughly an hour, compare PFS groups first.

Traffic selectors are the other trap. A route-based SRX proposes 0.0.0.0/0 for both sides by default, as the Juniper route-based IKEv2 example notes. A policy-based peer, or a Palo Alto with proxy IDs, proposes specific subnets instead. IKEv2 lets the responder narrow selectors, but vendors narrow differently, so explicit mirrored selectors are the safer interop choice.

Complete SRX Site to Site VPN Configuration (Site A)

Apply this with commit confirmed 5 and keep console or out-of-band access. A wrong host-inbound setting on the external zone can cut off remote management. Replace the addressing, key and interface names with your own.

Interfaces, zones and address book

set interfaces ge-0/0/0 unit 0 family inet address 203.0.113.10/24
set interfaces ge-0/0/1 unit 0 family inet address 192.0.2.1/26
set interfaces st0 unit 0 family inet
set routing-options static route 0.0.0.0/0 next-hop 203.0.113.1
set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services ike
set security zones security-zone trust interfaces ge-0/0/1.0 host-inbound-traffic system-services ping
set security zones security-zone trust interfaces ge-0/0/1.0 host-inbound-traffic system-services ssh
set security zones security-zone vpn interfaces st0.0
set security address-book global address LAN-A 192.0.2.0/26
set security address-book global address LAN-B 192.0.2.64/26

IKE and IPsec

set security ike proposal IKE-P authentication-method pre-shared-keys
set security ike proposal IKE-P dh-group group19
set security ike proposal IKE-P authentication-algorithm sha-256
set security ike proposal IKE-P encryption-algorithm aes-256-cbc
set security ike proposal IKE-P lifetime-seconds 28800
set security ike policy IKE-POL proposals IKE-P
set security ike policy IKE-POL pre-shared-key ascii-text "replace-with-32-plus-random-characters"
set security ike gateway GW-SITE-B ike-policy IKE-POL
set security ike gateway GW-SITE-B address 198.51.100.20
set security ike gateway GW-SITE-B external-interface ge-0/0/0.0
set security ike gateway GW-SITE-B version v2-only
set security ike gateway GW-SITE-B dead-peer-detection probe-idle-tunnel
set security ipsec proposal IPSEC-P protocol esp
set security ipsec proposal IPSEC-P encryption-algorithm aes-256-gcm
set security ipsec proposal IPSEC-P lifetime-seconds 3600
set security ipsec policy IPSEC-POL perfect-forward-secrecy keys group19
set security ipsec policy IPSEC-POL proposals IPSEC-P
set security ipsec vpn VPN-SITE-B bind-interface st0.0
set security ipsec vpn VPN-SITE-B ike gateway GW-SITE-B
set security ipsec vpn VPN-SITE-B ike ipsec-policy IPSEC-POL
set security ipsec vpn VPN-SITE-B ike proxy-identity local 192.0.2.0/26
set security ipsec vpn VPN-SITE-B ike proxy-identity remote 192.0.2.64/26
set security ipsec vpn VPN-SITE-B ike proxy-identity service any
set security ipsec vpn VPN-SITE-B establish-tunnels immediately

Three details differ from many older guides. First, there is no mode main line, because main and aggressive mode are IKEv1 concepts. Second, the IPsec proposal has no authentication algorithm, because AES-GCM provides integrity itself; configuring both is a common copy-paste error, so read the commit check output on your release. Third, the proxy-identity lines make the selectors explicit for interop. If the peer is another SRX using defaults, you can omit them on both sides.

Routing, policies and MSS

set routing-options static route 192.0.2.64/26 next-hop st0.0
set security policies from-zone trust to-zone vpn policy A-TO-B match source-address LAN-A
set security policies from-zone trust to-zone vpn policy A-TO-B match destination-address LAN-B
set security policies from-zone trust to-zone vpn policy A-TO-B match application any
set security policies from-zone trust to-zone vpn policy A-TO-B then permit
set security policies from-zone vpn to-zone trust policy B-TO-A match source-address LAN-B
set security policies from-zone vpn to-zone trust policy B-TO-A match destination-address LAN-A
set security policies from-zone vpn to-zone trust policy B-TO-A match application any
set security policies from-zone vpn to-zone trust policy B-TO-A then permit
set security flow tcp-mss ipsec-vpn mss 1350
commit confirmed 5

Security policies match address-book names, not raw prefixes, and every policy needs an application match. A policy with a bare prefix or no application line will not commit. An MSS of 1350 is a common starting point on Ethernet paths; lower it if a PPPoE or LTE link sits in the path.

These policies permit any application between the two LANs. They do not inspect content or restrict ports. Narrow the application match once the tunnel is stable.

Why route-based beats policy-based here

The tunnel is a routed interface in its own zone, so your existing trust-to-untrust source NAT never touches VPN traffic. That removes the most common policy-based failure, where internet NAT rewrites packets before encryption. It also lets you run OSPF or BGP over st0 later without a redesign. Hub-and-spoke is the natural next step for more sites.

Configuring the Peer

SRX to SRX

Mirror the config with local and remote values swapped. Swap the proxy-identity prefixes, and point the static route for 192.0.2.0/26 at st0.0.

SRX to FortiGate

Match the Phase 1 and Phase 2 proposals exactly, and remove any extra proposals FortiOS adds by default. Set the Phase 2 selectors to the same subnets as the SRX proxy-identity, mirrored. A FortiGate tunnel may not come up at all without a firewall policy referencing it, which looks like an IPsec failure from the SRX side, as engineers on r/networking have reported.

SRX to Palo Alto

Build the IKE gateway, the IKE and IPsec crypto profiles and the tunnel interface to match. If the Palo Alto tunnel has proxy IDs, they must mirror the SRX proxy-identity exactly. If it has none, it behaves like a route-based peer with 0.0.0.0/0 selectors.

Verification: Healthy and Broken Output

Trigger the tunnel with a sourced ping, then check each phase. Outputs are abridged and illustrative, and exact columns vary by release.

user@srx-a> ping 192.0.2.65 source 192.0.2.1 count 5

user@srx-a> show security ike security-associations
Index   State  Initiator cookie  Responder cookie  Mode           Remote Address
5812247 UP     3f8a9c1d2e4b6a70  9b1c2d3e4f5a6b7c  IKEv2          198.51.100.20

user@srx-a> show security ipsec security-associations
  Total active tunnels: 1     Total Ipsec sas: 1
  ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway
  <131073 ESP:aes-gcm-256/None 1a2b3c4d 3521/ unlim - root 500 198.51.100.20
  >131073 ESP:aes-gcm-256/None 5e6f7a8b 3521/ unlim - root 500 198.51.100.20

user@srx-a> show security ipsec statistics
ESP Statistics:
  Encrypted bytes:           1843200
  Decrypted bytes:           1790464
  Encrypted packets:           14400
  Decrypted packets:           13987
Errors:
  ESP authentication failures: 0, ESP decryption failures: 0
  Bad headers: 0, Bad trailers: 0

Port 4500 instead of 500 means NAT traversal is active, which Junos uses automatically when it detects NAT in the path. Encrypted and decrypted packet counters should both climb while traffic flows.

The three broken states

No IKE SA at all means Phase 1 never completed. Check reachability to the peer, the ike host-inbound service, the pre-shared key and the IKE proposal. An IKE SA that is UP with no IPsec SA means the child SA was rejected, usually over the IPsec proposal or the traffic selectors.

Both SAs up, with encrypted packets climbing and decrypted packets stuck at zero, means your side sends and nothing returns. The fault is on the peer: its route, its policy or its selectors. The reverse pattern points at your own route or policy.

Ordered Diagnostic When It Will Not Come Up

1. Can you reach the peer? Run ping 198.51.100.20 source 203.0.113.10. Some peers drop ICMP, so treat a failure as a hint rather than proof.
2. Is IKE allowed in? Run show configuration security zones security-zone untrust and confirm ike appears under host-inbound-traffic.
3. Is there an IKE SA? Run show security ike security-associations and check the State and Mode columns.
4. Is there an IPsec SA? Run show security ipsec security-associations, then add detail to compare local and remote identities with the peer.
5. Is traffic routed into the tunnel? Run show route 192.0.2.64/26 and confirm st0.0 is the next hop.
6. Is policy permitting it? Run show security policies hit-count while a ping is running.
7. Only now, trace. Enable IKE traceoptions, reproduce the failure, read the file, then remove the trace config.

set security ike traceoptions file ike-debug
set security ike traceoptions flag all
commit
run show log ike-debug | match "fail|proposal|error"
delete security ike traceoptions
commit

Tracing with flag all is verbose, so keep it brief. On platforms and releases that use the newer iked process rather than kmd, log wording differs. Search for the peer address as well as the keywords.

VPN, SD-WAN or SASE?

A site-to-site IPsec tunnel over broadband is the cheapest way to join two offices, and it is the right answer for most small estates. It carries no SLA, so latency-sensitive voice or video may need SD-WAN across multiple transports. If most traffic goes to SaaS rather than between sites, read what SASE changes for branch networks before you build a mesh of tunnels.

Juniper, Junos, MX, SRX, EX and QFX are trademarks of Juniper Networks, Inc. Other product names are trademarks of their respective owners. juniperclient.com is independent and unaffiliated.

Frequently Asked Questions

How do I set up an SRX route-based VPN?

Bind the IPsec VPN to an st0 unit with set security ipsec vpn VPN-SITE-B bind-interface st0.0, put st0.0 in its own zone, and route the remote LAN to it. Then add security policies between the LAN zone and the VPN zone in both directions. The full block is in the configuration section above.

How do I configure an SRX site to site VPN with IKEv2?

Set version v2-only on the IKE gateway and drop IKEv1-only statements such as mode main. Proposals, policies and the st0 binding stay the same. Confirm that the Mode column in show security ike security-associations reads IKEv2.

What are the best practices for IPsec tunnels between different firewall vendors?

Use IKEv2, one proposal per phase, and explicit mirrored traffic selectors on both ends. Avoid vendor-specific extras until the basic tunnel is stable. Wait past the IPsec lifetime and confirm a clean rekey before you call the job done.

Why is the wrong Phase 2 traffic selector used after an upgrade?

Usually one side changed or narrowed its selectors and the other did not. Compare the local and remote identities in show security ipsec security-associations detail with the peer, then set them explicitly with proxy-identity. Selector mismatches often surface only after a rekey or reboot.

Why do I get a VPN traffic selector mismatch with a FortiGate?

FortiGate Phase 2 selectors and the SRX proxy-identity must mirror each other exactly, including prefix length. Set both sides to the same pair of subnets, or both to 0.0.0.0/0 for a pure route-based design. Then run clear security ike security-associations and let the tunnel renegotiate.