VMware NSX-T to AWS Transit Gateway VPN

February 25, 2020

Tweet This:
Share on LinkedIn:

By Dana Gertsch, Kovarus Senior Consultant

In this post I will demonstrate how to setup an IPSEC VPN between VMware NSX-T and an Amazon Web Services (AWS) Transit Gateway. The goal is to build a hybrid cloud to support VMware vRealize Automation Cloud (vRAC) multi cloud blueprints.

My AWS environment consists of one AWS Transit Gateway (TGW), with two subnet attachments and one VPN attachment. I’m not going to discuss the deployment or configuration of a TGW. Please refer Getting Started with Transit Gateway for more information.

Tunnel 1 will be connected to a VyOS open source appliance, and the other to an NSX-T T0 router. The VyOS router and T0 router are Border Gateway Protocol (BGP) peered, with the T0 router advertising a private subnet.

Go to the AWS region hosting your TGW, then download the VPN connection configuration:

  1. Go to VPC
  2. Select Site-to-Site Connections
  3. Select the VPN connection then click Download Configuration
  4. Change the Vendor to Generic, then click Download

Now some prep work in NSX. Under Networking –> VPN add a new Endpoint using the IP address of the loopback interface (10.44.255.3).

Next, add three VPN profiles, one for Internet Key Exchange (IKE), one for IPSEC and one for Dead Peer Detection (DPD). The settings are in the previously downloaded VPN configuration file.

My IKE profile uses IKE Version IKE V1, Encryption Algorithm is AES 128, Digest Algorithm is SHA1, DH is Group 2, with a SA Lifetime of 28800 seconds.

The IPSEC profile Encryption Algorithm is AES 128, Digest Algorithm is SHA1, DH is Group 2, and the SA Lifetime is 3600 seconds.

And finally add a DPD Profile, set the DPD Probe Interval to 10 seconds.

Next add a new VPN IPSEC VPN Service, selecting your T0 router as the Gateway.

Save the Service, expand SESSION, then add a Route Based session. The settings are in the previously downloaded file. NOTE: This configuration has settings for two tunnels, so be careful to stay within one IPSEC Tunnel section.

Copy the Virtual Private Gateway Outside IP and paste it into the Remote IP and Remote ID fields. Select the Local Endpoint, copy and paste the Pre-Shared Key, then change the Profiles under Advanced Properties. Then save it.

NSX will show the session as Up within a few seconds. The AWS side takes a bit longer but tends to update in less than a minute. Looking under Details you will notice the IPSEC IS UP, but the Status is DOWN. The tunnel is DOWN because BGP has not been configured on the NSX end.

Within NSX, add the AWS BGP Peer by editing the T0 router, expand BGP (assuming you already have BGP setup), and add a new BGP peer by clicking the number next to BGP Neighbors.

Click ADD BGP NEIGHBOR. Under the appropriate IPSEC tunnel configuration in your downloaded file, find BGP Configuration Options. Copy and paste the Neighbor IP Addresses into IP Address, and the VPW ASN into the Remote AS number. Click in the Source Addresses field and select the IP address for your end of the tunnel. Set IP Address Family to IPv4. Set the Hold Down Time to 30 seconds, and the Keep Alive Time to 10 (not in the configuration file). Save the settings, then exit the T0 configuration window.

Verify that the BGP neighbor is up by expanding the T0, expanding BGP, then click on the number next to BGP Neighbors. The Status should be Up if you configured everything correctly.

Now back to AWS to check on the Tunnel status. It should be UP now.

1 BGP route has been learned from each neighbor. Click Routes under Transit Gateway Route Tables to view the details.

Looks good so far. Now take a look at the routes T0-Service Router.

get logical-routers
Logical Router
UUID                                   VRF    LR-ID  Name                              Type                        Ports
736a80e3-23f6-5a2d-81d6-bbefb2786666   0      0                                        TUNNEL                      3
cf470f79-c271-4ecf-9134-2a44562c6124   1      18     SR-KPSC-T1-1                      SERVICE_ROUTER_TIER1        5
9eb39969-d97b-41cd-b98b-6012b4df0f79   2      17     DR-KPSC-T1-1                      DISTRIBUTED_ROUTER_TIER1    4
a959aef0-5cd4-4490-9e75-749ba9a5850e   3      15     SR-KPSC-T0-1                      SERVICE_ROUTER_TIER0        6
240d86ce-3add-46c7-b231-fdf44cc9960c   4      14     DR-KPSC-T0-1                      DISTRIBUTED_ROUTER_TIER0    4

get logical-router a959aef0-5cd4-4490-9e75-749ba9a5850e route

Flags: t0c - Tier0-Connected, t0s - Tier0-Static, B - BGP,
t0n - Tier0-NAT, t1s - Tier1-Static, t1c - Tier1-Connected,
t1n: Tier1-NAT, t1l: Tier1-LB VIP, t1ls: Tier1-LB SNAT,
t1d: Tier1-DNS FORWARDER, t1ipsec: Tier1-IPSec,
> - selected route, * - FIB route

Total number of routes: 11

t0s> * 0.0.0.0/0 [1/0] via 10.44.19.65, uplink-285, 03:23:53
t0c> * 10.44.19.0/24 is directly connected, uplink-285, 03:23:55
t0s> * 10.44.192.0/18 unreachable (blackhole), 03:24:03
t1c> * 10.44.192.0/24 [3/0] via 100.64.32.1, downlink-275, 03:23:53
t0c> * 10.44.255.3/32 is directly connected, loopback-288, 02:09:38
t0c> * 100.64.32.0/31 is directly connected, downlink-275, 03:23:55
t0c> * 169.254.160.204/30 is directly connected, vti-296, 01:56:04
b  > * 172.24.0.0/16 [20/100] via 169.254.160.205, vti-296, 00:21:29
b  > * 172.31.0.0/16 [20/100] via 169.254.160.205, vti-296, 00:21:29
t0c> * fc72:d962:a376:6800::/64 is directly connected, downlink-275, 03:23:55
t0c> * fe80::/64 is directly connected, downlink-275, 03:23:55

Now to validate the routing, I’m going to SSH from 10.44.192.3 (Its segment is connected to the T1 router) to a test machine on one of the VPCs connected to the Transit Gateway.

ssh -i .ssh/id-rsa.pem ec2-user@172.31.0.75
Last login: Mon Feb 10 22:21:18 2020 from ip-10-44-192-3.us-east-2.compute.internal

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/
8 package(s) needed for security, out of 40 available
Run "sudo yum update" to apply all updates.
[ec2-user@ip-172-31-0-75 ~]$

As you can see, the configuration isn’t that hard. Connecting my Private and Public clouds allows me to place machines in the desired environment using vRealize Automation Cloud hybrid cloud blueprints.


Looking to learn more about modernizing and automating IT? We created the Kovarus Proven Solutions Center (KPSC) to let you see what’s possible and learn how we can help you succeed. To learn more about the KPSC go to the KPSC page.

Also, follow Kovarus on LinkedIn for technology updates from our experts along with updates on Kovarus news and events.