How To Configure NSX IPSEC VPN With AWS, Azure, and GCP • Chris Colotti's Blog

How To Configure NSX IPSEC VPN With AWS, Azure, and GCP

The last few weeks I have been putting together a new lab for my team at Cohesity to use for live demos.  Part of the overall design was to allow for VPN connections to the various clouds that Cohesity supports so we can demonstrate real world use cases with Cloud Editions running real-time in each cloud connected back to the on premises lab.  While the overall lab architecture is still coming together the core networking we selected to use was VMware NSX.  With that we deployed a core NSX Gateway that is to act as the central aggregation point for internet access and VPN connections.  What I found out quickly is that connecting an NSX VPN to Azure, GCP, and AWS is not very well documented and each one seemed to be slightly different.  So now that it is all done and working I wanted to quickly document each clouds specific settings to work with the VMware NSX Gateway for IPSEC VPN.  Hopefully this saves other the hours of trial and error and troubleshooting it took me.

In order to try to keep this simple and brief I will cover the main points for each cloud that relates to the NSX Gateway settings.  I won’t go into any firewall rules you may need to pass traffic this is just how to get tunnels up and running.  Each cloud seemed easiest to configure as POLICY based.  I am also assuming you have set up the appropriate VPN gateways and networks per each cloud vendor.  Again this is just the settings specific to NSX once you have all the core items deployed including routing tables.  I have highlighted the items that have minor differences.

NSX Static Route Policy Based VPN Settings:

AWS

PFSENABLED
NameWhatever you want
Local IDYour Public IP assigned to the uplink (Or the local NAT IP)
Local EndpointYour Public IP assigned to the uplink (Or the local NAT IP)
Local Subnets0.0.0.0/0 (or your overall local subnet so /16 or something) AWS only allows ONE subnet here!
Peer IDAWS VPN Gateway Public IP
Peer EndpointAWS VPN Gateway Public IP
Peer Subnets0.0.0.0/0 (your overall peer subnet RANGE for the VPC) AWS only allows ONE subnet here!
IKE VersionIKEv1
Digest AlgorithmSHA1
Encryption AlgorithmAES
Pre-Shared KeySupplied by AWS when VPN Gateway was created
DH Group2

NOTE:  What wrapped me up was the Local and Peer subnets.  In the other configurations you will see standard comma separated notations and that does NOT work for AWS.  You will still need to propagate your routing tables

NSX Static Route Policy Based VPN Settings:

GCP

PFSENABLED
NameWhatever you want
Local IDYour Actual Public IP whether assigned to the uplink or not, can’t be local IP
Local EndpointYour Public IP assigned to the uplink (Or the local NAT IP)
Local SubnetsComma separated list of local subnets
Peer IDGCP VPN Gateway Public IP
Peer EndpointGCP VPN Gateway Public IP
Peer SubnetsComma separated list of local subnets
IKE VersionIKEv1
Digest AlgorithmSHA1
Encryption AlgorithmAES
Pre-Shared KeyWhatever you choose
DH Group2

NOTE:  I found that if you are using NAT to your NSX Gateway like I am you MUST set the local IP to the actual Public IP.  You will see errors in the GCP connection logs if you don’t.  Unlike AWS you can use comma separated subnet lists.

NSX Static Route Policy Based VPN Settings:

Azure

PFSDISABLED
NameWhatever you want
Local IDYour Public IP assigned to the uplink (Or the local NAT IP)
Local EndpointYour Public IP assigned to the uplink (Or the local NAT IP)
Local SubnetsComma separated list of local subnets
Peer IDAzure VPN Gateway Public IP
Peer EndpointAzure VPN Gateway Public IP
Peer SubnetsComma separated list of local subnets
IKE VersionIKEv1
Digest AlgorithmSHA1
Encryption AlgorithmAES256
Pre-Shared KeyWhatever you choose
DH Group2

NOTE:  This one you must have PFS disabled and you must use AES256 but otherwise it is similar to the GCP setup.

About Chris Colotti

Chris is currently a Principal Architect at Cohesity. In his role he spends the majority of his time supporting Cohesity events and creating outward facing content. He also acts as an active interface between the field and engineering/product management as customer zero in the TAG production lab. Chris is active on the VMUG and event speaking circuit and is available for many events if you want to reach out and ask. Previously to this he spent close to a decade working for VMware as a Principal Architect. Previous to his nine plus years at VMware, Chris was a System Administrator that evolved his career into a data center architect. Chris spends a lot of time mentoring co-workers and friends on the benefits of personal growth and professional development. Chris is also amongst the first VMware Certified Design Experts (VCDX#37), and author of multiple white papers. In his spare time he helps his wife Julie run her promotional products as the accountant, book keeper, and IT Support. Chris also believes in both a healthy body and healthy mind, and has become heavily involved with fitness as a Diamond Team Beachbody Coach using P90X and other Beachbody Programs. Although Technology is his day job, Chris is passionate about fitness after losing 60 pounds himself in the last few years.

2 comments

  1. Note that IKEv2 is supported on AWS since recently, I’m curious if IKEv2 is thus usable with your NSX setup.
    https://aws.amazon.com/about-aws/whats-new/2019/02/aws-site-to-site-vpn-now-supports-ikev2/

Leave a Reply

Your email address will not be published. Required fields are marked *