Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Multinode High Availability in Azure Cloud

Read this document to understand how to configure Multinode High Availability on vSRX instances deployed on Azure cloud.

Overview

You can configure Multinode High Availability on vSRX Virtual Firewalls deployed in the Microsoft Azure Cloud. Microsoft Azure is Microsoft's application platform for the public cloud. It is an open, flexible, enterprise-grade cloud computing platform for building, deploying, and managing applications and services through a global network of Microsoft-managed data centers.

You can configure a pair of vSRX virtual firewalls on Azure to operate as in an active/backup Multinode high availability configuration. Participating nodes run both active control and data planes at the same time. The nodes backup each other to ensure a fast synchronized failover in case of a system or hardware failure. The interchassis link (ICL) connection between the two devices synchronizes and maintains the state information and handles device failover scenarios.

You can configure Multinode High Availability on vSRX Virtual Firewall VMs by customizing firewall deployment settings in Microsoft Azure Cloud.

IPsec VPN Support

Starting in Junos OS Release 24.4R1, we support IPsec VPN for active/backup Multinode High Availability in Azure Cloud deployments.

Limitation

Multinode High Availability doesn’t support multiple SRG configurations (active/active) in public cloud deployments. Active/backup mode supports SRG0 or SRG1. IPsec VPN tunnel anchors at the SRG1, which works in a stateful active/backup mode. All VPN tunnels terminate on the device where the SRG1 is active.

Architecture

Figure 1 shows two vSRX Virtual Firewall instances form a Multinode high availability pair in the in the Azure cloud. One vSRX Virtual Firewall instance acts as the active node and the other instance acts as the backup node. Both nodes connect to each other using an ICL to synchronize and maintain state information and to handle device failover scenarios.

Figure 1: vSRX in Multinode High Availability Deployments in Azure CloudNetwork architecture diagram showing security setup in Microsoft Azure with users, internet gateway, untrust zone, vSRX nodes, trust zone, and protected resources.

vSRX Virtual Firewall requires two public IP addresses and one or more private IP address for each individual instance group. The public subnets consist of one for the management interface (fxp0) and one for a revenue (data) interface. You can use any four revenue interfaces for the subnet configuration. The private interface is connected to the protected resources. It ensures that all traffic between applications on the private subnet and the Internet must pass through the vSRX Virtual Firewall instance.

For Multinode High Availability on Azure, you must deploy both the firewalls within the same Azure Resource Group. An Azure Resource Group is a logical container that holds related resources for an Azure solution. It can include all the resources for the solution, or only those resources that you want to manage as a group.

You must allocate a node-specific primary address to each node and a common secondary or floating IP address to both the nodes. The secondary IP address, which acts as a floating IP address, is always attached to the active node. In case of failure on the current active node, the secondary IP address transitions from the failed active node to the current active node. The new active node ensures the continue flow of traffic.

Initially both the nodes are launched with predefined tags stating which one is the owner of the secondary IP address during boot up. That particular node starts operating as the active node and other one starts as a backup node.

Split-Brain Protection

The split-brain scenario refers to a situation where both nodes of the Multinode High Availability system become stuck in the same state, either active or backup, when the inter-chassis link (ICL) between the nodes is down. To prevent this state, both nodes attempt to probe the primary IP address of the trust or the untrust interface, based on the configuration.

When an Interchassis Link (ICL) experiences a failure along with a probe failure, the node that does not receive a reply from its peer will take on the active role. However, if the probe succeeds and confirms that the peer node is still operational, the node will maintain its current state. This probing process persists until the ICL is restored.

Example: Configure Multinode High Availability in Azure Cloud Deployment

Read this topic to understand how to configure the Multinode High Availability solution on SRX Series Firewalls.

