One of the tasks most administrators will have to perform when adopting Microsoft’s Azure as their cloud platform is setting up a site-to-site VPN connection between their on-premise infrastructure to an Azure region where they will host their IaaS, PaaS or SaaS services. There are plenty of blog posts, YouTube videos and Microsoft documentation demonstrating the configuration but I find that most of the environments I come across tend to show that not a thought has been put into something as simple as, yet I feel is very important, naming conventions. With that in mind, this post serves to place a bit more emphasis on preparing the resources that will be required to set up the VPN connection prior to proceeding with the configuration.
The following is a diagram of what the topology would look like along with the resources we will be creating:
Azure Resource Preparation
It is possible to create the Azure resources required for a site-to-site VPN connection during the configuration but making decision on the fly is prone to mistakes that you may make so it is always best to plan and design the resources before commencing with the configuration.
As a start, if this has not been done, spend some time to determine how resources should be named. Maintaining a standard naming convention will save you a lot of grief in the future and make it much easier to identify resources and/or sort them into lists for exercises such as billing. Microsoft has an official document that provides recommendations for naming and tagging here:
Recommended naming and tagging conventions
https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/naming-and-tagging
**Note that I don’t proclaim that my naming conventions are the best but I hope a demonstration would provide an example for such an exercise.
Resource Groups
Every resource in Azure needs to be placed into a resource group so the first step is to determine where the resources that will be required for the site-to-site VPN will be created. It is possible to move a resource to another resource group or even another subscription but putting a bit of thought in how you would like to organize your resources and maintaining a standard will ensure tidiness. For the purpose of this example, all of the resources created for the site-to-site VPN will be placed into a single resource group containing networking items as the environment isn’t very large. It is possible to break up the components into dedicated groups (e.g. Public IPs, Virtual Network Gateways, Virtual Networks).
Resource group: rg-prod-network
Subnets
Subnets are networks you define in Virtual Networks (VNet) and it is not something you create before the creation of the Virtual Network but it is best to pre-plan the name and subnet prior to the configuration.
Subnet
|
Parameter |
Configuration |
|
Name |
snet-prod-svr-10.248.1.0-24 |
|
Address range (CIDR block) |
10.248.1.0/24 |
The naming convention chosen is to use the snet- prefix followed by the environment (in this case production) and then the Azure region (East US).
Gateway Subnet
The gateway subnet contains the IP addresses that the virtual network gateway virtual machines and services use. When you create your virtual network gateway, gateway VMs are deployed to the gateway subnet and configured with the required VPN gateway settings. This subnet is reserved solely for the virtual network gateway so do not deploy anything else into it. The subnet size can be as small as /29 but it is recommended to be /27 or larger as this would accommodate most configurations and not limit additional virtual network gateway connections in the future.
Gateway Subnet
|
Parameter |
Configuration |
|
Name |
GatewaySubnet |
|
Address range (CIDR block) |
10.248.255.0/27 |
The Gateway Subnet is specific to the VNet and you are not allowed to provide a custom name so the default will be used.
Virtual Networks
The Azure Virtual Network (also known as VNet) is a fundamental building block for the network in Azure. These objects define the IP scheme of the resources located within it and interacts with other VNets and/or networks through a Virtual network Gateway. Note that moving a virtual machine between VNets isn’t very straight forward and trying to redesign VNets after a deployment can be a laborious task so spend some time to think out the naming convention and IP addressing before creating and using them. For the purpose of this example, we’ll have one VNet that contains all of the production servers.
Virtual network
|
Parameter |
Configuration |
|
Name |
vnet-prod-eastus |
|
Location |
East US |
|
Address Space |
10.248.0.0/16 |
|
Subnets |
Hosts Subnet: 10.248.1.0/24 (247 addresses) GatewaySubnet: 10.248.255.0/27 (26 IP addresses) |
|
DNS servers |
Domain Controllers |
The naming convention chosen is to use the vnet- prefix followed by the environment (in this case production) and then the Azure region (East US).
Public IP Address
Public IP addresses are fairly self-explanatory as these objects represent the public IP addresses available that can be assigned to resources such as a virtual machine, Virtual Network Gateway or application. The public IP address we’ll need for the site-to-site VPN is a public IP for the VPN Gateway.
Public IP Address:
|
Parameter |
Configuration |
|
Name |
pip-vgw-EastUS |
|
SKU |
Basic |
|
IP address assignment |
Dynamic |
The naming convention chosen is to use the pip- prefix followed by the Virtual Network Gateway prefix vgw- and then the Azure region (East US).
Virtual Network Gateway
The Virtual Network Gateway is the device that establishes the connection to the VPN device at your on-premise datacenter or office. Note that a single Virtual Network Gateway can establish multiple site-to-site VPN connections so it is not advisable to name it to include where it is connecting to.
Virtual Network Gateway
|
Parameter |
Configuration |
|
Name |
vgw-EastUS |
|
VPN type |
Route-based |
|
SKU |
VpnGw1 |
|
Gateway type |
VPN |
The naming convention chosen is to use the vgw- prefix followed by the Azure region (East US).
Local Network Gateway
The Local Network Gateway represents the device at your on-premise datacenter or office that establishes the connection to the Virtual Network Gateway at the Azure region. You will need to work with the network engineer to determine what static IP address this device will use to accept the site-to-site VPN connection as well as the address space (subnets) that reside in the network so the VNet will know what traffic to route through this VPN.
Local Network Gateway
|
Parameter |
Configuration |
|
Name |
lgw-BDA-EastUS |
|
IP Address |
162.x.213.x |
|
Address Space |
10.247.0.0/16, 192.168.113.0/24 |
The naming convention chosen is to use the lgw- prefix followed by the location of the gateway (in this case BDA represents Bermuda) and finally which Azure region (East US) it is connecting to.
Connection (Site-to-Site)
The connection represents the site-to-site connection between the Azure Virtual Network Gateway to the Local Network Gateway.
Connection between Azure Virtual Network Gateway to Local Network Gateway
|
Parameter |
Configuration |
|
Connection Type |
Site-to-Site |
|
Name |
cn-lgw-BDA-EastUS-to-vgw-EastUS |
|
Shared key (PSK) |
<create a unique string> |
|
Protocol |
IKEv2 |
|
Location |
East US |
The naming convention chosen is to use the cn- prefix followed by the local network gateway object name, then the -to- to indicate that it is connected to the virtual network gateway in Azure.
On-Premise Preparation
The network engineer configuring the VPN appliance on-premise will likely ask you for the:
- Public IP address of the virtual network gateway in Azure
- Shared key
- Address space in Azure (if they were not involved with the subnet planning)
- VPN type
You wouldn’t be able to complete the configuration without asking and obtaining the following information for the on-premise appliance:
- Public IP address of the local network gateway located on-premise
What I typically do is agree on a shared key, address space and VPN type with the network engineer, proceed to create the virtual network gateway, supply the information to the engineer, then ask for them to provide me with the public IP address of the local network gateway.
Deployment
Resource Group
Begin by creating the resource group or groups that these resources will reside in. For the purpose of this example, we will create one resource group named rg-prod-network for all of the resources.
Virtual Networks
Create the virtual network (VNet) that will be used to host the Virtual Network Gateway and host the resources such as virtual machines.
Remove the default IPv4 address space of 10.0.0.0/16 and default subnet of 10.0.0.0/24 if those are not the address space and subnet you will be using:
Add the subnet you’ll be using into the VNet configuration:
Leave DDoS protection on and the firewall either as disabled or enabled if one is configured and to be used:
Add a designed tag for the resources if ones have been planned for the resource:
Proceed to create the VNet:
Once the Virtual Network has been created, proceed to navigate into the resource, then to Subnets and then click on Gateway subnet:
Create the Gateway Subnet with the pre-planned subnet:
For the purpose of this example, we will only configure the Address range (CIDR block) and leave the rest as default/unconfigured.
You should now see the two subnets configured for the VNet:
Public IP Address
It may seem logical to create a public IP address before creating the virtual network gateway but what I’ve noticed in the past (not sure if this has changed) is you cannot assign a static public IP address to the gateway and creating a dynamic public IP address would not allow you to select it during the virtual network gateway configuration (probably because a dynamic public IP address doesn’t actually have an IP assigned to it until it is associated and used) so this is the one component that I create during the configuration of the virtual network gateway. Having the name of the public IP address for the virtual network gateway planned should still be done.
Virtual Network Gateway
Proceed to create the virtual network gateway by navigating to the virtual network gateways resource and click Add:
Create the virtual network gateway with the configuration previously planned:
The creation of the gateway takes a bit of time (upwards to 20 minutes or more) so do not expect it to be within a few minutes.
You’ll notice that the public IP address gets created quickly but there is no IP address assigned:
The reason is because this public IP address is configured for the virtual network gateway and the deployment hasn’t completed yet. Note how the Assignment configuration is set to Dynamic as well.
Once the virtual network gateway deployment has completed, obtain the public IP address that has been assigned to it, proceed to reach out to the network engineer configuring the local network gateway and provide him with the public information.
Also ensure that you have obtained the Public IP address of the local network gateway located on-premise.
Local Network Gateway
While waiting for the virtual network gateway deployment to complete, you can continue with creating the local network gateway by navigating to the local network gateways resource and click Add:
Create the local network gateway with the configuration previously planned:
The deployment, unlike the virtual network gateway, shouldn’t take too long to complete:
Connection (Site-to-Site)
Once you have confirmed with the network engineer that the on-premise VPN appliance is configured, you can proceed to connect the Azure Virtual Network Gateway to the Local Network Gateway. Proceed to navigate to the virtual network gateway object, connections and then click on the Add button:
Create the virtual network gateway connection to the local network gateway with the configuration previously planned:
The creation of the connection doesn’t take long and the initial connection Status will be labeled as Unknown:
Assuming there are no problems with the configuration then the Status will be change to Connected:
**Note that one of the things I’ve noticed in the past is that if you do not define an address space for the local gateway network then the connection status would remain unknown indefinitely so ensure that it has been configured.
You can proceed to configure additional site-to-site connections to other gateways if there are other datacenters or offices that need to connect into Azure.
