It is possible in Microsoft Azure to configure your vNet to terminate multiple IPsec VPN connections to enable you to create mesh-like connectivity between your on premise sites and Azure.
In my example I have two on premise networks Network_A and Network_B, it is very important if you have two networks sharing a vNet gateway that they do not have overlapping address spaces.
Network_A 10.25.1.0/16 (10.25.0.1 – 10.25.255.254)
Network_B 10.22.1.0/16 (10.22.0.1 – 10.22.255.254)
The overlaps must also include the Gateway subnet, as this is a network in itself.
One thing to note if you are provisioning your vNet for the first time, is that for a multi-site VPN to be possible your Azure Gateway must be configured to use Dynamic Routing. If you are like me and you are re-configuring an existing gateway you can delete it and recreate it with a Dynamic Routing gateway. You will need to re-run your VPN script on your firewall though, as the Azure Gateway will be assigned a new IP.
Dynamic Routing is also known as Route-based in the context of networking. It is important to ensure your VPN devices support route-based routing. The following link can be referenced to check this;
Before you start your configuration, confirm your VPN devices at each of the sites can support route-based routing. Surprisingly devices such as Cisco ASA’s and Palo Alto PAN-OS devices are not compatible- they only support policy-based VPNs.
Confirm you want to create a new Azure Gateway. It takes anywhere between 10-30 minutes to provision a new Azure Gateway so be patient.
Before you export your network configuration to XML you must first define the additional local networks that are being used at your other on premise sites.
Enter a descriptive name for the new network, if you forget to do this before you export the network configuration to XML you will be an XML validation error when you do the re-import.
Define the Address Space being used within the site. It is best to ensure your Address Spaces to not overlap, this is an easy mistake to make if you enter a "catch-all" mask to encapsulate the entire Class A, B or C subnet. A work around for overlaps if you do use general network ranges is to manually enter in the exact network ranges used in each of the on premise networks.
At this point you should have all the on premise networks defined under the Virtual Network.
The next step is to export the network configuration to XML. This can be done using the GUI.
You then have to edit the XML file to include your additional Local Networks that have been defined within your vNet.
If you export the network configuration before you define the Local Networks they will not be defined as <LocalNetworkSites> and you will receive a general XML validation error.
In my example script below, I have two Local Networks "Network_A" and "Network_B". The XML should be set like it is highlighted below (the variable is the local network name).
<LocalNetworkSiteRef name="Network_A"><Connection type="IPsec" /></LocalNetworkSiteRef>
<LocalNetworkSiteRef name="Network_B"><Connection type="IPsec" /></LocalNetworkSiteRef>
Save the XML file and return to the Azure Portal. Use the New wizard and select Network Services, Virtual Network and Import Configuration.
Browse for the edited XML file and click Next. The XML is validated before the import can complete, if Azure does detect a syntax error in the code it will state exactly what line is causing the problem.
Once the import is completed, the next step is to import the configuration script automatically generated by Azure. This script should be imported into each of VPN devices. It is important to read and understand the configuration script, as there are some assumptions made by Azure.
For example, the default configuration script creates an Internet Key Exchange (IKE) policy with a number of 10, if you have used this for another VPN tunnel you could cause a conflict on your firewall which could cause an outage.