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).
|
<Gateway>
<ConnectionsToLocalNetwork>
<LocalNetworkSiteRef
name="Network_A"><Connection type="IPsec" /></LocalNetworkSiteRef>
<LocalNetworkSiteRef
name="Network_B"><Connection type="IPsec" /></LocalNetworkSiteRef>
</ConnectionsToLocalNetwork>
</Gateway>
|
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.