Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Example: Configure IPSec VPN in Active/Active Multinode High Availability on SRX Series Firewalls in a Layer 3 Network

This example shows how to configure and verify IPsec VPN for active-active Multinode High Availability setup.

Overview

Multinode High Availability supports IPsec VPN in active/active mode with multiple SRG1s (SRG1+). Each SRG still operates in active-backup mode between the two nodes, but different SRGs can be active on different nodes. This model allows multiple active IPsec tunnels to be established from both nodes simultaneously, enabling encryption and decryption on both nodes and improving bandwidth utilization.

In this example, you configure Multinode High Availability (MNHA) between two firewalls and establish high‑availability IPsec VPN tunnels from the MNHA firewall pair to a peer device. The focus is on ensuring that IPsec tunnels can be successfully established and maintained with seamless failover between the firewalls in MNHA setup.

Example Prerequisites

Software requirements

  • Supported firewall devices with Junos OS Release 22.4R1 or later. This example is tested with Junos OS Release 25.4R1.

  • Configure firewall filtering and quality of service (QoS) as per your network requirements and have appropriate security policies to manage traffic in your network.

  • In a typical high-availability setup, you use multiple routers and switches on both the northbound and southbound sides. In this example, use two routers on each side of the firewalls. Configure all upstream and downstream routers according to your network requirements

  • Install the Junos IKE package on your security devices using the request system software add optional://junos-ike.tgz command. The junos-ike package is included in your Junos software packages (Junos OS Release 20.4R1 onwards).

Before You Begin

Benefits

Active/active IPsec VPN in an MNHA setup improves availability and performance by allowing both nodes to simultaneously terminate and forward VPN traffic, enabling load sharing, faster convergence, and minimal traffic disruption during failures.

Know more

IPsec VPN in Active-Active Mode on MNHA

Learn more

IPsec VPN User Guide

Functional Overview

Technologies used
  • Multinode high availability
  • IPsec VPN
  • Monitoring options
  • Interfaces and zones
  • Routing policy, protocols, and routing options

Primary verification tasks
  • High Availability information about both nodes
  • IPsec VPN connectivity from peer device to MNHA setup

Topology Overview

Figure 1 shows the topology used in this example.

Figure 1: Active/Active Multinode High Availability in Layer 3 Deployment Active/Active Multinode High Availability in Layer 3 Deployment

The topology demonstrates an active/active IPsec VPN deployment using Multinode High Availability (MNHA) with two firewalls forming an MNHA cluster and establishing IPsec VPN tunnels to a remote firewall (SRX-03).

The SRX-03 device acts as a peer device to the MNHA setup and it establishes individual IPsec VPN tunnels each with SRX-01 and SRX-02 devices. From the perspective of SRX‑03, the MNHA pair functions as a single logical VPN endpoint.

Traffic from the internal host flows through Router 1 → MNHA setup→ IPsec tunnels → Router 2 → SRX‑03 → Router 3. Return traffic follows the same encrypted paths. This example verifies traffic reachability from Router 3—where SRX-03 (the peer device) is connected—to Router 1, which has a remote host PC attached.

  • SRX‑01 and SRX‑02 operate as an MNHA pair with multiple SRGs (SRG1+), enabling traffic to be processed actively on both nodes.
  • Each SRG runs in active–backup mode internally, while the overall solution provides active‑active VPN forwarding across SRGs.
  • The nodes are connected through a routed, encrypted inter‑chassis link (ICL) in the HA Link zone, using floating loopback IP addresses to synchronize control and VPN state. In this example, the link uses the ge-0/0/2.0 interface directly between devices instead of passing through an intermediate routed network.
  • Trust zone interfaces connect the MNHA cluster toward the internal network through Router 1 (AS 65030).
  • Untrust zone interfaces connect both SRX‑01 and SRX‑02 to Router 2 (AS 65035), which provides upstream reachability toward the remote VPN site.
  • Loopback interface (lo0.0) on each SRX hosts floating IP addresses.
  • SRX‑03 terminates IPsec VPN tunnels from the MNHA cluster and connects to Router 3.
  • The remote SRX uses its own loopback interface as the VPN endpoint, ensuring tunnel stability independent of physical interface state.
  • The VPN interfaces are placed in the VPN zone, separating encrypted traffic from untrusted transit networks.
  • Multiple IPsec tunnels are established between the MNHA cluster and SRX‑03, bound to different SRGs. If a node or SRG fails, traffic is redirected to the remaining active SRG without tunnel renegotiation, as the VPN endpoints use floating IP addresses.

