Junos Dual-WAN IPsec VPN: Match Source Path to Gateway

Two WAN links per site look like redundancy until you try to prove which address pair a given flow actually used. On an SRX, one IKE gateway carries one external interface and one local address; a list of remote candidates does not create a second local source. That is why this walkthrough starts with the pair matrix instead of the configuration, because Junos will happily commit a design that covers only half of your intended combinations. I hit this on a pair of SRX345s, where the backup tunnel came up cleanly and still dragged the session down on failback.

Work through the steps in order: enumerate the pairs you must support, build one gateway per local source, confirm which association carried traffic, and only then decide what each kind of failure is allowed to change.

Map the pairs before you touch the CLI

If site A can source from A1 or A2 and site B can receive on B1 or B2, you have four outer address pairs. Most designs need two of them continuously and treat the other two as nice-to-have. Write the matrix down and mark each row, because every row you promise costs you a gateway, a tunnel interface and a route decision later.

Each required pair needs three things at once: a reachable underlay between those exact addresses, mutual acceptance of the peer identity and source address at both ends, and a protected return path. A pair that works in one direction only will still show a tunnel, and the failure surfaces later as one-way application traffic.

One gateway per local source, not per remote site

The remote address list belongs to a gateway, and so does the local source. Juniper's IKE gateway reference keeps remote addresses, external interface, local address and dead-peer detection as separate settings, which is the whole point: two local sources means two gateways over two st0 units. Sharing the IKE policy between them is fine; keeping one gateway and hoping it re-sources itself is not.

set security ike policy IKE-P1 mode main
set security ike gateway GW-A1 ike-policy IKE-P1
set security ike gateway GW-A1 address 198.51.100.20
set security ike gateway GW-A1 address 198.51.100.21
set security ike gateway GW-A1 external-interface ge-0/0/0
set security ike gateway GW-A1 local-address 203.0.113.10
set security ike gateway GW-A1 version v2-only
set security ike gateway GW-A2 ike-policy IKE-P1
set security ike gateway GW-A2 address 198.51.100.20
set security ike gateway GW-A2 external-interface ge-0/0/3
set security ike gateway GW-A2 local-address 192.0.2.10
set security ike gateway GW-A2 version v2-only

Then attach the tunnels and give the far prefix two next hops, one per tunnel:

set interfaces st0 unit 1 family inet
set interfaces st0 unit 2 family inet
set security ipsec policy IPSEC-P1 perfect-forward-secrecy keys group14
set security ipsec vpn VPN-A1 bind-interface st0.1
set security ipsec vpn VPN-A1 ike gateway GW-A1 ipsec-policy IPSEC-P1
set security ipsec vpn VPN-A2 bind-interface st0.2
set security ipsec vpn VPN-A2 ike gateway GW-A2 ipsec-policy IPSEC-P1
set routing-options static route 10.20.0.0/16 qualified-next-hop st0.1 preference 10
set routing-options static route 10.20.0.0/16 qualified-next-hop st0.2 preference 20

Whether one gateway may hold two address statements depends on the release and on which IKE process the box runs. Older kmd-based Junos takes a single remote address per gateway; newer builds handle multiple candidates but add their own constraints, and high-availability clusters are a common place where that support narrows. Check the release notes for your exact build before copying this from an older chassis.

Confirm which association carried the packet

Two SAs and two tunnels do not tell you which one forwarded the session. Ask the box directly, and compare the fields against the pair you intended:

show security ike sa detail
show security ipsec sa detail
show security flow session destination-prefix 10.20.1.0/24
show interfaces st0.1 | match packets

The detail output reports the local and remote gateway for each association, which is the fastest way to spot a tunnel that negotiated from a source you did not expect. Then watch the per-unit packet counters on st0.1 and st0.2 while you push traffic through; a tunnel that carries nothing keeps its SA and looks healthy in a summary view.

Give each failure its own detector

Peer liveness, local uplink loss, protected-route withdrawal and application breakage are four different events. DPD answers only the first one, so configure it with an interval and threshold you can defend rather than leaving the default and assuming it covers the rest:

set security ike gateway GW-A1 dead-peer-detection interval 10
set security ike gateway GW-A1 dead-peer-detection threshold 3
set security ipsec vpn VPN-A1 vpn-monitor source-interface st0.1
set security ipsec vpn VPN-A1 vpn-monitor destination-ip 10.20.0.1

Tunnel monitoring that probes a destination inside the far subnet covers the case DPD cannot see: IKE is alive, the gateway answers, and the protected prefix is unreachable anyway. Pick which of the two should pull preference, because both firing at once produces a change storm instead of a clean failover.

Do not forget the far end. A preferred route that stays installed on the remote site keeps pointing into a tunnel you already abandoned, and no local timer fixes that. Publish the same preference logic on both peers, and record whether a recovered link may take traffic back automatically or has to be switched by hand.

Readdress one link without touching the other

When an ISP hands you a new block, change one relationship at a time. Update the address or local-address on both peers for that pair, commit, and clear only the affected associations by index rather than clearing every SA on the box. A global clear takes out the healthy tunnel too and turns a maintenance window into an outage.

Keep one failed flow and its session detail as evidence before you clean anything up, then re-run the checks above against the new address pair. Restoring a link is a routing decision, so treat the reversion as its own tested step rather than assuming the old preference returns by itself.

Close the change with a short checklist

A dual-WAN tunnel design is finished when you can name the pair behind every session, not when both SAs are up. Walk the list below on the box you actually changed:

• Every promised pair has a gateway, an st0 unit and a route entry.
• Each tunnel has been seen carrying packets, not just holding an SA.
• Both ends agree on detection and on which side restores preference.
• The return path for each pair is written down next to its forward path.

If a line fails, fix that pair before adding the next one; stacking two half-working tunnels makes the counters meaningless and the failover behaviour impossible to predict.