I have been a big fan of OpenSSL on the Linux platform, and have used it for many years to set up encrypted site-to-site VPN connections between locations. This usually entails me settings up a CentOS server at each location, dropping the latest rev of OpenSSL on each, and setting up the connections via hub and spoke topology. OpenSSL is pretty cool – it runs via certificate based authentication, comes out of the box with some sweet support scripts that handle the creation and maintenance of a CA via openssl, and has a very simple config file to tweak various settings. I have used this solution extensively in consulting engagements for small businesses.
On the Enterprise side, I have supported IPsec site-to-site tunnels on Cisco ASA 5525x series firewalls. While SSL encrypted tunnels are generally acceptable for any type of internet facing traffic, there is no doubt that IPsec is the standard for corporate VPN connections for site to site traffic.
I don’t own an IPsec capable device, and most small businesses I work with don’t either. Hence the OpenSSL solution I have been leveraging for years…. But what if you need to setup an encrypted interface with an organization that for security or operational reasons only does IPsec? While open source free IPSec solutions are available, they are generally very difficult to work with and troubleshoot, and often don’t reliably work with every vendors’ specific implementation of IPsec.
It just so happens that one of the many services bundled with the NSX Edge is indeed IPsec VPN. This is yet another cool service bundled in to what is definitely the “swiss army knife” of network appliances. It is easy to set up, can support up to 10 tunnels per Edge, and is fully vetted to work with most major vendors’ implementations (including Cisco ASA, which probably represents the bulk of the corporate IPsec install base).
In this post, I am going to be replacing the OpenSSL site-to-site solution that I have used to link my home network to the network at my Mom’s house. Mom is always having computer issues requiring remote support, so years ago I set up an OpenVPN SSL tunnel between our two locations so that can access any of her local systems securely. I now have placed a Dell R610 running ESXi 5.5 with NSX 6.1.4 installed at her place, and the gateway device handling all traffic is of course an NSX Edge device. I am running NSX 6.2 in my home lab, so as an added benefit to this set up we will be verifying cross release functionality.
Let’s get started!
Log into the Web client and navigate to “Networking & Security”.
Select the NSX Edge Service Gateway that will be performing the IPsec VPN function.
Navigate to the “VPN” tab, and select “IPsec VPN”. Select the green plus to define a new tunnel configuration.
TUNNEL INFORMATION
If you have ever configured IPSEC on an ASA, either via CLI or ASDM, it can be a somewhat complicated procedure. In my opinion the wizard in the Edge greatly streamlines the process, and is actually quite simple.
First thing is to select whether the specific tunnel should be enabled. All installations should also enable Perfect Forward Secrecy – this is just an extra security step that causes a new Diffie-Hellman key exchange to be negotiated for the PHASE 2 tunnel. Basically, without this enabled, the symmetric key that is created between the tunnel endpoints during PHASE 1 key negotiation is used for the actual encryption of data over the PHASE 2 data tunnel. This is a tradeoff of CPU cycles versus security. If it is off the connection will continue to use the same symmetric key for re-negotiations of additional PHASE 2 tunnels that are re-established due to connection issues or timeouts. You can choose to enable or not – bear in mind this setting needs to match at both endpoints or tunnel creation will fail.
I also give the tunnel a distinct name.
LOCAL INFORMATION
I set Local ID and Local Endpoint to match the Edge Interface IP that will be terminating the tunnel. In this case, my Edge is the single gateway between my lab/home networks and my Verizon FIOS connection. It’s UPLINK interface is IP’d with 192.168.1.201, facing my Verizon FIOS router which has specified this IP as a “DMZ Host” via NAT. This means I don’t have to muck around with port forwarding on the POS Verizon FIOS router, and all inbound traffic to my public IP will get forwarded to my Edge at 192.168.1.201. Same deal at Mom’s house, which we will verify in a bit.
Next we need to define local network traffic that will be participating in the tunnel. The defined networks here are what we intend our partner organization or endpoint to be able to access via the tunnel. The entries here will need to agree with what the partner endpoint has configured for its “Remote Subnets”. Vice a versa for us – our “Remote Subnets” will need to match their entry for “Local Subnets”, otherwise PHASE 2 encrypted tunnels will fail to form due to the disagreement of which subnets can participate in bidirectional traffic.
I am putting a few of my local subnets here, as I may need to access Mom’s stuff from any number of systems on multiple local networks. You can get as granular as you want in the definitions, narrowing down to a single host if necessary.
PEER INFORMATION
Now I enter the settings for the remote partner endpoint – this could be a Cisco ASA, a CheckPoint FW, etc. In this case it is a 6.1.4 Edge running at Mom’s.
Similar to the Local Endpoint entries, we need to define the Peer Id and Endpoint. The Edge at Mom’s is IP’d and set up the same way as mine – it faces her Verizon FIOS router the same way, actually has the same 192.168.1.x IP as mine, so I enter this as the Peer Id.
The Peer Endpoint needs to be set to the public IP of the partner connection, in this case the public IP bound to Mom’s Verizon router. Like my set up, this Verizon router is also forwarding all incoming traffic to the Edge via NAT. IPsec has traditionally had some issues working behind NAT setups – so this will be a good test of the Edge’s ability to work while behind NATs at both sides.
Next we enter the remote subnets that we want accessible over the tunnel. These are Mom’s local subnets that I want to be able to reach. Other than the transport network between the Edge and upstream Verizon router (192.168.1.0/24), all the other subnets between my house and my Moms are unique. If they weren’t, and I wanted to enable IPsec communication between the subnets, we would have to put some NAT configs in place to rectify the clash of RFC1918 IP space. Thankfully, we won’t need to mess with that here.
NOTE: For local routing, all the “Local Subnets” I identified in the config earlier have their north bound default gateway set to the specific Edge that is handling the IPsec tunnel. This piece is critical, as initiated traffic from my local subnet of 172.16.10.0/24 destined for one of Mom’s subnets, say 172.16.20.0/24, needs to be seen by this Edge in order to be identified as interesting traffic to be encrypted and sent over the IPsec tunnel. Obviously, routing needs to be configured appropriately traffic destined for tunnel inclusion gets routed to the Edge handling the tunnel!
ENCRYPTION / AUTHENTICATION
We need to set encryption and authentication settings. I am selecting AES256 for the encryption scheme, and setting a Pre-Shared Key for authentication. You can also set up Certificate based authentication if desired.
I selected Diffie-Hellman Group 5 for key creation encryption scheme, and am leaving extensions alone as none are needed for this configuration.
And that’s it!! Hit OK and move on to configuring the Peer……
MOM’S CONFIG
I am not going to go into much detail here, as the config is the same, but “reversed”. The most important thing to remember when configuring the peer, whether it be another Edge, Cisco ASA, etc., is that all encryption, authentication, local and remote subnet settings need to match! IPsec tunnels not coming up are notoriously difficult to troubleshoot, and 9 times out of 10 in my experience it usually comes down to a mis-matched setting that has been over looked.
This can be a difficult troubleshooting exercise if the peer is run by a different organization or team, but luckily for this lab I obviously have administrative control over both endpoints.
So – in a nutshell:
- Copy/pasting my config’s “Local Subnets” to Mom’s “Peer Subnets”
- Copy/pasting my config’s “Peer Subnets” to my Mom’s “Local Subnets”
- Matching all encryption selections
- Setting the Peer Id to match my Local Id
- Setting the Peer Endpoint to match the public IP bound to my Verizon FIOS router
- Matching the pre-shared key
- Hitting OK to finalize the config
Once complete, publish the changes on both sides.
TESTING
If everything was set correctly, the tunnel should come up immediately on its own, as indicated by the “Status” column for the defined tunnel.
You can also select the “Show IPsec Statistics” for another view of really the same information.
The reporting and statistics that are available in the Management Console are pretty Spartan – it would be cool if the product charted bandwidth consumption by tunnel, similar to what it does for SSL VPN connections, but that doesn’t appear to be available in 6.2. I hope they add some more basic reporting in the next release!
Let’s test access – from the above statistics screenshot I can see that all 24 tunnels that were defined are up, so this means any combination of local and remote access should be working.
A ping from my Fedora 20 system to the vCenter system running at Mom’s…. Looks good! That latency number is far lower than what I used to see via my OpenSSL setup.
And an RDP connection…. Also good!
Sweet… pretty simple setup, and now I have an AES-256 encrypted IPsec tunnel between the location!
ASA CONFIGURATION
Now that we know we have a legitimate working configuration, we can explore another nifty feature – exporting our tunnel settings into a Cisco ASA config with the push of a button!
This will parse out comparative settings for an IOS configuration. This is a pretty cool troubleshooting tool to forward to a partner that is configuring the peer on an ASA.
CONCLUSION
I earlier referred to the Edge as the “Swiss Army Knife” of network appliances, and it no doubt deserves this label. I haven’t been able to test any great load through this tunnel between the two locations, as might be needed in an Enterprise implementation. The best I have done is a nightly ZFS files system replication between a couple of FreeNAS 9 virtual machines that are syncing via this tunnel. That replication is usually sending newly downloaded movies, media etc. and usually has Gigabytes to send each night. It pegs out my Mom’s FIOS connection at 25Mbps for an extended period of time each night, and I haven’t yet witnessed a crash, disconnect, or hiccup.
I will update the post once I have some time to get some iperf blasts running over the tunnel, to better test how the tunnel performs under load as far as through put and latency.
And that’s it…. Pretty straightforward I think. And the best part about it is my Mom has no idea that she has some of the coolest virtualization technology on earth running at her place, and her FIOS connection is helping me vet out this functionality.
Thanks Mom!