You can configure a pair of vSRX virtual firewalls on Azure to operate as in an active/backup Multinode high availability configuration. Participating nodes run both active control and data planes at the same time. The nodes backup each other to ensure a fast synchronized failover in case of a system or hardware failure. The interchassis link (ICL) connection between the two devices synchronizes and maintains the state information and handles device failover scenarios.

In this example, we'll show you how to configure Multinode High Availability on two vSRX Virtual Firewall instances deployed in the Azure Cloud.

Tip:
Table 1: Readability Score and Time Estimates

Reading Time

45 Minutes

Configuration Time

1.5 hour

Example Prerequisites

VMs requirements

Two vSRX Virtual Firewalls deployed on Azure Cloud

Software requirements

Junos OS Release 23.4R1 or later releases

Licensing requirements

Use vSRX Virtual Firewall license or request an evaluation license. Licenses can be procured from the Juniper Networks License Management System (LMS).

Check the following links for details:

Before You Begin

Benefits

Increases the availability of vSRX Series firewalls deployed in Azure that results in improved reliability and reduced downtime.

Know more

vSRX Virtual Firewall with Microsoft Azure Cloud

Learn more

Deploying Juniper Security in AWS and Azure

Functional Overview

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

Primary verification tasks
  • High Availability information about both nodes
  • Multinode High Availability status on Azure Cloud

Topology Overview

Figure 2 shows the topology used in this example.

Figure 2: Multinode High Availability Configuration on vSRX VMs Deployed in Azure Multinode High Availability Configuration on vSRX VMs Deployed in Azure

The topology illustrates a Multinode High Availability (MNHA) setup using two vSRX Virtual Firewall instances—Node 1 and Node 2—deployed in Microsoft Azure. This configuration ensures redundancy and seamless failover for secure traffic handling.

Table 2 and Table 3 provide interface and IP address details used in this example.

Table 2: Interfaces and IP Addresses on Active Node
Interface Subnet Private IP Public IP Role/Notes
fxp0 10.10.0.0/24

10.10.0.4

 203.0.113.33 Management Interface
ge-0/0/0 10.10.1.0/24

10.10.1.4

 - Connects ICL (Inter-Cluster Link)
ge-0/0/1 (Primary) 10.10.2.0/24

10.10.2.4

 - Connects untrust zone to Internet
ge-0/0/1 (Secondary) 10.10.2.0/24

10.10.2.5

198.51.100.253

 Acts as secondary IP
ge-0/0/2 (Primary) 10.10.3.0/24

10.10.3.4

 - Connects trust zone to protected subnet
ge-0/0/2 (Secondary) 10.10.3.0/24

10.10.3.5

 - Secondary IP
Table 3: Interfaces and IP Addresses on Backup Node
Interface Subnet Private IP Public IP Role/Notes
fxp0 10.10.0.0/24

10.10.0.5

 203.0.113.35 Management interface
ge-0/0/0 10.10.1.0/24

10.10.1.5

 - Connects to ICL
ge-0/0/1 (Primary) 10.10.2.0/24

10.10.2.6

 - Connects untrust zone to Internet
ge-0/0/2 (Primary) 10.10.3.0/24

10.10.3.6

 - Connects trust zone to protected subnet

Key Components

  • vSRX Nodes

    • Node 1 and Node 2 act as firewall peers in an MNHA cluster.
    • Each node has:
      • Untrust Interface (Ge-0/0/1): Connects to the public subnet, which has Internet access
      • Trust Interface (Ge-0/0/2): Connects to protected resources in the private subnet.
      • Management Interface (FXP0): Used for out-of-band management.

  • Public and Private Subnets

    • Both vSRX nodes are placed in the public subnet to provide connectivity to the Internet gateway.
    • The untrust side handles external traffic.
    • Protected resources are located in the private subnet, connected to the trust interfaces of both nodes.

  • Interchassis Link (ICL)

    • Interfaces Ge-0/0/0 on both nodes form the ICL.
    • Uses routable IP addresses (10.10.1.4 and 10.10.1.5).

