Azure Redundant Failover dual link VPN


A client was dealing with network infrastructure problem; they were experiencing communication lost between Azure and on-prem networks. This problem was generated due to ISP internet link failures.  This condition causes downtime problems at its daily operation. Besides, they had 03 internet links with different ISP, there were no automatic failover routines, neither their firewall or Azure Classic Virtual Network.


Sometimes, the internet link became down. This problems, had stopped the normal daily routine, which cause time and money loss. Every time the link was down, the Network Analyst had to change the firewall configurations, to point a new interface port to Azure Virtual Gateway.



It is necessary to provide an automatic failover solution to prevent link downtime, assure the VPN availability. The implementation must use the new ARM Azure Portal, and must accept future multi-site communication with all other client offices in the country.



The team was leaded by an Azure Solution Architect and a FortiGate-300C Firewall Specialist.


The Design

The design was to create a new ARM Network Infrastructure with an Azure Routing based Virtual Gateway, with multi-site support, pointing to 02 different internet connection at client on-prem network. Creating 02 VPN tunnels between Azure and Client headquarter.


01) Resource Group

The resource group was created to both, create a logical layer between other resources, and grant more control access permission over the new Azure Virtual Network. There was no mystery to create Azure Resources Groups.


02) Azure Virtual Network (AVN)

It is necessary some considerations about Azure Virtual Network. The first of all is about the Address Space, it is very important to avoid network overlaps between AVN subnet addresses and on-prem subnet address. If the addresses were overlapped, the communication could experience unpredictable results.

Other important thing to pay attention in AVN, is about subnet design. First because the Portal only accept 01 subnet specification at creation time, you must edit the subnets after the creation, to add all your VNets and the GatewaySubnet. The GatewaySubnet must use that name! (Azure requirement!)

Additional attention is required with the number of hosts left at each subnet created, because if you plan to use point-to-site or others site-to-site VPN, it must have enough host address available.


03 – Local Network Gateway (LNG)

Were created 02 LNG with the same local address subnets. But each of them points to a public-facing IP at on-prem network.

It sounds a little bit crazy 02 LNG with the same local addresses, but due the essence of routing tables, when the packet could not be delivered to one LNG the route table redirect it to the next available gateway. It works!


04 – Azure Connection

There were 02 connections created for each of the LNG, both with with the same passphrase.


05 – Virtual Network gateway (VNG)

The Virtual Network Gateway, must be bound with the Azure Virtual Network, also must be assigned a public IP Address to them, and it must be connected with the two connections created above.


06 – Firewall

The firewall configuration passed through a lot of configuration: static routing, policy routing and policy grouping. This is very common routine to the firewall guys. But the important thing about the solution was the Equal-Cost Multi-Path routing (ECMP), wich provides the “best path” to packets between the networks.

ECMP was implemented between the 02 VPN interfaces in firewall. The main VPN was created with the lowest metric, and the second VPN with a higher one. In addition, to ensure ECMP availability, was enabled an interface Health Status Monitor, which check a destination IP in Azure to assure it is healthy,



The solution was designed and implemented in 04 hours.



The communication between Azure and on-prem subnets are stable.  Both of links was shut down, in different times, and the communication remain normal.  All the packets were delivered due to ECMP and no issue was detected in client application.  The next step is migrating all Virtual Machines to this Azure Virtual Network.


Leave a Reply

Your email address will not be published. Required fields are marked *