Over the last year, we’ve been doing a lot of testing with VMware Cloud on AWS (VMC) and it’s pretty slick. In the past, we’ve used our physical parameter device (Cisco ASA) to handle the VPN traffic, but yesterday I wanted to set up a VPN to the management gateway, and I wanted it done now. Since I don’t have direct access to the ASA, I have to submit a ticket to our NetSec team to have them do it, and they have their own work going on, so naturally I decided to use an NSX Edge for this.

I pulled up the two interfaces side by side so I could fill out both at the same time, but I noticed the VMC side was missing a few things that I had on the NSX side: Local ID & Peer ID. But the VMC side also had an option for IKE & SHA versions, which I didn’t have on the NSX side. Keep those in mind as you step through this, let’s get started…

My Setup

My NSX Edge is actually behind the ASA I mentioned earlier, but I have some public to private NATs in place already, so I used one of those and set a secondary IP on my ESG’s uplink interface. I wanted to connect to the Management Gateway so I could have direct access to the vCenter, which can be seen here:

And I’d need an IP on my NSX Edge for the VPN tunnel, so I added the secondary address:

Here’s my VMC on AWS VPN to the Management Gateway

  • VPN Name: this is just a display name
  • Remote Gateway Public IP: Exactly what it sounds like, this is my public IP that NATs to the private 172.16.56.4 address.
  • Remote Gateway Private IP: If you’re not using a NAT and your ESG is IP’d with a public IP, you’ll leave this blank, in my case, the .4 address was entered here
  • Remote Networks: the subnets on the other side of the VPN tunnel, in my case: 172.16.56.0/24
  • Local Gateway IP: the public IP of the Management Gateway on VMC, which is pre-populated
  • Local Network: the local subnet to communicate across the VPN tunnel, for me: 192.168.128.0/20
  • Encryption: AES 256 (must match on both sides)
  • Perfect Forward Secrecy: Enabled
  • Diffie Hellman: DH14 (I started with DH2, but changed to DH14, must match on both sides)
  • IKE Version: IKEV1 (I left this alone, especially since I didn’t see where to edit in NSX 6.3.5, I don’t recall seeing it in 6.4, neither)
  • SHA Version: SHA1 (same caveat as IKE version)
  • Pre-shared key: whatever password you want, preferably something strong & complex, will be used when created on the NSX-side

Now lets look at the NSX side of the VPN tunnel

  • Enabled: Checked
  • Enable perfect forward secrecy: Checked
  • Name: display name
  • Local Id: After testing, I found the best thing here is the IP address of the ESG for the VPN tunnel, in my case 172.16.56.4
  • Local Endpoint: the IP address on the ESG used for the tunnel, 172.16.56.4
  • Local Subnets: the subnets on this side of the tunnel that will communicate across the tunnel
  • Peer Id: Same as the Local Id, there’s no option for this on the VMC side, so after testing, I found the Public IP of the VMC Management Gateway works best
  • Peer Endpoint: Public IP of the VMC Management Gateway
  • Peer Subnets: the private IP subnet of the VMC Management network
  • Encryption Algorithm: AES256 (must match on both sides)
  • Authentication: PSK
  • Pre-Shared Key: the same password you set on the VMC (must match on both sides)
  • Diffie-Hellman Group: DH14 (must match on both sides)

Firewall Rule Accelerator

From there, the VPN tunnel connected; however, the firewall rules may not be in place to allow my local segment to talk to the management segment on VMC. Never fear, VMC has “Firewall Rule Accelerator” that will generate the rules you need to allow the segments to communicate:

Now I’m good to go, with firewall rules in place

Some Troubleshooting

I got an error stating the IKEV1 password issue, which I’m sad I didn’t screenshot because I haven’t been able to completely recreate. As it turned out, it was directly related to the Local & Peer IDs. Typically, when setting up an IPSec VPN tunnel between two NSX Edges, you can set your IDs to match. For instance, if I did them between ORD and IAD datacenters, the ORD NSX Edge would have the Local ID of ORD, and Peer ID of IAD; and vice versa for the IAD NSX Edge. Since there were no options for local or peer ID on the VMC Side, I kind of stumbled through it. On a whim, I tried the IPs and it connected flawlessly.

You’ll also want to make sure that the local subnets/network match what’s entered in Peer Subnets (NSX) or Remote Networks (VMC). I added an extra subnet on the NSX side and then received a different IKE error on the VMC side:

And there you have it! That’s all you need to establish your site-to-site IPSec VPN tunnel from your on-prem datacenter to VMC on AWS using NSX!