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
| PFS | ENABLED |
| Name | Whatever you want |
| Local ID | Your Public IP assigned to the uplink (Or the local NAT IP) |
| Local Endpoint | Your Public IP assigned to the uplink (Or the local NAT IP) |
| Local Subnets | 0.0.0.0/0 (or your overall local subnet so /16 or something) AWS only allows ONE subnet here! |
| Peer ID | AWS VPN Gateway Public IP |
| Peer Endpoint | AWS VPN Gateway Public IP |
| Peer Subnets | 0.0.0.0/0 (your overall peer subnet RANGE for the VPC) AWS only allows ONE subnet here! |
| IKE Version | IKEv1 |
| Digest Algorithm | SHA1 |
| Encryption Algorithm | AES |
| Pre-Shared Key | Supplied by AWS when VPN Gateway was created |
| DH Group | 2 |
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
| PFS | ENABLED |
| Name | Whatever you want |
| Local ID | Your Actual Public IP whether assigned to the uplink or not, can’t be local IP |
| Local Endpoint | Your Public IP assigned to the uplink (Or the local NAT IP) |
| Local Subnets | Comma separated list of local subnets |
| Peer ID | GCP VPN Gateway Public IP |
| Peer Endpoint | GCP VPN Gateway Public IP |
| Peer Subnets | Comma separated list of local subnets |
| IKE Version | IKEv1 |
| Digest Algorithm | SHA1 |
| Encryption Algorithm | AES |
| Pre-Shared Key | Whatever you choose |
| DH Group | 2 |
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
| PFS | DISABLED |
| Name | Whatever you want |
| Local ID | Your Public IP assigned to the uplink (Or the local NAT IP) |
| Local Endpoint | Your Public IP assigned to the uplink (Or the local NAT IP) |
| Local Subnets | Comma separated list of local subnets |
| Peer ID | Azure VPN Gateway Public IP |
| Peer Endpoint | Azure VPN Gateway Public IP |
| Peer Subnets | Comma separated list of local subnets |
| IKE Version | IKEv1 |
| Digest Algorithm | SHA1 |
| Encryption Algorithm | AES256 |
| Pre-Shared Key | Whatever you choose |
| DH Group | 2 |
NOTE: This one you must have PFS disabled and you must use AES256 but otherwise it is similar to the GCP setup.