Microsoft Azure Multi-Site VPN

Recently I had the opportunity to assist an organisation which has physical offices located in Adelaide, Melbourne, Brisbane and Sydney replacing their expensive MPLS network with a Multi-site VPN to Azure.

This worked well for the customer as they no longer have any server infrastructure on premises. Each branch office requires access to the virtual infrastructure hosted within their Azure VNET.

The solution provides each office connectivity to the VMs and other services hosted within Azure, as well as a means of inter-site connectivity to PC’s and other services located within the branch offices on the rare occasion where this may still be required.

Step 1. – Document Internal Network

In preparation for implementing the Multi-site VPN, review and document the current IP address ranges in-use and Internet gateway addresses at each branch site.

Internal Network Ranges and Gateway Addresses

 

Step 2. Define the Internal Network Ranges within Azure

Within Azure Networks, select Local Networks

Next you need to define the internal network ranges and gateway addresses as obtained in step 1.

Step 3. – Define the Azure Gateway Subnet

The Multi-site VPN requires a “Gateway Subnet”.

Select Networks, VNET, Configure and click “add subnet” to add your gateway subnet to the VNET configuration.

A whole subnet is required, in this case I’ve chosen 172.17.10.0/24 and have included it within my VNET as follows:

Step 4. – Create a Dynamic Routing Gateway

A “Dynamic Routing” Gateway is required for Multi-Site VPN. If you already have a Point-to-site VPN configured to a single site and are using a “Static Routing” Gateway, you will need to delete the gateway and start a fresh. If you need to delete your old static gateway, Microsoft have instructions at http://msdn.microsoft.com/en-us/library/azure/dn221918.aspx

Select New, Dynamic Gateway

The Gateway will start building, this will take approximately 15 minutes to complete.

Once completed the dashboard will display the gateway between Azure and the primary site (as listed in local networks)

Step 5. Export Network Configuration and Populate for Multi-Site Gateway

In order to configure VPN tunnels to multiple on-premise gateways, we need to export the NetworkConfig.xml and define the <ConnectionsToLocalNetwork>.

Open the exported NetworkConfig.xml and locate the <Gateway> node / element and add an additional localNetworkSiteRef name for each site as illustrated below.

<Gateway>
<ConnectionsToLocalNetwork>
<LocalNetworkSiteRef name=”Adelaide”><Connection type=”IPsec”/></LocalNetworkSiteRef>
<LocalNetworkSiteRef name=”Sydney”><Connection type=”IPsec” /></LocalNetworkSiteRef>
<LocalNetworkSiteRef name=”Brisbane”><Connection type=”IPsec”/></LocalNetworkSiteRef>
<LocalNetworkSiteRefname=”Melbourne”><Connectiontype=”IPsec”/></LocalNetworkSiteRef>
 </ConnectionsToLocalNetwork>
</Gateway>

Step 6. Import the updated Network Configuration

When you import the NetworkConfig.xml file with the changes, the new tunnels will be added using the dynamic gateway that you created earlier.

The dashboard should now display the status of each VPN tunnel

Step 7. – Obtain the IPsec/IKE pre-shared Key for each tunnel

Now we are ready to download the IPsec/IKE pre-shared keys for the VPN tunnels. Once your new tunnels have been added, use the PowerShell cmdlet “Get-AzureVNetGatewayKey” to get the IPsec/IKE pre-shared keys for each tunnel.

Using the Azure PowerShell execute the following cmdlet for each LocalNetworkSiteName (as defined in step 2)

Get-AzureVNetGatewayKey –VNetName “VNET” –LocalNetworkSiteName “Adelaide”|fl

The output should look something like this:

Value : P1nwHJfbAL4ZvWWySewt9yDcwf0gAD76
OperationDescription : Get-AzureVNetGatewayKey
OperationId : 58732f31-170f-ae52-ba31-bc5f173c1972
OperationStatus : Succeeded

The highlighted value in bold is the IPsec/IKE pre-shared key. This will be required when configuring the VPN tunnel for the router (in this case for the Adelaide site, remember to repeat for each LocalNetworkSiteName)

