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.