This is Part Two of configuring Site-to-Site IPSec connectivity between on-premises NSX-t and Azure. Here we are going to focus on the Azure side and learn what it takes to set up the connection between the two.
In part one of these two blogs, I showed you the steps to configure the VMware NSX-t to prepare for our Azure Site-to-Site connection. In part two, this blog post, we will focus on the Azure side to complete the configuration necessary to establish the connection.
So, without further ado, let’s started.
Microsoft Azure Side
After logging into Azure, we must create a new “Resource Group”. We can also use an existing group; on this blog post, I will create a new resource group called S2S_VPN. All the configurations/components will be hosted in this resource group.
Virtual Network – vNet
The first task is to create a virtual network with the /16 range. After we creat the vNet, we will have two subnets, the Gateway subnet and the Workload subnet.
Note: We are creating only the Workload subnet in the following steps; we will create the Gateway subnet during the provision of the Virtual Gateway. There will be more about this later.
Let’s create a vNet with the following configuration:
(See figure after config details.)
- Name: vNetConnect
- IP Address space: 10.20.0.0/16
- Subnet Name: WorkloadSubnet
- Subnet IP Range: 10.20.17.0/24
- Create
Virtual Network Gateway
After we create the vNet, we are ready to start the Site-2-Site configuration, starting with the Azure Virtual Network Gateway. From the Azure search resources, search for “Virtual Network Gateway”; select create to start the configuration using the following details:
- Name: Oasis_Gateway
- Region: Your Region
- Gateway Type: VPN
- VPN Type: Route-Based
- SKU: Basic (max 100MB)
- Virtual Network: vNetConnect
- Gateway Subnet Address Range: 10.20.254.0/28
- Public IP Address: Create new
- Public IP Address Name: Gateway_IP
- Create
Local Network Gateway
While the virtual network gateway is provisioning, we can start with the deployment of the Local Network Gateway. From the Azure search services, search for the “Local Network Gateway”; select create to start the configuration with the following details:
- Name: Oasis_S2S
- Endpoint: IP Address (you can use FQDN if it is configured)
- IP/FQDN Address: your DC public IP
- Address Space(s): provide the IP range of the on-premises network
- Create
With these configurations, we are ready to put things together and create the connection with the on-premises. So let us jump in:
Connections
Browse the resource group and select the virtual network Gateway “Oasis_Gateway” from the “Overview” page. Write down the public IP address, we need this address on the NSX-t side:
From the right side menu, click on connectors. Press “Create” to create a new Connection with the following details:
- Name: Oasis_NSX-t
- Connection type: Site-to-Site
- Virtual network gateway: Oasis_Gateway
- Local network gateway: Oasis_S2S
- Shared key: “Provide your key/password”
- Create
The last step in our configuration is to update the IP address and the Shared key on the NSX-t “IPSec Sessions”. So, let’s browse to NSX-t, Networking, VPN, IPSec Sessions; edit the “AzureSecSession”, then update the IP address of the Azure public gateway IP and the shared key:
Update NSX-t IPSec Session
Once saved, the connection will be established and you will be able to see the Green status:
Summary
Our Site-to-Site VPN is now configured and established. All the on-premises workloads can now communicate with the Azure VMs without the need for an Azure VM public IP. All that is required is the private IP address of the VM. To prove our configuration, I created a Linux VM on Azure; I can ping it from any VM connected to my on-premises NSX-t segment, as shown in the following screenshot:
What do you think?
Your article helped me a lot, is there any more related content? Thanks!