Step By Step Deploy VMware NSX with Microsoft Azure IPSEC VPN Site-to-Site

Intro:

Some time ago I wrote an article on how to configure Citrix NetScaler Cloudbridge Connector with Microsoft Azure IPSEC Site-to-Site VPN tunnel NATed behind a router, since then I got some requests to showcase the same configuration using VMware NSX ESG (Edge Services Gateway) so that’s exactly what we are going to go through this post. I love to do first time posts because its more exciting and doesn’t take from efforts of other community professionals so  some research was done to check if someone has already posted a similar setup with step by step instructions but with vain thus lets go ahead.

Prerequisites:

• NSX with Logical switch and ESG (Edge Services Gateway).
• Microsoft Azure subscription.
• Router with public IP.

We will walk through Azure configuration from the ground up never the less for NSX, at least to reach to the point of having a working NSX Edge ESG, follow this article Step By Step Deploy VMware Cross-vCenter NSX with Local Egress .

Environment:

Public IP for Azure will be created in the course of this post, Physical network represents the current address range configured on the local router LAN interface and on Azure which will also be created later, Logical network represents NSX logical switches networks required to connect with Azure hosted services and same goes for Azure which represents the subnets required to communicate to local NSX environment, and ESG uplink IPs are assigned to the ESG uplink interface connecting to the physical router.

Scope:

• Create a Virtual Network on Azure with required subnets.
• Create Virtual Network Gateway on Azure with public IP.
• Create Local Network Gateway on Azure.
• Create VPN IPSEC connection on Azure.
• Add Secondary IP on NSX ESG uplink interface.
• Create IPSEC VPN on NSX.
• Configure NATing, Routing, and Firewall rules on Local Router.
• Create a VM on azure and Test.

Configuration:

1- Login to Azure Portal “New”, search for “Virtual Network” and Create.

2- Fill in the required details (don’t mind the red flags as I already have them pre-created).

3- Add a new “ Virtual Network Gateway” and fill in the required details. If the Virtual Network created earlier is blacked-out, it means that a Gateway subnet needs to be created so head to the virtual network subnet settings and add a subnet gateway within the address space with a /29 subnet. My actual address space is 192.168.0.0/16 so I created a Gateway subnet of 192.168.11.0/24 ( It should be at least /29 ).

Note the following settings:

– Policy-Based: NSX VPN as of now only supports Policy-Based VPN type.

–Virtual Network: This represents the virtual network created earlier (Resource group is chosen by default where virtual network is created).

– Public IP: Create a new public IP and make sure to choose Static.

4- Add a new “Local Network Gateway”. This points to the public IP of the local router and the logical network that will communicate through this VPN which would be our internal NSX Logical VXLAN network address range.

Note the following settings:

– IP address: Public IP on local router.

– Address Space: subnets required to communicate through this VPN that are hosted inside NSX. My VXLANs are 172.16.X.X/24 so a /16 would cover all my NSX logical networks.

– Use Existing Resource group and choose the same one that the virtual network and gateway were created earlier.

5- Add a new “Connection” from Azure ( This is the actual VPN connector which will group the local gateway and virtual gateway into an IPSEC tunnel ).

Note the following settings:

– Connection Type: Site-to-Site (IPSEC).

– Resource Group: Same as created earlier.

– Virtual Network Gateway: Same as created earlier.

– Local Network Gateway: Same as created earlier.

– Shared Key (PSK): password123password123password123password123 . Only use letters and numbers making sure its a bit long, mine is 44 long .

6- Go to NSX Networking & Security in vCenter web and configure an additional IP for NSX Edge on the uplink interface so it will be used for dedicated traffic for VPN tunnel.

Go to “VPN” inside the ESG gateway and Enable. Set a global configuration pre-shared key although not mandatory. Add a new VPN Connection.

Note the following settings:

– PFS: Disable Perfect Forward Secrecy since its not supported with Azure Static-Policy based VPN.

– Local Id: The new IP that was added to the ESG uplink interface earlier.

– Local Endpoint: The same new IP that was added to the ESG uplink interface earlier.

– Local Subnets: Logical switches hosted on NSX that will be able to communicate with Azure through this VPN tunnel. 172.16.0.0/16 covers all my /24 subnets but we can enter each network manually if required.

– Peer Id: The public IP of the Azure virtual network gateway that was created earlier.

– Peer Endpoint: The same public IP of the Azure virtual network gateway that was created earlier.

– Peer Subnets: The subnets created on Azure earlier that will need to communicate with Logical NSX switches through this VPN tunnel.

– Encryption Algorithm: AES.

– Pre-Shared Key: same as one used on Azure Connection earlier. password123password123password123password123 .

– Diffie-Hellman Group: DH2 . Took me some time to catch this but the VPN tunnel will not work with any other option because of Azure Policy based VPN using IKE1 which would support DH2 only so this is a must.

7- Because NSX ESG is an internal IP on the local physical network and not a public IP (which is hosted on the physical router), Nating should be configured so that traffic originating from the NSX VPN IP “10.20.34.198” to destination Azure public IP “52.173.84.117” is going through physical public IP on router that was specified in Azure VPN Connection settings and Local gateway settings “ This is a must if more than one public IP is on your router”, this would be a source NAT.

Nating should also be configured for traffic originating from Azure Public IP “52.173.84.117” to destination NSX VPN IP “10.20.34.198” to ensure VPN traffic is reaching the VPN IP and not NAted by the local physical router. This would be a destination NAT.

A static route should be added to specify that traffic destined to Azure subnets “192.168.0.0/16” should be routed through NSX VPN IP “10.20.34.198” to make sure this traffic is routed through the VPN tunnel. This is a must.

Firewall rules should be in place to allow traffic flow between subnets in local network and subnets in Azure. Also IPSEC-ESP should be opened on the firewall to the NSX VPN IP. I have a Mikrotik router but this should be straight forward for all routers.

8- Lets check from Azure side and from NSX side if VPN tunnel is established.

9- I have created a VM on Azure with IP “ 192.168.4.5” and I have a local VM connected to an NSX Logical switch with IP “172.16.3.30” so lets test:

Conclusion:

Fairly simple but not straight forward is all I have to say about this never the less how great it would be to have a VMware Software Defined Data Center and Microsoft Azure public cloud interconnected to form the ultimate hybrid environment. Any comments or suggestions are highly appreciated.

Salam  .