Now that I started studying for the AWS Certified Advanced Networking – Specialty I have to learn pretty much everything about AWS networking. Naturally VPN is a part of that.
When it comes to AWS VPN the most common use case is establishing secure Site-to-Site connections between the customer’s data center and a Virtual Private Cloud (VPC).
As an exercise for myself I decided to configure a Site-to-Site VPN connection between an NSX-T Tier-1 gateway and an AWS VPC and in today’s article I’m walking through the process of setting this up.
Let’s begin with a simple diagram showing the logical environment and the scenario that I cooked up for myself:
A database server (db01) in the data center needs to regularly dump its database to an EC2 instance (db-backups). The database server is connected to a segment which is attached to a Tier-1 gateway. The EC2 instance is connected to a private subnet in a Virtual Private Cloud (VPC).
The requirement is that only “segment-db” in the data center should be allowed to access the VPC private subnet using an encrypted connection over the Internet.
This sounds like a reasonable realistic scenario at least, right? Let’s set this up.
I begin by configuring the AWS side using the AWS Management Console.
Virtual Private Gateway
First of all I need a Virtual Private Gateway (VGW) and attach it to my VPC. This is a matter of some clicks and requires minimal configuration:
Next up is a Customer Gateway. This is a logical construct representing the VPN “device” on the data center side:
I’m selecting static routing and enter the public IP address of the VPN endpoint on the data center side. This can be a NAT-ed IP address.
The third and last component is a VPN Connection:
Here I choose the newly created VGW and Customer Gateway. I also select static routing and add the 10.10.1.0/24 prefix which matches the “segment-db” subnet.
At this point Site-to-Site VPN on the AWS side is configured and ready:
I download the vendor generic configuration file which contains all the settings for the VPN connection. This file might come in handy when configuring NSX-T:
One last thing before heading over to the data center is a small modification to the private subnet’s route table so that route propagation from the VGW is enabled. In my case this effectively adds a route for 10.10.1.0/24 with the VGW as target.
With the AWS side ready to rock n’ roll I will continue with the configuration of the NSX-T side.
I begin by creating profiles for IKE, IPSec, and DPD. This is done under Networking > Network Services > VPN > Profiles. The profiles contain settings that match the ones in the downloaded configuration file.
For the IKE profile I use the following settings:
|IKE version||IKE V1|
|Encryption Algorithm||AES 128|
|SA Lifetime (sec)||28800|
The IPSec profile looks like this:
|Encryption Algorithm||AES 128|
|SA Lifetime (sec)||3600|
And finally the DPD profile:
|DPD Probe Interval (sec)||10|
Note 1: I actually don’t have to create these profiles as the built-in “Foundation” (IKE and IPSec) and “nsx-default-l3vpn-dpd-profile” profiles work fine with AWS IPSec VPN, but I prefer having my own profiles.
Note 2: The IKE/IPSec/DPD settings in my profiles are fine for my little lab exercise. In the real world you want to consider other, possibly more secure settings.
With the VPN profiles in place I move over to VPN Services and add a new IPSec service:
Very little needs to be configured here. A name (nsx-aws), a description perhaps, but most importantly a gateway. Starting with NSX-T 2.5 IPSec VPN can be configured on a Tier-1 gateway which is exactly what I want to do here:
The last piece of configuration that I need to add is a Policy Based IPSec session which is done under IPSec Sessions:
The IPSec session is configured with the following settings:
|Remote IP||public IP of the AWS VGW|
|Pre-shared Key||PSK is in the downloaded configuration file|
|Connection Initiation Mode||Initiator|
Quite a few settings here but most of them are self explanatory.
Except for “Local Endpoint” perhaps, which I created while configuring the IPSec session.
The local endpoint serves as the VPN tunnel’s endpoint on the NSX-T side. Its IP address is assigned to the loopback interface within the Tier-1 Service Router (SR) component. This IP address needs to be unique and reachable throughout the network meaning it needs to be advertised by the Tier-1 and then distributed by the Tier-0.
On the Tier-1 gateway I make sure that “All IPSec Local Endpoints” is enabled under “Route Advertisement”:
On the Tier-0 gateway I select “IPSec Local Endpoint” under “Advertised Tier-1 Subnets”:
A quick peek at the physical router’s route table shows me there’s now a host route to the local endpoint (192.168.10.10/32):
Verify VPN connection
Now that the AWS and the NSX-T sides are configured, I should have a functional Site-to-Site VPN connection between the two environments. Let’s verify.
The IPSec tunnel status is looking good in the NSX Manager UI:
Some more details about IPSec sessions can be fetched on the Edge node CLI using the “get ipsecvpn” command. For example:
get ipsecvpn session
On the AWS side the tunnel status for the first tunnel has changed to “Up”:
I seem to have an operational Site-to-Site VPN connection. Time for the ultimate test: Can “db01” connect to the EC2 instance?
It can indeed. Mission accomplished!
For faster provisioning of the NSX-T VPN configuration I can use the API instead.
Have a look at this piece of JSON code for some inspiration:
This creates a Tier-1 with segment and IPSec VPN configuration. It can be send as the body of a PATCH request to the hierarchical policy API:
If you want to give it a try, replace the values of the following keys so they match your environment:
Besides this it should be pretty environment agnostic.
Thanks for reading.