Juniper SRX Route-Based Site-to-Site IPsec VPN

Route-based VPNs on a Juniper SRX put all tunneled traffic into a logical st0 (secure tunnel) interface: anything routed into st0.x is encrypted and sent to the peer, provided the security policy permits it. Unlike policy-based VPNs there is no per-traffic "interesting traffic" list, which makes route-based tunnels easier to scale and to combine with dynamic routing. This guide walks through a complete route-based site-to-site IPsec configuration between two SRX firewalls, including the security zones, policies, NAT exceptions and MTU handling that are easy to forget — and the verification sequence that proves each layer works before you blame the tunnel.

Route-based versus policy-based VPNs

Both designs are supported on the SRX, and choosing between them is mostly about how traffic selects the tunnel:

• Policy-based — the VPN is bound to a pair of source and destination addresses inside a security policy, and the peer is identified by proxy IDs. Only traffic matching the policy enters the tunnel; a new subnet pair means a new policy and usually new proxy-ID configuration.
• Route-based — the VPN is bound to an st0 interface, and ordinary routing decides what enters the tunnel. Add a prefix to a static route or an IGP and traffic follows it; no policy change and no proxy IDs are required for the traffic itself.

Route-based tunnels therefore suit designs with many subnets per site, with dynamic routing over the tunnel, or with more than two sites terminating on the same firewall. They also make failover with IP monitoring simpler, because the tunnel interface can be monitored directly.

Topology and building blocks

SRX-A (WAN 1.1.1.1/30, LAN 10.1.1.0/24) peers with SRX-B (WAN 2.2.2.2/30, LAN 10.2.2.0/24). Both LANs use st0.0 with addresses 192.168.0.1/30 and 192.168.0.2/30. The pieces to configure on both sides: IKE proposal, IKE policy, IKE gateway, IPsec proposal, IPsec policy, IPsec VPN (bound to st0.0), zone membership for st0.0, security policies, and a static route pointing the remote LAN into st0.0. The tunnel endpoint addresses on st0 are outside both LAN ranges on purpose — they are transport addresses for the tunnel, not a routed subnet you should advertise.

Phase 1 (IKE) configuration

set security ike proposal IKE-PROP authentication-method pre-shared-keys
set security ike proposal IKE-PROP dh-group group14
set security ike proposal IKE-PROP encryption-algorithm aes-256-cbc
set security ike proposal IKE-PROP authentication-algorithm sha-256
set security ike policy IKE-POL mode main
set security ike policy IKE-POL proposals IKE-PROP
set security ike policy IKE-POL pre-shared-key ascii-text MySecretKey
set security ike gateway IKE-GW ike-policy IKE-POL
set security ike gateway IKE-GW address 2.2.2.2
set security ike gateway IKE-GW external-interface ge-0/0/0.0
set security ike gateway IKE-GW version v2-only
set security ike gateway IKE-GW dead-peer-detection interval 10 threshold 3

On SRX-B mirror the same commands with the peer address 1.1.1.1 and its own external interface. The security level of the proposals must match on both ends.

Three details are worth calling out. First, version v2-only removes IKEv1 negotiation from the picture; if the remote device only supports IKEv1, use version v1-only and expect a main-mode policy. Second, dead peer detection makes the SRX tear down a tunnel whose peer has silently disappeared, which is what allows routing to fail over instead of black-holing traffic into a dead tunnel. Third, if the peer uses a different identity than its IP address, add local-identity and remote-identity to the gateway; those identities, not the tunnel addresses, are what get compared during authentication.

Phase 2 (IPsec) configuration

set security ipsec proposal IPSEC-PROP protocol esp
set security ipsec proposal IPSEC-PROP encryption-algorithm aes-256-cbc
set security ipsec proposal IPSEC-PROP authentication-algorithm hmac-sha-256-128
set security ipsec proposal IPSEC-PROP lifetime-seconds 3600
set security ipsec policy IPSEC-POL proposals IPSEC-PROP
set security ipsec policy IPSEC-POL perfect-forward-secrecy keys group14
set security ipsec vpn IPSEC-VPN bind-interface st0.0
set security ipsec vpn IPSEC-VPN ike gateway IKE-GW
set security ipsec vpn IPSEC-VPN ike ipsec-policy IPSEC-POL
set security ipsec vpn IPSEC-VPN establish-tunnels immediately
set security ipsec vpn IPSEC-VPN vpn-monitor source-interface st0.0
set security ipsec vpn IPSEC-VPN vpn-monitor destination-ip 10.2.2.1