The following table shows the details on interfaces configuration used in this example.

Table 1: Interfaces and IP Address Configuration on Security Devices
Device Interface Zone IP Address Configured For
SRX-01 lo0.0

Untrust

10.11.0.1/32

Floating IP address

IKE Gateway address

10.12.0.1/32

IKE Gateway address

ge-0/0/2.0

HA Link

10.22.0.2/24

Connecting ICL

ge-0/0/4.0

Untrust

10.5.0.1/24

Connects to R2 router

ge-0/0/3.0

Trust

10.3.0.2/24

Connects to R1 router
SRX-02

lo0.0

Untrust

10.12.0.1/32

Floating IP address

IKE Gateway address

10.11.0.1/32

IKE Gateway address

ge-0/0/2.0

HA Link

10.22.0.1/24

Connecting ICL

ge-0/0/3.0

Trust

10.2.0.2/24

Connects to R1 router

ge-0/0/4.0

Untrust

10.4.0.1/24

Connects to R2 router
SRX-03 lo0.0

Untrust

10.112.0.1/32

IKE Gateway address

10.112.0.5/32

IKE Gateway address

ge-0/0/0.0

Untrust

10.7.0.1/24

Connects to R2 router

ge-0/0/1.0

Trust

10.6.0.2/24

Connects Router
Table 2: Interfaces and IP Address Configuration on Routing Devices
Device Interface IP Address Configured For
Router 2 (R2) lo0

10.111.0.2/32

Loopback interface address of R2

ge-0/0/1

10.4.0.2/24

Connects to SRX-02

ge-0/0/0

10.5.0.2/24

Connects to SRX-01

ge-0/0/2

10.7.0.2/24

Connects to SRX-03 (VPN peer device)
Router 1 (R1) lo0

10.111.0.1/32

Loopback interface address of R1

ge-0/0/0

10.3.0.1/24

Connects to SRX-01

ge-0/0/1

10.2.0.1/24

Connects to SRX-02
  • ge-0/0/2.100
  • ge-0/0/2.101
  • 10.1.0.1/24
  • 10.1.1.1/24
 Connects to Host network
Router 3 (R3)

ge-0/0/0

10.6.0.1/24

Connects to SRX-03
lo0

10.6.255.1/32

Loopback interface address of R3

