Pages

Friday, May 29, 2020

Planning and setting up a Site-to-Site VPN connection between an on-premise network and Azure

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:

image 

Azure Resource Preparation

image

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.

image 

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

image 

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.

image 

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).

image 

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).

image 

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).

image 

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.

image 

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.

image

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.

image

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:

image

Add the subnet you’ll be using into the VNet configuration:

image

image

Leave DDoS protection on and the firewall either as disabled or enabled if one is configured and to be used:

image

Add a designed tag for the resources if ones have been planned for the resource:

image

Proceed to create the VNet:

image

Once the Virtual Network has been created, proceed to navigate into the resource, then to Subnets and then click on Gateway subnet:

image

Create the Gateway Subnet with the pre-planned subnet:

image

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:

image

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:

image

Create the virtual network gateway with the configuration previously planned:

image

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.

image

You’ll notice that the public IP address gets created quickly but there is no IP address assigned:

image

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.

image

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.

image

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:

image

Create the local network gateway with the configuration previously planned:

image

The deployment, unlike the virtual network gateway, shouldn’t take too long to complete:

image

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:

image

Create the virtual network gateway connection to the local network gateway with the configuration previously planned:

image

The creation of the connection doesn’t take long and the initial connection Status will be labeled as Unknown:

image

Assuming there are no problems with the configuration then the Status will be change to Connected:

image

image

**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.

image

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.

image

No comments: