In a previous article, I discussed how the Azure VPN Gateway could be utilized for providing remote workers with connectivity to Azure Virtual Networks and resources over an Internet connection through the creation of a Point-to-Site (P2S) VPN connection. However, an Azure VPN gateway also provides the option to use an encrypted link (IPSec) between the Azure Virtual Networks and your on-premises (or other) networks to achieve a hybrid or cross-premises architecture. This is known as a Site-to-Site (S2S) VPN connection.

To implement the S2S VPN connection between the Azure VNets and the On-premises network over the Internet, the following devices and services are needed:

Virtual network gateway

The VPN gateway is a specific type of virtual network gateway that is deployed into a specific subnet called a gateway subnet and is configured with a public IP address. The VPN gateway sends encrypted (IPSec) traffic between an Azure virtual network and other types of networks over the public Internet. In Azure, we can create multiple connections that can coexist on the same gateway and these will share the available gateway bandwidth. However, each virtual network can only have one VPN gateway.

Azure also provides us with multiple configuration options for high-availability solutions so that we can avoid introducing a single-point failure into our architecture. Every Azure VPN gateway consists of two instances in an active-standby configuration, by default.

The maximum amount of throughput, connections, and supported features vary depending on the VPN Gateway SKU that is implemented and each type is subject to different pricing. These are important factors that should be considered when planning a site-to-site VPN connection deployment to determine if it will meet the needs of the organization. Due to the limitations on features and the max number of S2S connections allowed, the Virtual WAN may be a more feasible solution for some organizations.

Local network gateway

The local network gateway (LNG) is an Azure service that represents the gateway device that is configured on your on-premises location. On this device, we specify the Public IP address of the on-premises VPN device to which you will create a connection in addition to any IP address ranges that are on your on-premises network. It is important to note that any changes to the IP address prefixes that you want to be routed to your on-premises network must manually be updated on the LNG.

Connection

A Site-to-Site VPN connection is the connection type configured between your virtual network gateway and your VPN device. A Shared Key (PSK) is configured on this connection that must match the value you configure in your on-premises VPN device configuration to establish connectivity between both ends.

Gateway subnet

A VPN Gateway must be deployed into a dedicated subnet known as the Gateway subnet. This subnet can be added to an existing virtual network or it can be created during the deployment of the VPN gateway device itself. Microsoft recommends that a /27 or /28 subnet is used for this network. Please note that it is a requirement that this subnet is named “GatewaySubnet” for it to work properly with the VPN Gateway and for establishing the connection between the networks.

On-premises gateway device

Microsoft says that “Site-to-Site connections to an on-premises network require a VPN device.” This Microsoft page provides information about validated, tested, and compatible VPN device types that can be used on-premises for use with an Azure S2S VPN connection. “It’s always best to check with your device manufacturer for the latest configuration information.” This device must be configured with a public IP address and its configuration must include and match the Shared Key that we configured on the Site-to-Site connection between the Virtual Network Gateway and the Local Network Gateway.

Lab Demonstration:

In this lab demonstration, I implemented a Site-to-Site (S2S) VPN connection between an on-premises network and an Azure VNet. Note that I did not have access to an actual on-premises network device with a public IP address for use in this demonstration, but I provide the Azure side of this configuration. I was able to accomplish this by completing the following steps:

1. Create a virtual network
2. Create a VPN Gateway
3. Create a Local Network Gateway
4. Create a Connection
5. Verify the Connection
6. Connect to a virtual machine

Step 1: Create a Virtual Network

In this first step, we begin by configuring a virtual network on our Azure tenant. An existing virtual network can be used if one is already configured.

Here we provide or create the resource group that will be used for this VNet. We give the VNet a name and provide the Region where it should be deployed to.

Next, we configure the IPv4 address space for this virtual network and the subnets that we will use on this network. Here I defined a network address space of 10.1.0.0/16 and from it, I carved out one FrontEnd subnet address range of 10.1.0.0/24.

Although the options are available, I did not enable any of these security features for this network.

Step 2: Create a VPN Gateway

In this step, we deploy an Azure Virtual Network Gateway device into a dedicated GatewaySubnet and it will be used for sending encrypted (IPSec) traffic between an Azure virtual network and other types of networks over the public Internet.

Here I gave the VPN Gateway a name and specified the Region where it should be deployed in. I specified a Gateway type of VPN because ExpressRoute is a different type of VPN gateway that is used for ExpressRoute connections. The VPN type that you choose depends on the connection topology that you want to create, but most will be a Route-based VPN type. Next, I selected a VPN SKU that I wanted to deploy and I went with a lower-cost option of VpnGw2 because this is only for a lab demonstration. I specified that this VPN gateway was to be associated with a virtual network named “nisha-VNet1”. In doing so, Azure will automatically create System Routes and assign the routes to each subnet in the virtual network to accept inbound traffic coming from the VPN Gateway based on what gets configured on the Local network gateway (or any prefixes that are advertised from on-premises via BGP, if used).

The gateway subnet was auto-populated for me on this screen. However, I did modify the subnet mask to use a /27 per Microsoft’s recommendation. I created a Standard public Static IP Address Type and gave it a name. I did not provision any redundancy high-availability options in this configuration nor did I enable BGP.

Step 3: Create a Local Network Gateway (LNG)

In this step, I deployed a Local Network Gateway (LNG) which is the device that represents the on-premises gateway device. I deployed it to the same Region as the VPN Gateway and I named this site “Site1”. You can name the site whatever you would like to name it, but it should be a name that helps you to identify which site it is connected to on the opposite end on-premises. The IP address configured here is the Public IP address of our local gateway. Finally, in the Address Spaces section, I defined the IP address prefixes that I want to be routed to the on-premises location, Site1.

Step 4: Create a Connection

In the “Add connection step”, I gave the connection a name that helps to identify the local and remote ends of the connection, Nisha-VNet1 to Site1. I specified a Connection type of Site-to-site (IPsec). Other available Connection type options in this list are VNet-to-VNet or ExpressRoute.

Next, the Virtual Network Gateway was pre-selected for me since I configured it from that device, but I had to provide the name of the Local Network Gateway where this connection should terminate (Site 1). I configured a Shared key of abc123 and enabled the IKEv2 protocol for encryption. The Shared Key must be configured on the remote end device (on-premises gateway) to match this key in order for the connection to be established.

Once the connection resource is created, we must also download the VPN device configuration scripts from Azure that can be used to configure the on-premises gateway device that will be needed for using this S2S connection.

We can access a download of this configuration script by navigating to the Overview blade that belongs to this Connection.

On this next page, you are provided with a variety of options to select the model family and firmware version for your on-premises VPN device including Cisco, Juniper, or Ubiquiti devices. This Microsoft page provides additional information about devices for which configuration scripts are available for download from Azure.

Step 5: Verify the Connection

In this step, we can verify the status of our connection by navigating to the Settings > Connections blade of the Virtual network gateway. Note that the status of my connection displays as “Not connected” because it does not have an active connection to an on-premises gateway on the remote end, as I did not have access to one for use in this demonstration. A successful connection should display a status of “Connected”.

Step 6: Connect to a virtual machine

A great way to test the connection between your on-premises network and your Azure Virtual Network is to confirm a successful connection from an on-premises device to an Azure Virtual Machine that is deployed to your Azure Virtual Network. You can accomplish this by creating a Remote Desktop Connection (RDP) to your VM and then connect to it using its private IP address.

I hope that this article is helpful to those who need to configure a Site-to-Site VPN Connection between their on-premises network and their Azure Virtual Networks. Please see the provided links for more information on how to configure the S2S VPN Connection solution below.

Thank you for reading!

• Tutorial - Connect an on-premises network and a virtual network: S2S VPN: Azure portal - Azure VPN Gateway
• Connect your on-premises network to an Azure VNet: Site-to-Site VPN: PowerShell - Azure VPN Gateway
• About VPN devices for connections - Azure VPN Gateway
• Download VPN device configuration scripts for S2S VPN connections - Azure VPN Gateway
• Community-suggested third-party VPN or firewall device settings for Azure VPN Gateway

If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇

🚀Join FAUN & get similar stories in your inbox each week

Create a Site-to-Site (S2S) VPN Connection in the Azure Portal was originally published in FAUN Publication on Medium, where people are continuing the conversation by highlighting and responding to this story.