To deploy vSRX Virtual Firewall instances in Microsoft Azure, you must select the vSRX image from the Azure Marketplace and customize the virtual machine settings and associated dependencies according to your network requirements. This manual deployment approach is often required when configuring an MNHA setup for vSRX VMs. While this use case could also be automated using a CloudFormation template, such a template is currently not available.

Let’s dive into the details of each step for deploying the vSRX Virtual Firewall on Microsoft Azure.

Azure Portal Setup

In this example, you deploy two virtual machines (VMs) for vSRX Firewall instances. The following list outlines a recommended order for configuring resources in Azure for multinode high availability. However, this sequence is not a strict or mandatory rule—many tasks can be completed before or after each other, depending on your workflow. You can adjust the order to suit your requirements
  • Create Resource Group
  • Administrative Access Setup
  • Create a Virtual Network (VNet) & Subnets
  • Create Public IP Addresses
  • Create a Network Security Group (NSG)
  • Create a Storage Account
  • Deploy vSRX VMs
  • Create and Assign I AM Permissions for a Managed Identity
  • Create Interface Tags
  • Create Network Interfaces
  • Assign IP Addresses for Interfaces
  1. Create a Resource Group
    A resource group is a logical container for resources deployed in Azure. It helps you manage and organize related resources. The vSRX VM is a resource within an Azure resource group. All components related to the vSRX (such as virtual network, storage account, public IP, and so on.) are part of the same resource group.
    1. Sign into the Azure portal.
    2. Search for Resource group and create a new one.
    3. Choose a name, enter subscription, and select region for the resource group. In this example, create a resource group azure-vsrx3.0.
    4. Click Review + create and then Create. For details,

      See Create a Resource Group for details.

  2. Administrative Access Setup for the Resource Group

    This procedure grants a user or user group the necessary permissions to manage (deploy, configure, monitor, and delete) the vSRX virtual machines and associated network resources within the dedicated resource group.

    When deploying vSRX Virtual Firewalls in Azure, IAM roles are also assigned to the managed entity (the vSRX VM or its associated resources). This procedure is covered later in this procedure.

    Note:

    To perform this task, you must have "Owner" privilege.

    1. Select the specific resource group (azure-vsrx3.0 in this example).
    2. On the Resource Group blade, click Access control (IAM) in the left-side navigation panel.
    3. Click the + Add button, then select Add role assignment.
    4. Select User, group, or service principal in Members tab and select a role such as Owner, Contributor, or Reader.
    5. Click + Select members search for and select user or user group to assign the role to.
    6. Configure conditions (Optional).
    7. Click Review + assign to finalize the role assignment.
    8. Click Save.
  3. Create a Virtual Network

    A virtual network (VNet) is the foundation for your Azure infrastructure. It allows you to securely connect Azure resources. At a minimum, define:

    • A management (fxp0) subnet,
    • One or more public subnets for Internet-facing traffic
    • A private subnet for internal workloads
    • An ICL subnet for inter-node communication in an MNHA setup

    1. In the Azure portal, go to the Create a resource section. Locate and select Virtual Networks.

    2. Click + Create.
    3. In the Basics Tab, enter following details:
      • Subscription: Choose your subscription.
      • Resource Group: Select an existing group (example: azure-vsrx3.0) or create a new one.
      • Name: Enter a name for your VNet (example: mnha-vnet-zone).
      • Region: Choose the region where you want to deploy resources.
    4. Click Review + create and then Create.
    5. On the Virtual Network page, click Settings > Subnets. The subnets are used to connect the two vSRX Virtual Firewall nodes using a logical connection (like the physical cable connecting ports).

      Table 4 shows a sample configuration used in this example.

      Table 4: Subnet Configuration in Azure Portal
      Function CIDR Role
      management-subnet 10.10.0.0/24 Management traffic
      icl-subnet 10.10.1.0/24 RTO, synchronization, and probes- related traffic
      untrust-subnet 10.10.2.0/24 External traffic
      trust-subnet 10.10.3.0/24 Internal traffic
      See Create a Virtual Network for details.
  4. Create a Public IP Address
    1. In the Azure portal, go to the Create a resource section. Locate and select Network foundation and then go to Public IP address.
    2. Click Create to start setting up a new public IP address.
    3. In the Basics tab, enter following details:
      • Subscription: Choose your subscription.
      • Resource Group: Select an existing group (azure-vsrx3.0 in this example).
      • Region: Choose the region where you want to deploy resources.
      • Name: Enter a unique name for the public IP resource.
      • IP Version: Select IPv4 or IPv6 based on your requirements.
      • SKU: Choose between Basic and Standard offerings.
      • IP address assignment, Tier, Routing preference: Retain the default options for this example.
    4. Once configured, review the settings and then click Create to allocate the public IP address.

    Repeat the same steps to create other public IPs. In this example, create vsrx-r0-ip, vsrx-secondary-public-ip, and vsrx-r0b-ip.

  5. Create a Network Security Group (NSG)
    1. Navigate to Network foundation > Virtual networks, and select Network security groups.
    2. Select Create network security group.
    3. Set up your NSG with the following details:
      • Subscription: Choose your subscription.
      • Resource group: Select an existing group (azure-vsrx3.0 in this example).
      • Name: Enter a unique name for the network security group (example: vsrx-r0-nsg).
      • Region: Choose the region where you want to deploy resources.

      Network Security Group gets created. Repeat same procedure to create another network security group (vsrx-r0b-nsg).

    4. Go to Settings and define inbound and outbound security rules to control traffic to and from your NIC and VMs in Inbound security rules and Outbound security rules.
      Tip:

      We recommend the following security settings for your NSG configuration:

      • Define appropriate NSG security rules to control traffic flow according to your requirements.
      • Allow only inbound SSH, and optionally HTTPS, depending on how you manage the vSRX instance.
      • Restrict inbound access to your own source IP to prevent potential SSH brute‑force attempts.
      • If using SD Cloud, ensure the vSRX can initiate outbound connections for the following:
        • DNS
        • NTP
        • SSH on port 7804
        • SYSLOG over TLS on port 6514 (target IP depends on your SD Cloud instance)
  6. Create a Storage Account
    A storage account provides a unique space to store and access data objects in Azure.
    1. In your resource group, click Create (+).
    2. Search for "Storage account” and create a new one.
    3. Specify the name, deployment model, performance, and other settings.
    4. Click Review + create and then Create. See Create a Storage Account for details.
  7. Deploy vSRX VMs

    Use the following steps to deploy two vSRX VM instances. You’ll use these two instances to set up Multinode High Availability. For details, see Deploy the vSRX Virtual Firewall Image from Azure Marketplace.

    CAUTION:

    For this example, the values shown are chosen specifically for this use case. All other settings remain at their defaults. Select the configuration values that best match your network requirements.

    1. Search for vSRX in the Azure Marketplace by clicking on Create a resource and search for vSRX Virtual Firewall.
    2. Select the vSRX VM image from the Azure Marketplace.
    3. Configure deployment settings by providing the following details:

      Basics Tab

      1. Subscription: Choose your subscription.
      2. Resource Group: Select the resource group In this example, use the azure-vsrx3.0 which you created previously.
        Note:

        Deploy both vSRX Virtual Firewall instances in the same resource group. The resource group will hold all the resources associated with the vSRX Virtual Firewalls for this deployment.
      3. Virtual Machine Name: Enter a unique name for your vSRX VM (example: vsrx-r0).
      4. Region: Choose the region where you want to deploy resources.
      5. Image: Select the vSRX Next-generation Firewall image.
      6. Size: Select DS3_v2 Standard as the vSRX Virtual Firewall VM size for this example.
      7. Authentication type: Select the required method of authentication to access the vSRX Virtual Firewall VM: Password or SSH public key.
      8. Public inbound ports: Retain Allow selected ports option.
      9. Select inbound ports: Select SSH 22 for this example.

    4. Disks tab

      1. OS disk type: Specify the disk type to use for the vSRX Virtual Firewall VM: SSD or HDD.

    5. Networking tab

      1. Virtual Network: Select the virtual network (mnha-vnet-zone for this example).
      2. Subnet: Select the virtual network (management-subnet for this example).
      3. Public IP: Select the public IP (vsrx-r0-ip for this example).
      4. Public inbound ports: Retain Allow selected ports option.
      5. Select inbound ports: Select SSH 22 for this example.

    6. Review your settings and click Create.

    Azure will start provisioning the vSRX VM based on your configuration. After the vSRX Virtual Firewall VMs are created, the Azure portal dashboard lists the new vSRX Virtual Firewall VMs under Resource Groups.

    Note:

    Remember to customize these steps based on your specific requirements and network design.

    Deploy and configure another vSRX instance VM (vsrx-r0b) using the same steps as mentioned in this procedure.

  8. Create and Assign I AM Permissions for a Managed Identity
    Managed identities are created and linked to the resource group. These identities allow VMs to securely interact with Azure services without managing credentials.
    The person who deploys the vSRX3.0 VM in Azure must have IAM (Identity and Access Management) permissions to create a user-assigned managed identity and attach it to the VM. This managed identity acts like a service principal, allowing the VM to authenticate and call Azure services without storing credentials.
    1. Create a Managed Identity
      1. In the Azure portal, go to the Create a resource section. Locate and select Managed Identity.
      2. Click on + Create .
      3. In the Basics tab of Create User Assigned Managed Identity, enter following details:
        • Subscription: Choose your subscription.
        • Resource Group: Select an existing group (azure-vsrx3.0) in this example.
        • Name: Enter a unique name for the managed identity (example: mnha-role).
        • Region: Choose the region where you want to deploy resources.
      4. Once configured, review the settings and then click Create.

      The system displays the status, and informs once the identity is created.

    2. Associate the Managed Identity to the vSRX3.0 VM

      1. Select the first vSRX Virtual Machine in the Azure portal.

      2. Navigate to Security > Identity.

      3. Select the User assigned tab and click on + Create.

      4. Subscription: Choose your subscription.
      5. User assigned managed identities: Select the managed identity you have created (mnha-role in this example).
      6. Click Add.
    3. Assign IAM Role for VM Instance

      Assign the Custom Role (At Resource Group Scope)

      1. Navigate to the Resource Group that contains both vSRX VMs and all associated network components (NICs, IPs).

      2. Click Access control (IAM) on the left-side menu.

      3. Click Add > Add role assignment.

      4. Role: Select a custom role that contains the specific necessary permissions (listed below) or, for simpler deployments, the Network Contributor role.

        • Recommended Permissions for Custom Role:

          • Microsoft.Authorization/*/read
          • Microsoft.Compute/virtualMachines/read
          • Microsoft.Network/networkSecurityGroups/join/action
          • Microsoft.Network/networkInterfaces/*
          • Microsoft.Network/virtualNetworks/join/action
          • Microsoft.Network/publicIPAddresses/read
          • Microsoft.Network/publicIPAddresses/write
          • Microsoft.Network/publicIPAddresses/join/action
          • Microsoft.Authorization/*/read
          • Microsoft.Compute/virtualMachines/read
          • Microsoft.Network/routeTables/*
          • Microsoft.Network/networkInterfaces/*

      5. Members: Select Managed identity.

      6. Click + Select members and choose the managed identity you created mnha-role.

      7. Click Review + assign.

  9. Create a Network Interface

    Plan the network interface configuration on the vSRX Series firewalls on Azure. You can create interfaces before or after VM deployment:

    • Before VM Deployment: Pre-create interfaces and assign them during VM setup.
    • After VM Deployment: Attach additional interfaces to existing VMs as needed. This operation is supported only when the VM is powered off; adding interfaces while the VM is running is not possible.

    In the following procedure, we create new interfaces and later attach them to VMs and assign IP addresses.

    1. Navigate to Network interfaces in the Azure portal under the Networking section.
    2. Click on Create network interface.
    3. Enter the following details for the new network interface:
      • Name: Provide a unique name for your interface.
      • Region: Select the same region as your VNet, VMs, and IP addresses.
      • Virtual network: Choose the virtual network that you want your NIC to be associated with (mnha-vnet-zone for this example).
      • Subnet: Select the appropriate subnet. The subnets you created earlier will be available in the drop-down.
      • IP Version: Select IPv4 for this example.
      • Private IP address assignment: Select Static for this example.
    4. Attach the public IP address you created earlier, if required.
    5. Choose to create a new network security group or associate with an existing one.
    6. Review the settings and click Create to provision the new interface.
  10. Associate Interfaces with VM
    1. Navigate to your deployed vSRX VM and click Networking> Network Settings.
    2. Click on Attach network interface.
    3. In the Attach existing network interface pane, select the interface you want to add from the dropdown. (If you don't have one, select Create network interface first).
    4. Click OK.
  11. Assign IP addresses for Interfaces
    1. In the VM's left-side menu click Networking > Network Settings.
    2. Locate the attached network interface.
    3. Click the network interface name to open its details in IP configuration page. In the IP configurations section, you’ll find the assigned IP address (if any), and you can also configure IP address.
      1. Check or uncheck Enable IP forwarding. Always enable IP forwarding on the control link interface. Make sure that default routes are configured on both the trust and untrust sides. Enable IP forwarding on revenue interfaces if required by your traffic topology. When in doubt, enable it to ensure proper traffic flow.
      2. Click +Add to add new IP configuration and enter the following details:

        • Name: Enter a name of the IP configuration (Example ipconfig or ipconfig1.

        • IP version: Select IPv4 or IPv6

        • Type: Select Primary or Secondary

        • Private IP Address: Allocation: Select Static or Dynamic. Static IP remains fixed as long as the VM exists and dynamic IP may change after VM reboots or power cycles.

        • Private IP Address: IP Address: Enter the IP address

        • Associate public IP address: Check or uncheck as per requirement. Note that, by default, only private IP addresses can be assigned to interfaces. Public IP addresses must be explicitly configured in the VM’s network interface settings. In this example, you have already created three public IP addresses: vsrx-r0-ip, vsrx-secondary-public-ip, and vsrx-r0b-ip. The actual public IP values (203.0.113.33, 198.51.100.253, and 203.0.113.35) are allocated automatically by Azure when the public IP resource is created. You cannot manually specify this IP; Azure assigns it from its managed address pools..

        Click Save to save your settings.

      Use the same steps to add the secondary IP address and the other required IP addresses on the corresponding interfaces of both VMs. For this example, use IP address configuration as mentioned in the tables: Table 5 and Table 6.

      Note: Only the active node VM (vsrx‑r0) requires a secondary IP address. Do not configure a secondary IP on the standby VM (vsrx‑r0b).
    Table 5: Configuration of Interfaces and IP Addresses on vSRX VM Node 1 (vsrx-r0) (Active Node)
    Interfaces Subnet IP Address Public IP IP Forwarding Option Mapped to Interface(vSRX and Azure)

    vsrx-r0213_z1

    		 management-subnet

    10.10.0.4

    203.0.113.33

    		 NA fxp0 (eth0)
    vsrx-r0-g0 ICL-subnet

    10.10.1.4

    		 NA Enable ge-0/0/0 (eth1)
    vsrx-r0-g1 untrust-subnet

    10.10.2.4

    		 NA Enable ge-0/0/1 (eth2)
    vsrx-r0-g1 untrust-subnet

    10.10.2.5

    198.51.100.253

    		 Enable ge-0/0/1 (eth2)
    vsrx-r0-g2 trust-subnet

    10.10.3.4

    		 NA Enable ge-0/0/2 (eth3)
    vsrx-r0-g2 trust-subnet

    10.10.3.5

    		 NA Enable ge-0/0/2(eth3)
    Table 6: Configuration of Interfaces and IP Addresses on vSRX VM Node 2 (vsrx-r0b) (Backup Node)
    Interfaces Subnet IP Address Public IP IP Forwarding Option Mapped to Interface(vSRX and Azure)

    vsrx-r0b545_z1

    		 management-subnet

    10.10.0.5

    203.0.113.35

    		 Enable fxp0 (eth0)
    vsrx-r0b-g0 ICL-subnet

    10.10.1.5

    		 NA Enable ge-0/0/0 (eth1)
    vsrx-r0b-g1 untrust-subnet

    10.10.2.6

    		 NA Enable ge-0/0/1 (eth2)
    vsrx-r0b-g2 trust-subnet

    10.10.3.6

    		 NA Enable ge-0/0/2(eth3)

    See Interface Mapping for vSRX Virtual Firewall on Microsoft Azure for vSRX Virtual Firewall and Microsoft Azure interface names.

    Click Settings > Networking to display interfaces, subnet, and IP configurations of your VM.

  12. Associate Interfaces with Network Security Group (NSG)
    Network security groups can be applied at subnet level (affects all NICs in that subnet) or interface level. NSGs control traffic by IP, port, and protocol; associating NSGs at the interfaces level applies rules specific to that VM’s interface. The NSG must be in the same region and resource group as the network interface.
    1. In the search bar at the top of the portal, type and select Network interfaces
    2. Select the name of the network interface you want to configure
    3. In the left-side menu, under Settings, select Network security group.
    4. Select the desired NSG from the dropdown menu (or select None to dissociate an existing one). Select the following NSGs:
      • vsrx-r0 for virtual machine vsrx-r0b
      • vsrx-r0b-nsg for virtual machine vsrx-r0b
    5. Select Save to apply the changes
  13. Create Interface Tags

    Resource tags in Azure are metadata elements consisting of a name and a value pair that you apply to your Azure resources, resource groups, and subscriptions.

    To create tags, on your vSRX VM page, select Tags from left-navigation bar.

    In this example, you create tags for both VMs to identify the trust and untrust interfaces on two vSRX Virtual Firewall instances. The following tables (Table 7 and Table 8show sample tags used in this example.

    Table 7: Interface Tags on vSRXVM-1 (vsrx-r0)

    Tag Name

    Value

    local_trust_interface

    vsrx-r0-g2

    local_untrust_interface

    vsrx-r0-g1

    peer_trust_interface

    vsrx-r0b-g2

    peer_untrust_interface

    vsrx-r0b-g1
    Table 8: Interface Tags on vSRXVM-2 (vsrx-r0b)

    Tag Name

    Value

    local_trust_interface

    vsrx-r0b-g2

    local_untrust_interface

    vsrx-r0b-g1

    peer_trust_interface

    vsrx-r0-g2

    peer_untrust_interface

    vsrx-r0-g1

    Note that the tag values shown in the table represent the network interface names. You must use the same tag values in your setup. In MNHA setup on Azure, these tags are used to map each NIC to the corresponding vSRX interface. This mapping must match the real interface names so that the HA process can correctly shift secondary IPs between the appropriate trust and untrust interfaces during failover.

Once you complete all configurations, Use Azure Portal serial console or remote SSH to log in to the vSRX Virtual Firewall VMs.

Now that all configurations required on Azure portal are complete, let’s start configuration on vSRX Virtual Firewall using CLI.

Note:

Ensure you use the latest version of vSRX software image (23.4R1 or later). You can directly upgrade the Junos OS for vSRX Virtual Firewall software using the CLI. Upgrading or downgrading Junos OS can take several hours, depending on the size and configuration of the network. You download the desired Junos OS Release for vSRX Virtual Firewall.tgz file from the Juniper Networks website. See Migration, Upgrade, and Downgrade Instructions.

Configure vSRX Virtual Firewalls

The Junos IKE package is recommended on your SRX Series Firewalls for Multinode High Availability configuration. This package is available as a default package or as an optional package on SRX Series Firewalls. See Support for Junos IKE Package for details.

If the package is not installed by default on your SRX Series firewall, use the following command to install it. You require this step for ICL encryption.

  1. Configure interfaces for ICL, internal and external traffic.
    • Node 1
    • Node 2
    Note:

    The secondary IP is owned only by the active node and becomes active on the backup node only during failover.

    Note:

    For fxp0 interface, management IP address is assigned by Azure and the management IP address is bound to fxp0.0 (unit 0).

  2. Configure security zones, assign interfaces to the zones, and specify the allowed system services for the security zones.
    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.

    • Node 1
    • Node 2
  3. Configure local node and peer node details.
    • Node 1
    • Node 2
  4. Configure SRG1 with deployment type as cloud, assign an ID, and set preemption and activeness priority.
    • Node 1
    • Node 2
  5. Configure Azure deployment-related options.
    • Node 1
    • Node 2
  6. 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

    • Node 2

  7. Configure routing instance.
    • Node 1
    • Node 2
  8. Configure policy options.
    • Node 1
    • Node 2
  9. Encrypt the ICL
    • Node 1
    • Node 2

    See Example: Configure Multinode High Availability in a Layer 3 Network for details.

Verification

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

Table 9: 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 security cloud high- availability information

Display status about MNHA deployment on public cloud (AWS or Azure).

Check Multinode High Availability Details

Purpose

View and verify the details of the Multinode High Availability setup configured on your vSRX Virtual Firewall instance.

Action

From operational mode, run the following command on both the devices.

On Node 1 (Active Node)

On Node 2 (Backup Node)

Meaning

Verify these details from the command output:

  • Local node and peer node details such as IP address and ID.
  • The field Deployment Type: CLOUD indicates that configuration is for the cloud deployment.
  • The field Services Redundancy Group: 1 indicates the status of the SRG1 (ACTIVE or BACKUP) on that node.

Check Multinode High Availability Information Details

Purpose

Check the status of Multinode High Availability deployment in Azure Cloud.

Action

From operational mode, run the following command:

Meaning

Verify these details from the command output:

  • Cloud Type: Azure indicates the deployment is for Azure.
  • Cloud Service Type: Secondary IP indicates that the Azure deployment uses the secondary IP to control traffic.
  • Cloud Service Status: Bind to Peer Node indicates the binding of the secondary IP address to the peer node meaning the current node is backup node.

Basic Troubleshooting Checklist

  1. Check secondary IP for untrust interface and trust interface are on the same vsrx3.0 VM instance.
  2. Check the four tag values to match the interface names.
  3. Check inbound rule is correct to permit the traffic.
  4. Check IP forwarding is enabled in Azure portal.
  5. Check Azure portal route and vSRX CLI route are synchronized.
  6. Check untrust interface of the active node to see if the floating IP addresses attached to it in Azure portal.

Set Commands on all Devices

vSRX Virtual Firewall (Node 1)

vSRX Virtual Firewall (Node 2)

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 (Node 1)

vSRX Virtual Firewall (Node 2)

See Also

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
24.4R1
Starting in Junos OS Release 24.4R1, we support IPsec VPN for active/backup Multinode High Availability in Azure Cloud deployments.
23.4R1
Starting in Junos OS Release 23.4R1, we support MNHA in Microsoft Azure Cloud platform.