Introduction to IPsec and VNS3

This is part 2 of our IPsec with VNS3 tutorial. Check out part one here.

In the previous tutorial we not only setup an IPsec connection but also created a Secure Edge using VNS3 and federated two major clouds. From here you could join your on-premise networks into your federated cloud environments using IPsec and TLS/SSL VPNs.

As promised last time, we’ll build on this environment and setup a Static Route-based IPsec connection.

What is a Static Route-based IPsec connection?

IPsec VPN’s come in two flavors: Policy Based and Route-based, with Route-based also being split into two types, Static and Dynamic.

Policy-based IPsec VPNs encapsulate traffic between two sites as defined by a specific policy or ACL. Or in simpler terms, you specify the exact subnets you’d like to connect across the IPsec VPN.

A Route-based VPN only has a single policy (subnet pair) usually 0.0.0.0/0 to 0.0.0.0/0, meaning any subnet can send to or from any other subnet on the other side of the connection. The Route-based VPN configuration creates a system interface usually a Virtual Tunnel Interface (VTI) or Generic Routing Encapsulation (GRE) which is then used to define routes and ACLs to allow specific subnet communication. You’ll mostly want to use VTI as GRE does not encrypt the traffic.

As with all good things there is a slight compromise, because a Route-based VPN encapsulates traffic based on routes on both sides it can be easier to administer but downgrades the security. Don’t worry, we’ll cover how to improve the security of the connection later on.

Just a quick note on Dynamic Route-based VPN’s, this is done using Border Gateway Protocol (BGP) and Autonomous System Numbers (ASN). It is clever stuff but outside of the scope of this tutorial. Check out out our video walkthrough for on BGP with VNS3.

In this tutorial we will create a Static Route Based VTI IPsec VPN between two cloud providers using VNS3.

Prerequisites

You will need to have completed the last tutorial, which can be found here.

At a minimum you will need two VNS3 controllers set up.

Login to VNS3 in AWS

As we are using the free edition we are limited to 1 IPsec Endpoint. So we’ll need to delete our Policy-based endpoint from last time.

1. On the IPsec page under Action, Choose “Delete endpoint”.

2.  To create a new endpoint we follow the same steps as before: Click “New Endpoint”

3. Type a name for your IPsec Endpoint in the first box “Name for remote endpoint”, I’ve used “RouteBasedToAzure”

4. Enter the Primary IP of your controller in Azure in the “IP address of the remote endpoint” box.

5. Choose “IKEv1″ for this example

6. Enter a pre-shared key, in the “Enter PSK” box, I’m using “biglongstring”.

7. This time, we’ll check the “Enable Route-based VPN” box, this will reveal a couple more boxes.

8. We’ll leave “Via VTI”

Then we need to specify the “VTI interface address”

VTI Interfaces

Strictly speaking, VTI interfaces are not required to have an address, but for now, in VNS3 it is required. There isn’t a “right” address for the VTI interfaces between the two hosts, they just need to be non-overlapping and in the same CIDR.

If we were setting up a Dynamic Route Based VPN via BGP it is usually one of the two usable addresses in the middle of a /30 (4 address) network. One address used by one side of the VPN, the other used by the other side. Then BGP can be terminated on those shared network addresses. This technique is used to talk to Azure and Amazon AWS VPNs. We’re not doing dynamic in this case but it was worth mentioning.

Now that’s cleared up, we can enter an address range. I’m using 169.254.46.70/30 on this controller. That will leave 169.254.46.69/30 for our controller in Azure.

Then we need to specify the local subnet, enter “0.0.0.0/0” in the “Enter local (VNS3 side) subnet in CIDR notation” box

Then we need to specify the remote subnet, enter “0.0.0.0/0” in the “Enter remote subnet in CIDR notation” box

VNS3 allows you to specify any local / remote subnet pair which can be used to limit the traffic allowed over the IPsec tunnel, much like a Policy-based tunnel. However, when connecting to most devices in the wild, they will most likely expect that your “local subnet” is 0.0.0.0/0 (everything) and the “remote subnet” is 0.0.0.0/0 (everything), otherwise it won’t connect.

Finally, we just need to add the extra configuration parameters. We can use the same ones we did on our Policy-based tunnel.