Step 8. – Configure Routers for IPSec Tunnel

Create VPN Device Scripts for each local network site and populate with respective IPsec/IKE pre-shared key. In my case each site had a Cisco 880 series ISR router. Microsoft have templates for a variety of manufacturers which can be downloaded from http://msdn.microsoft.com/en-us/library/azure/dn133800.aspx#BKMK_ISRDynamic

Open the template using Notepad. Search and replace all <text> strings with the values that pertain to your environment. Be sure to include < and >. When a name is specified, also remember that the name you select should be unique.

A table containing the template text fields with an explanation of the parameter values can be found at http://msdn.microsoft.com/en-us/library/azure/30e508e4-8b3f-4b09-ba0e-0ab251fc3d5c#BKMK_AboutConfigurationTemplates

Once a template has been created for each of your sites, pass the scripts onto your network administrator, in the case of the Cisco 880 series routers, the relevant parts of the script were integrated into the Cisco IOS running configuration by our ISP.

Step 9. – Check the multi-site tunnel status for connectivity

Once the router configurations have been updated, the ConnectivityState should change from “Initializing” to “Connected”.

To verify the connectivity state from the Azure PowerShell execute:

 Get-AzureVnetConnection -VNetName VNET

 Each site will be listed. Look for the ConnectivityState, LastEventMessage and LocalNetworkSiteName

ConnectivityState : Connected
EgressBytesTransferred : 861264503
IngressBytesTransferred : 1054775403
LastConnectionEstablished : 4/06/2014 12:04:27 AM
LastEventID : 23401
LastEventMessage : The connectivity state for the local network site ‘Adelaide’ changed from Not Connected to Connected.
LastEventTimeStamp : 4/06/2014 12:04:27 AM
LocalNetworkSiteName : Adelaide
OperationDescription : Get-AzureVNetConnection
OperationStatus : Succeeded

ConnectivityState : Connected
EgressBytesTransferred : 118232342
IngressBytesTransferred : 52362858
LastConnectionEstablished : 5/06/2014 2:49:32 PM
LastEventID : 23401
LastEventMessage : The connectivity state for the local network site ‘Brisbane’ changed from Not Connected to Connected.
LastEventTimeStamp : 5/06/2014 2:49:32 PM
LocalNetworkSiteName : Brisbane
OperationDescription : Get-AzureVNetConnection
OperationStatus : Succeeded

ConnectivityState : Connected
EgressBytesTransferred : 138401240
IngressBytesTransferred : 122273966
LastConnectionEstablished : 6/06/2014 10:54:34 AM
LastEventID : 23401
LastEventMessage : The connectivity state for the local network site ‘Melbourne’ changed from Not Connected to Connected.
LastEventTimeStamp : 6/06/2014 10:54:34 AM
LocalNetworkSiteName : Melbourne
OperationDescription : Get-AzureVNetConnection
OperationStatus : Succeeded

ConnectivityState : Connected
EgressBytesTransferred : 225672988
IngressBytesTransferred : 65533667
LastConnectionEstablished : 5/06/2014 3:19:32 PM
LastEventID : 23401
LastEventMessage : The connectivity state for the local network site ‘Sydney’ changed from Not Connected to Connected.
LastEventTimeStamp : 5/06/2014 3:19:32 PM
LocalNetworkSiteName : Sydney
OperationDescription : Get-AzureVNetConnection
OperationStatus : Succeeded

The connectivity status can also be viewed from within the Azure Virtual network dashboard as follows:

Conclusion

If you are looking for an alternative to a MPLS network and require access to your Azure VNET from all your branch offices the Azure multi-site VPN may be a good fit for your organization. In the aforementioned case, the performance of connectivity to the Azure VNET is desired over the performance of connectivity from one branch office location to another (e.g. connectivity between Adelaide and Brisbane). With the Azure VNET being at the center, this fulfils the requirements of this organization at a substantially lower cost than their legacy MPLS network.