Configure Firewalls

  1. Configure interfaces for ICL, internal and external traffic and setup the loopback interface lo0.0 with a floating IP address to reach the peer gateway. We'll use 10.11.0.1 as the floating IP address and 10.12.0.1 as IKE gateway address.
    • Node 1
    • Node 2
  2. Configure security zones as required for your network, and allow necessary host‑inbound system services.
    • Node 1
    • Node 2
    CAUTION:

    The configuration examples provided in this document allow all host inbound protocols and services for simplicity. In a production deployment, you must restrict inbound access to only the protocols and services required for your environment. For an MNHA setup, this configuration typically includes allowing IKE, BGP, and BFD. Always tailor the security rules to align with your network and security requirements.

  3. Configure the security policy.
    CAUTION:

    The security policy shown in this example is only for demonstration and testing. You should configure security policies as per your network needs. Ensure that your security policies allow only the applications, users, and devices that you trust.

    Node 1 and Node 2

  4. Configure the local and peer node IDs on both security devices. Assign unique identifiers so each device can determine its role in the MNHA pair.
    • Node 1
    • Node 2
  5. Configure services redundancy groups SRG1 and SRG2. Use separate redundancy groups as needed to manage failover for different service sets.
    1. Node 1
      • SRG1
    2. SRG2

      You can configure up to 64 IP addresses for IP monitoring and activeness probing. The total 64 IP addresses is sum of the number of IPv4 and IPv6 addresses.

    • Node 2
      • SRG1
      • SRG2
  6. Configure routing policy and routing options. Define route preferences and policies that support MNHA failover and traffic steering. In this step, you configure:
    • Active/active traffic distribution across MNHA nodes
    • Policy‑controlled BGP advertisement per SRG
    • Configure BFD monitoring. BFD provides fast failure detection for protected links and paths.
    • Symmetric IPsec traffic forwarding

    • Define SRG prefixes. The prefix list defines which routes (prefixes) are associated with SRGs so that traffic for those prefixes is steered to and processed by SRG.

      Node 1Node 2

    • Create route‑filter lists to specify advertisable routes.

      Node 1Node 2

    • Configure MNHA route export policy. This configuration advertises routes with a preferred metric (metric 10) when active and less preferred metric (metric 20) when backup.

      Node 1Node 2

    • Define conditional health checks. This configuration determines whether the node is active or backup for each SRG based on route presence.

      Node 1Node 2
      Note: You must specify the active signal route along with the route-exists policy in the policy-options statement. When you configure the active-signal-route with if-route-exists condition, the HA module adds this route to the routing table.
      Note:

      Configure active signal routes 10.39.1.1 (SRG1) and 10.49.1.1 (SRG2) with the if-route-exists match condition. MNHA adds these routes when a node becomes active, and the node advertises the routes with higher preference. Configure backup signal routes 10.39.1.2 and 10.49.1.2 with medium priority for the standby node. On failure, the HA link goes down, the active node drops its primary role and removes the active signal route. The backup node detects this through probes, becomes active, and its route preference increases to take all traffic.

    • Configure BGP.

      Node 1Node 2
  7. Configure base reachability required for BGP conditions.
    • Node 1
    • Node 2
  8. Encrypt the ICL. Configure a VPN profile for ICL high‑availability traffic using IKEv2 and define IKE and IPsec parameters that protect MNHA control and state synchronization over the ICL.

    • Node 1 and Node 2

      Note:

      • Specifying the ha-link-encryption option encrypts the ICL to secure high availability traffic flow between the nodes.

      • The same VPN name ICL_IPSEC_VPN must be mentioned for vpn_profile in the set chassis high-availability peer-id <id> vpn-profile vpn_profile configuration.

      • For the Multinode High availability feature, you must configure the IKE version as v2-only

  9. Configure IPsec VPN options to establish tunnels with SRX‑03 and enable IPsec VPN configuration synchronization on both devices by using the groups option.
    Node 1 and Node 2
    • IPSec VPN configuration for SRG1 and SRG2.

      In the above configuration, SRG1 VPNs (SRG1_IPSEC_VPN1) rely on route‑based forwarding without explicit traffic selectors, while SRG2 (SRG2_IPSEC_VPN500) uses traffic selectors. Traffic selectors define the exact local and remote IPs whose traffic must be encrypted and sent through the IPsec tunnel. A static route toward the st0 interface ensures that matching traffic is forwarded into the VPN tunnel instead of the default forwarding path. Both approaches can be used —depending on the deployment.

Configuration on VPN Peer Device

Configure the VPN peer device SRX‑03 with matching IPsec VPN options. Ensure IKE and IPsec parameters (peers, proposals, and policies) match those options on SRX‑01 and SRX‑02 to bring tunnels up successfully.

  1. Configure the interfaces to establishes trust, untrust, and VPN connectivity, with loopback addresses used as IKE endpoints.
  2. Define security zones.
  3. Create the IKE proposal.
  4. Define IKE policies.
  5. Create an IKE gateway, define address, specify external interfaces and version.
  6. Create IPsec proposals.
  7. Create IPsec policies.
  8. Create separate IKE gateways and IPsec VPNs for SRG1 and SRG2.

    In this step, use the same configuration approaches—static routes for SRG1 VPNs (SRG1_IPSEC_VPN1) and traffic selectors for SRG2 (SRG2_IPSEC_VPN500)—to align with the IPsec VPN configuration in the MNHA setup.

  9. Create a security policy.

    For this example, we’ve configured a policy to permit all traffic. We strongly recommend you to create security policies as per your network requirements to permit traffic that is allowed by your organizational policy and deny all other traffic. We've used the default policy for the demo purpose only in this example.

  10. Configure the static routes.

