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.

Introduction to IPsec and VNS3

IPsec is a way to connect two private networks together over an untrusted network to create a Virtual Private Network (VPN). The internet is the obvious untrusted network but it could also be a 3rd parties service, AWS’ Direct Connect or Azure’s Expressroute for example. 

Often there is a need to connect from the Cloud to Data Centers and offices (Cloud to Ground) or from the Cloud to multiple Clouds. Traditionally you would need to use each cloud provider’s native VPN solutions and multiple services to connect each Point of Presence (PoP) which can leave a complicated and costly web of complexity in its wake. 

That’s where VNS3 comes in, VNS3 is a Virtual Application Security Controller. It is a cloud based virtual device that you launch in your cloud account to centralize your connectivity and security needs or what we like call a Secure Edge.

In this tutorial series we will use VNS3 to build out a Secure Edge using some of the many functions of VNS3, with a focus on IPsec. There are three main types of IPsec configuration: Policy Based, Static Route Based, and Dynamic Route Based.

In this tutorial we will create a simple Policy Based tunnel between two cloud providers by using VNS3. We will launch VNS3 in AWS, launch VNS3 in Azure, then connect them using IPsec.

Prerequisites

You will need an Azure account and a AWS account, it is free to sign up. 

Both providers have Free Tier options and VNS3’s Free Edition means you can follow this tutorial for no cost. You can still follow along if you don’t have both accounts, just launch two controllers in separate VNETs / VPCs in your chosen cloud, the IPsec setup will still be relevant.

Launch VNS3 in AWS

1. Launch VNS3 from the AWS Marketplace

Or from the AWS Console choose Launch Instance. Search for VNS3 and select VNS3 Free – Network Controller (Firewall/Router/VPN)

2. Select your instance size. VNS3 can reliaby run on instances as small as a t2.micro

3. Configure your instance. You can leave storage defaults. We suggest adding a Tag for the Name

4. Configure security group

We will add a couple of rules to allow IPsec connections

Add UDP rule for IPsec

Under “Type” choose “Custom UDP”, in “Port Range” type 500. In source paste 0.0.0.0/0 from the line above. This is used for Phase 1

Add UDP rule for NAT Traversal

Under “Type” choose “Custom UDP”, in “Port Range” type 4500. In source paste 0.0.0.0/0 from the line above. This is used for Phase 2

Add Protocol 50 rule for Native IPsec

Under “Type” choose “Custom Protocol”, in “Protocol” type 50. In source paste 0.0.0.0/0 from the line above. This is used for Phase 2.

5. Review and Launch. Select “Proceed without a key pair”

Now we need to allocate an “Elastic IP’

Assigning an Elastic IP

In the AWS console find “Elastic IPs”

1. Click “Allocate Elastic IP address” and allocate a new address

2. From “Actions”, select “Associate Elastic IP address”. Choose your Instance from the dropdown and choose the private IP address of the instance. Click “Associate”

Disable Source/Destination Check

Now in a Browser we can log into VNS3 using the Elastic IP, but before we do that we need to disable the source / destination check in the AWS console. This is necessary so VNS3 will be able to pass through traffic.

Select the instance, go to Actions > Networking > Change source/destination check, then tick Stop and Save. We need to do this so our IP packets won’t be dropped when we use the IPsec tunnel.

Login to VNS3

Now we can login to VNS3, in the address bar of your favorite browser type https://<your elastic ip>:8000/

You may need to navigate through the “Proceed to unsafe” option in your browser. Note this is only because the browser doesn’t recognize the Certificate Authority used to sign the SSL certificate. Your traffic is still protected by HTTPS.

Then login with the username: vnscubed 

The password is the instance id which can be found in the AWS console, on the detail tab.

We always recommend changing the passwords, which is under Admin > Passwords in the VNS3 UI.

Excellent! You have launched a VNS3 controller, which should look like this: 

But this is only half the story; all IPsec connections have two ends. Let’s jump into Azure and see how launching VNS3 differs.

Launch VNS3 in Azure

1. Launch VNS3 from Azure Marketplace
Or in the Azure Portal search for “VNS3” and Choose VNS3 (Firewall/Router/VPN) in the Marketplace menu.

2. Select or Create a Resource Group and enter a Virtual machine name.

3. Accept the ssh key, you won’t need it as VNS3 is a sealed appliance. Access is by the UI or API, more on the API later.

3. Click through to “Review and Create”. Click Create.

4. Once it’s done navigate to the NIC in the Resource group and Enable IP forwarding under IP configurations. Don’t forget to save!

5. Next we need to update the NSG to allow IPsec traffic. Navigate to the NSG > Inbound security rules > Add.

We will add UDP port 500 and 4500, like we did in AWS. This is for IPsec traffic.

Leave Source, Source port ranges and Destination as the defaults, for the purposes of this tutorial. 

Update the Name to something relevant, I’ve used “IPsec”

Login to Azure VNS3 

Now we’ve done the housekeeping, we are ready to log in. Navigate to the resource and find the Public IP

In the address bar type https://<your public ip>:8000/

The username will be vnscubed 

This time the password is a little different, you need to combine the instance name with the private IP address, like this <instance name>-<private IP>. For example:

vns3controller-10.10.10.1

Then, as before change the passwords.

Now you should have two VNS3 controllers, awesome!

Let’s setup one half of the Policy Based IPsec connection. As we are in the controller in Azure we can start there.

Setting up an IPsec Connection

To setup the IPsec connection:

1. Choose IPsec in the side menu and click New Endpoint

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

3. Enter the Elastic IP of the controller in AWS in the “IP address of the remote endpoint” box.

4. Choose IKEv1 for this example

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

6. As this is Policy Based we can skip to the Extra Configuration box add the following:

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

You should have something like this:

Now we have an Endpoint we need to add a Tunnel (or encryption domain, subnet pair).

Adding a tunnel

1. Click on Actions on the right hand side and choose New Tunnel

2. We will use the VNET/VPC subnet, the Overlay network will be covered in a future tutorial. Enter the CIDR of the Azure VNET in the “Enter Local subnet box”, mine is 10.2.1.0/24.

3. Enter the CIDR of the AWS VPC in the “Enter remote subnet” box, mine is 172.16.0.0/24.

4. Give your tunnel a description in the “Enter name or description” box

We will skip the ping hosts for now.

Click Create, the tunnel will be added to the Endpoint.

Now expand the endpoint on the IPsec page and we can see our endpoint and tunnel are down and not connected, this is fine as we still need to hop across to our controller in AWS and repeat the process

On the controller in AWS create a new endpoint and tunnel by following the above steps and switch the Azure and AWS IP address settings. 

When you have finished return to the IPsec page and you should see the tunnel is connected, you may have to refresh the page.

If you don’t see connected in green after a few minutes, you can check the tunnel log by clicking on the Tunnel Name to show the details. Then click on “Show Log” to see any log messages or errors. You can check out our forum or contact support@www.cohesive.net if you need help. 

Conclusion

That’s all there is to it! In this simple IPsec guide you have not only setup an IPsec connection but you have created a secure edge using VNS3 and federated two major clouds. 

This is a really powerful use case; from here you can join your on-premise networks into your federated cloud environments using IPsec and TLS/SSL VPNs. 

Which brings me back to our API. If all this pointing and clicking isn’t your thing we have a great tutorial here https://docs.cohesive.net/tutorials/peering-mesh-tf-py/ which uses Terraform and our Python SDK.

Next time we’ll build on this environment and setup a Static Route Based IPsec connection. Until then reach out to contactme@www.cohesive.net if you would like to know more about VNS3.