These are some parameters that will work for our connection. But they are not a recommendation and they are not right or wrong. Parameters alone could fill up a blog, but in short a given set of parameters is more secure or less secure, the key thing is they have to match on both sides of the connection or it won’t connect or remain stable if it does connect.

For now, add these to the “Extra configurations” box:

phase1=aes256-sha1-dh14

phase2=aes256-sha1

pfsgroup=dh14

phase1-lifetime=86400s

phase2-lifetime=28800s

local-peer-id=<this vns3 public ip>

e.g local-peer-id=52.149.159.65

Excellent, you should have something that looks like this:

Click “Create Endpoint”. You should see something like this:

That’s the AWS side of the connection setup, let’s hop across to Azure and set that side up.

Login to VNS3 in Azure:

1. First we need to delete the existing endpoint, on the IPsec page under Action,  Choose “Delete endpoint”.

2. Click “New Endpoint”

3. Type a name for your IPsec Endpoint in the first box “Name for remote endpoint”, I’ve used “RouteBasedToAWS”

4. Enter the EIP of your controller in AWS in the “IP address of the remote endpoint” box.

5. Choose “IKEv1” for this example

6. Enter a pre-shared key, I’m using “biglongstring” 

7. This time, we’ll check the “Enable Route-based VPN” box, this will reveal a couple more boxes.

8. We’ll leave “Via VTI”

9. Enter 169.254.46.69/30 in the “VTI interface address” box

10. Then we need to specify the local subnet, enter 0.0.0.0/0 in the “Enter local (VNS3 side) subnet in CIDR notation” box

11. Then we need to specify the remote subnet, enter 0.0.0.0/0 in the “Enter remote subnet in CIDR notation” box

12. Add the Extra configuration parameters.

phase1=aes256-sha1-dh14

phase2=aes256-sha1

pfsgroup=dh14

phase1-lifetime=86400s

phase2-lifetime=28800s

local-peer-id=<this vns3 public ip>

And we are done, you should have something that looks like this:

You should also see that they connection is now up, if everything has gone to plan:

Security

Now we have our connections created on each controller we need to loop back and improve the security by tightening up our respective security groups. 

We can do this by specifying the exact /32 address of our endpoints for our UDP ports.

In our AWS Security group we need to “Edit inbound rules” and update the source IP to the Primary IP of the controller in Azure.

Once you are done your SG should look similar to this:

Next we’ll update our Azure NSG,

First we will have to change the “Source” from “Any” to “IP Addresses” then we can update the “Source IP addresses/CIDR ranges” to the EIP of the controller in AWS. 

Setting up the Static Routes

Now we have the connection and security setup we need to be able to pass traffic across the IPsec tunnel. To do this we need to define the routes for the specific subnets that will be sending traffic. 

In our controller in AWS, under the Connections section you will find “Routes”

The first thing to do is specify the the subnet of the VNET in Azure in the “Enter CIDR for new route”, mine is 10.2.1.0/24.

We can give it a description, I’ve used ToAzure.

Under “Route type” we can see several options, choose “Route-based VPN tunnel”, the next box “Route-based VPN tunnel for this route” should be auto-populated, but check it specify’s your tunnel.

Then click “Add route”, this is what you should see:

Now step across to the controller in Azure and repeat the process, just remember to substitute the subnet for the AWS VPC subnet, mine is 172.16.0.0/24. 

This is how it looks in my controller:

Now we have the routes setup we can pass traffic across the tunnel, here are a couple of pings to prove it:

You’ll need to launch a VM in the Azure VNET or AWS VPC, then you can ping your controllers private IP. If that sounds a bit advanced, don’t worry. Next time we will launch a couple of VM’s and connect them to the VNS3 Encrypted Overlay, then we’ll have full real world topology to explore.

Conclusion

In this second IPsec guide we have setup a Static Route-based IPsec VPN, which is a little more involved but it is fast becoming the de facto way of setting up an IPsec VPN. In this real world example we also demonstrated how to improve the security of your IPsec VPN endpoints.

Next time we will introduce the VNS3 Encrypted Overlay network. You can reach out to contactme@www.cohesive.net if you have any questions or would like to know more about VNS3’s extensive capabilities.

Thanks for reading.