Verification

Use the show commands to confirm that the configuration is working properly.

Table 3: Show Commands for Verification
Command Verification Task

show chassis high-availability information

Display details of the MNHA status on your security device including health status of the peer node.
show securiti ike security-associationsshow securiti ipsec security-associations

Display status about IPsec VPN connections

Check Multinode High Availability Setup

Purpose

View and verify the details of the Multinode High Availability setup configured on your security device.

Action

From operational mode, run the following command:

SRX-01

SRX-02

Meaning

Verify these details from the command output:

  • Local node and peer node details such as IP address and ID.

  • The field Encrypted: YES indicates that the traffic is protected.

  • The field Deployment Type: ROUTING indicates a Layer 3 mode configuration—that is, the network has routers on both sides.

  • The field Services Redundancy Group: 1 and Services Redundancy Group: 2 indicate the status of the SRG1 and SRG2 (active or backup) on that node.

Check Multinode High Availability Service Redundancy Groups

Purpose

Verify that the SRGs are configured and working correctly.

Action

From operational mode, run the following command:

Meaning

Verify these details from the command output:

  • Peer node details such as deployment type, status, active and back up signal routes.

  • Split-brain preventions probe, IP monitoring and BFD monitoring status.

  • Associated IP prefix table.

Check IPsec VPN Status

Purpose

Confirm VPN status by checking the status of any IKE security associations at SRG level.

Action

Run the following commands on SRX-01, SRX-02, and SRX-03 (VPN peer device):

SRX-01

SRX-02

SRX-03

Meaning

Verify these details from the command output:

  • IP addresses of the remote peers.
  • The state showing UP for both remote peers indicates the successful association of Phase 1 and Phase 2 establishment.
  • The remote peer IP address, IKE policy, and external interfaces are all correct.
  • The IPsec tunnels are up, actively passing traffic, and operating without errors

Testing Traffic Flow Across the VPN

Purpose

Verify the traffic flow across the VPN.

Action

Use the ping command from Router 3, which is connected to the peer VPN firewall (SRX-03), to test traffic flow to Router 1, where the host is connected.

From operational mode, enter the ping command.

Meaning

This ping output confirms successful end‑to‑end connectivity across the IPsec VPN between the remote site and the internal network.

If the ping command fails, there might be a problem with the routing, security policies, end host, or encryption and decryption of ESP packets

Verify Interchassis Link (ICL) Encryption Status

Purpose

Verify the interchassis link (ICL) status.

Action

Run the following command on SRX-01:

Meaning

The command output provides IPsec SAs used to encrypt the MNHA ICL link. It protects control, routing, and state synchronization traffic between SRX‑01 and SRX‑02

CAUTION:

The IP range (180.100.1.x) shown in the command output serves as the ICL IPsec traffic selector. The system dynamically assigns this IP range, and it is essential not to alter or modify it. Additionally, BFD (Bidirectional Forwarding Detection) will be automatically enabled for the broader 180.x.x.x IP range.

Set Commands on all Devices

vSRX Virtual Firewall (SRX-01)

vSRX Virtual Firewall (SRX-02)

vSRX Virtual Firewall (SRX-03)

Router 1

Router 2

Router 3

Show Configuration Output

From configuration mode, confirm your configuration by entering the show high availability, show security zones, and show interfaces commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

vSRX Virtual Firewall (SRX-01)

vSRX Virtual Firewall (SRX-02)

vSRX Virtual Firewall (SRX-03)

See Also