In part I of our NATe post we discussed economic advantages to replacing your AWS NAT Gateways with Cohesive Networks...
IPSec with VNS3: Part I
Internet Protocol Security (IPSec) is used to encrypt communications between two computers over the internet. Usually it is done between between security gateways to allow two networks to communicate securely. On the data center side this will be done for the most part on physical boxes manufactured by the likes of Cisco, Juniper, Fortinet and others. In the public cloud it is virtualized. Cohesive Networks VNS3 is one such device that allows you to easily configure these secure connections into your cloud private network. Whether you are running a hybrid cloud, are an ISV that needs to connect to customer sites or are implementing a multi cloud strategy VNS3 can provide a stable, secure and simple solution.
VNS3 can manage as many IPSec connections as you need, the only limit is the underlying instance resources. You can scale your VNS3 instance with the number of connections. It supports both policy and route based connections and supports a wide range of algorithms, hashes and Diffie-Hellman groups. In short, VNS3 can connect to just about anything out there. It’s highly configurable design lets you match exactly what it is communicating with. This all makes VNS3 a very stable solution.
Setting up VNS3 is a breeze. You can launch it out of your cloud vendor’s marketplace and pay by the hour, or contact Cohesive Networks for longer term billing. VNS3 should be placed into a public subnet. Once launched you will need to either in AWS, turn off source destination checking, or in Azure, enable IP Forwarding on its network interface. In AWS you should attach an Elastic IP (EIP) to it or in Azure a Public IP Address. Once it is up you can manage it via its web interface. You will need to open up TCP port 8000 in your security group. Then open a browser and go to:
The default admin username is: vnscubed
In AWS the default password is the instance id, in Azure the default password will be the virtual machine name followed by a hyphen then the private ip (ex. MyVNS3-10.0.0.1)
Once you have logged in you should change the admin and api passwords.
The IPSec configuration page can be found under the Connections section on the left hand side contextual menu. From there you will want to click on the “New Endpoint” button and will see the IPSec configuration form.
Now it is just a matter of filling in the parameters for the endpoint you will communicate with. Typically you and the other party will agree upon a set of algorithms, hashes and dh groups as well as NAT-T or native IPSec and IKEv1 or IKEV2. While VNS3 does a good job of auto discovery it is best to make sure that both sides are explicitly the same. We provide a simple syntax for VNS3. An example might look like:
VNS3 simplifies this process by putting all of your configuration on a single page.
If you are creating a policy based IPSec connection you will next need to create individual tunnels for your connection. This is done after the creation of the initial endpoint. After the endpoint is created you can create a “New tunnel” from the action drop down to the right of your endpoint. This will be your local subnet and then the subnet on the other side of the connection that you will be communicating with.
With route based IPSec we support both Virtual Tunnel Interface (VTI) and over GRE, useful for sending multicast packets. If you are utilizing a VTI route based IPSec VPN you next want to set up a “New eBGP Peer” from the action drop down.
Your IPSec configuration should now show as connected.
In the next parts in this blog series we will dive into the tools we provide to troubleshoot a faulty connection, interesting things you can do with our firewall to transform the tunnel traffic, and some plugins we use to solve common problems.