establish-tunnels immediately brings the tunnel up as soon as the configuration commits instead of waiting for traffic; with it you can verify Phase 2 right away. The vpn-monitor statements send periodic pings through the tunnel to a destination on the far side, which is how the SRX knows the tunnel is not just negotiated but actually passing traffic — useful for alerting and, in a chassis cluster, for triggering failover. If the peer is a third-party device that insists on proxy IDs, add a traffic selector to the VPN so the SRX offers 0.0.0.0/0 on both sides:

set security ipsec vpn IPSEC-VPN traffic-selector TS-ANY local-ip 0.0.0.0/0
set security ipsec vpn IPSEC-VPN traffic-selector TS-ANY remote-ip 0.0.0.0/0
set security ipsec vpn IPSEC-VPN traffic-selector TS-ANY protocol any

Perfect forward secrecy is optional but recommended: without it, a compromised Phase 1 key can be used to derive Phase 2 keys retroactively. With it, every rekey requires a fresh Diffie-Hellman exchange, so both ends must be configured identically.

The st0 tunnel interface

set interfaces st0 unit 0 family inet address 192.168.0.1/30

The st0 interface is where the design becomes "route-based". It has no VLAN tagging and no physical association: the interface exists in the security zone you place it in, and traffic routed to it is encapsulated by the VPN bound to that unit. Keep this in mind when reading configurations from elsewhere — older examples add unit 0 with explicit encapsulation, while current Junos configures the interface in the same family inet stanza as any other logical interface.

One st0 unit can carry only one VPN. To terminate several tunnels on the same firewall, use additional units:

set interfaces st0 unit 1 family inet address 192.168.1.1/30
set security ipsec vpn IPSEC-VPN-BRANCH bind-interface st0.1
set security ipsec vpn IPSEC-VPN-BRANCH ike gateway IKE-GW-BRANCH
set security ipsec vpn IPSEC-VPN-BRANCH ike ipsec-policy IPSEC-POL

Zones, policies and routing

set interfaces st0 unit 0 family inet address 192.168.0.1/30
set security zones security-zone VPN host-inbound-traffic system-services ike
set security zones security-zone VPN interfaces st0.0
set security zones security-zone UNTRUST host-inbound-traffic system-services ike
set security zones security-zone UNTRUST interfaces ge-0/0/0.0
set security policies from-zone TRUST to-zone VPN policy lan-to-vpn match source-address 10.1.1.0/24
set security policies from-zone TRUST to-zone VPN policy lan-to-vpn match destination-address 10.2.2.0/24
set security policies from-zone TRUST to-zone VPN policy lan-to-vpn match application any
set security policies from-zone TRUST to-zone VPN policy lan-to-vpn then permit
set security policies from-zone VPN to-zone TRUST policy vpn-to-lan match source-address 10.2.2.0/24
set security policies from-zone VPN to-zone TRUST policy vpn-to-lan match destination-address 10.1.1.0/24
set security policies from-zone VPN to-zone TRUST policy vpn-to-lan match application any
set security policies from-zone VPN to-zone TRUST policy vpn-to-lan then permit
set routing-options static route 10.2.2.0/24 next-hop st0.0

Create the return policy from-zone VPN to-zone TRUST with the source/destination reversed, plus an any-any tunnel policy between VPN and VPN zones if needed. The static route toward st0.0 is what makes this a route-based VPN: the remote LAN prefix is reached through the tunnel interface and IKE is allowed as a host-inbound service on the untrust interface.

Two mistakes account for most "the tunnel is up but nothing works" cases. The first is forgetting the return policy: IKE and IPsec succeed, pings from the far side are dropped by policy, and the tunnel looks healthy while carrying nothing. The second is missing host-inbound for IKE on the external interface, which leaves the gateway stuck in a negotiation loop.

