Site-to-site IPsec VPN with NSX

With NSX Data Center for vSphere establishing site-to-site IPsec VPN connections is done on the Edge instances. One X-Large ESG instance supports up to 6000 IPsec tunnels which gives you an idea about scalability.

In this exercise I’ll show you how to configure a site-to-site IPsec VPN connection between two sites that are both using NSX Edge instances. This native NSX scenario is probably the easiest and most straightforward, but it’ll hopefully give you an idea of what the IPsec VPN configuration process looks like.

Diagram

As always let’s start with a picture of what we’re trying to achieve:

NSX IPSEC.png

The goal is simple. These two organisations want to establish a secure communications channel over the Internet so that specific logical networks at each site can communicate with each other. More specifically, in this scenario the two VMs in the diagram should be able to communicate with each other.

For this exercise I already deployed the NSX Edges and the DLRs. I also configured routing between ESG and DLR on each site. We will just focus on configuring the site-to-site IPsec VPN tunnel in this article.

Configuring the Edges

Under the “Manage” tab of the ESG click on “VPN” and choose “IPsec VPN”. To start adding a new IPsec configuration click the green plus sign.

Skärmavbild 2018-10-30 kl. 20.35.02

Let’s briefly touch upon the form here.

Enabled – Wether this IPsec VPN is active or not.
Enable perfect forward secrecy (PFS) – Enabled by default. Ensures each new cryptographic key is unrelated to any previous key.
Responder Only – When enabled the IPsec VPN will never initiate a connection.

Name – A name for the IPsec VPN.
Local Id – This is the IP address assigned to the ESG’s uplink interface.
Local Endpoint –  When using pre-shared key fo authentication this can the same as “Local Id”.
Local Subnets – The IP subnets on this side that will be part of the IPsec VPN
Peer Id – A unique ID for the peer site. When using pre-shared key for authentication this can be anything although it is recommended to use the public IP address/FQDN of the remote endpoint. When using certificates for authentication this is the common name (CN) in the peer’s certificate.
Peer Endpoint – This is the IP address of the remote endpoint.
Peer Subnets – The subnets on the remote site that should be part of the IPsec VPN.

IKE Version – Internet Key Exchange version. Used to set up a security association (SA).
Digest Algorithm – The authentication algorithm to use.
Encryption Algorithm – The encryption algorithm to use.
Authentication – This can be either pre-shared key (PSK) or certificate.
Diffie-Hellman Group – The key exchange algorithm.
Extension – Aadditional parameters we can add to the IPsec VPN.

Using the IP information in the diagram above, the IPsec VPN configuration for organisation A’s ESG looks like this:

Skärmavbild 2018-11-03 kl. 12.53.45.png

And for organisation B’s ESG it looks like this:

Skärmavbild 2018-11-03 kl. 13.31.04.png

Please note that in my environment the uplink interfaces of both ESGs connect to the same L2 segment, configured with IP subnet 10.2.128.0/24.

Establishing the IPsec tunnel

With the IPsec configurations in place we can now move on with the tunnel establishment.

Start the IPsec VPN service on both edges:

Skärmavbild 2018-11-03 kl. 13.34.13.png

Let’s verify that the IPsec tunnel got established. Mark the IPsec VPN and click on “Show IPsec Statistics”:

Skärmavbild 2018-11-03 kl. 19.54.29.png

Channel status looks good. We can click on “View Details” to get some more state information. As you see not much is going on at this point. We have established an IPsec tunnel, but it’s not being used.

We can also view the IPsec VPN status at the edge instance CLI by issuing the “show service ipsec” command:

Skärmavbild 2018-11-03 kl. 20.14.30.png

Testing communication

At this point organisation A’s virtual machines connected to “LS Web” should be able to reach organisation B’s virtual machines connected to “LS Web” and vice versa. Let’s try it out.

Open a SSH or console session to one of the VMs and ping the virtual machine at the other site:

Skärmavbild 2018-11-03 kl. 23.16.52.pngAs you can see I’m pinging 172.16.1.20 from 172.16.0.20 and receiving replies.

Looking once more at the tunnel state, we can now see packets have been sent and received. It works!

Skärmavbild 2018-11-03 kl. 23.19.08.png

Conclusion

Nothing really fancy here. Good old IPsec VPN doing its thing but on top of NSX components. Site-to-site IPsec VPN is an important component of any enterprise network platform and it’s good to see NSX Data Center for vSphere delivers the functionality as well as making it easy to configure.