When the topology grows, replace the static route with an IGP riding the tunnel — then the VPN zone needs to accept the routing protocol:

set security zones security-zone VPN host-inbound-traffic protocols ospf
set protocols ospf area 0.0.0.0 interface st0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive

With OSPF over st0, new subnets behind either firewall are reachable without touching the VPN configuration, which is the main practical advantage of the route-based design.

NAT and the tunnel

If the untrust interface already has source NAT for internet access, that NAT rule will happily translate traffic destined for the remote LAN and hand it to the tunnel with the wrong addresses. Junos evaluates source NAT rule sets in order, so the fix is an explicit no-NAT rule above the general rule, matched on the destination:

set security nat source rule-set trust-to-untrust rule no-nat match destination-address 10.2.2.0/24
set security nat source rule-set trust-to-untrust rule no-nat then source-nat off
set security nat source rule-set trust-to-untrust rule internet-nat match source-address 10.1.1.0/24
set security nat source rule-set trust-to-untrust rule internet-nat then source-nat interface

Destination NAT on the far side follows the same logic: if the remote site publishes servers with destination NAT, the addresses you route into the tunnel must be the translated ones.

MTU, MSS and fragmentation

set security flow tcp-mss ipsec-vpn mss 1350

ESP encapsulation plus the outer IP header consumes roughly 50 to 70 bytes of the path MTU. Large TCP segments that fit the LAN but not the tunnel are fragmented or dropped, and the result is a VPN where pings and small requests work perfectly while file transfers, web pages and anything with large payloads hang. Clamping TCP MSS for VPN traffic is the standard mitigation; if the tunnel carries UDP-heavy traffic, plan the interface MTU accordingly and test with ping ... do-not-fragment size 1400 from end to end.

Verification

show security ike security-associations
show security ike security-associations detail
show security ipsec security-associations
show security ipsec security-associations detail
show security ipsec statistics
show security flow session | match "10.1.1|10.2.2"
ping 10.2.2.1 source 10.1.1.1

The IPsec SA table shows the tunnel with its SPI and lifetime; a healthy pair shows Phase 1 (IKE) and Phase 2 (IPsec) SAs up in both directions. If the tunnel stays down, check the IKE proposal match, pre-shared key, external interface, and that the peer's LAN prefix in the static route points at the right st0 unit — the discipline is the same as for the SRX basics in our SRX internet configuration guide and SRX security policy guide.

Troubleshooting checklist

• Phase 1 stuck in negotiation — proposal mismatch (encryption, hash, DH group), wrong pre-shared key, IKE version mismatch, or the peer's identity not matching the gateway configuration. Use clear security ike security-associations after every change instead of waiting for a rekey.
• Phase 1 up, Phase 2 fails — proposal or PFS mismatch, or a proxy-ID/traffic-selector mismatch with a third-party peer. Debug with set security ike traceoptions flag all and set security ipsec traceoptions flag all, remembering to remove them afterwards.
• Both phases up, no traffic passes — missing or reversed return policy, missing route for the remote prefix, a NAT rule capturing the tunneled flow, or an address mismatch on st0 (both ends must be in the same subnet).
• Some traffic passes, large transfers stall — MTU and MSS, as above.
• Tunnel flapping — dead peer detection too aggressive for the path, or a WAN link that loses packets when saturated.

Scaling and HA considerations

For multiple sites, give each peer its own st0 unit and its own gateway, then let routing decide which tunnel a prefix uses. Static routes per prefix are simple and predictable; OSPF over the tunnels scales better and removes the need to touch the firewall when a new subnet appears behind a remote site.

In a chassis cluster, the tunnel endpoints live on reth interfaces and st0 units are configured in redundancy groups, so a failover moves the tunnel with the interface. Combine vpn-monitor with IP monitoring so that a tunnel failure — not just an interface failure — can trigger the failover, and expect the IKE session to re-establish on the newly active node. The cluster prerequisites are covered in our SRX chassis cluster guide, and for IKE debugging on either platform see IKEv2 debugs and SA initiation troubleshooting and the SRX troubleshooting command cheat sheet.

原文链接：https://letsconfig.com/how-to-configure-site-to-site-route-based-ipsec-vpn-on-juniper-srx