Running in AWS
Introduction
This guide describes the basic steps to setup an AWS VPC where you plan on running a VNS3 controller and AWS instances for your cloud use-case. A simple deployment scenario is presented with some best practice pointers. For more complex deployments please open a support ticket via the Cohesive Networks Support Site or email to support@cohesive.net.
Requirements
You have an AWS account that Cohesive can use for enabling your access to the VNS3 Controller AMIs (via DevPay, AWS Marketplace, or private Image permissions).
In order to be interoperable with other data centers via IPsec, VNS3 supports a wide range of systems and standards.
Preferred: Most models from Cisco Systems*, Juniper, Watchguard, Dell SONICWALL, Netgear, Fortinet, Barracuda Networks, Check Point*, Zyxel USA, McAfee Retail, Citrix Systems, Hewlett Packard, D-Link, WatchGuard, Palo Alto Networks, OpenSwan, pfSense, and Vyatta.
Best Effort: Any IPsec device that supports: IKE1 or IKE2, AES256 or AES128 or 3DES, SHA1 or MD5, and most importantly NAT-Traversal standards.
Known Exclusions: Checkpoint R65-R80 require native IPSec connections as Checkpoint does not conform to NAT-Traversal Standards in these versions. In Checkpoint R80+, GuiDBedit must be used to force either native IPsec or NAT-T in order to maintain a reliable connection. (See https://support.cohesive.net/support/solutions/articles/31000156433-nat-t-compatibility-with-check-point-devices)
Cisco ASA 8.4(2)-8.4(any) bugs prevent a stable connection from being maintained.
Firewall Setup
VNS3 Controller instances use the following TCP and UDP ports, they are allowed by default in the controller’s internal firewall, and cloud security groups should be set accordingly:
- UDP port 1194 - (OpenVPN-based overlay networks) For client VPN connections; must be accessible from all servers that will join VNS3 topology as clients.
- UDP port 51820 - (Wireguard-based overlay networks) For client VPN connections; must be accessible from all devices that will join VNS3 topology as clients.
- UDP 1195-1203 (OpenVPN-based peering network in versions 5.x or earlier) - For tunnels between Controller peers; must be accessible from all peers in a given topology. VNS3 Free and VNS3 Lite Edition will not require UDP ports 1195-1197 access as they are not licensed for Controller Peering.
- UDP 1201-1208 (Wireguard-based peering network in versions 6.x or later) - For encrypted peering tunnels between Controller peers; must be accessible from all peers in a given topology. VNS3 Free and VNS3 Lite Edition will not require UDP ports 1201 -1208 access as they are not licensed for Controller Peering.
- TCP port 8000 - HTTPS admin interface and API; must be accessible from hosts where you will want to obtain runtime status or configure peering, also needs to be open to and from the Controllers at least for the peering process, and needs to be accessible when downloading credentials for installation on overlay network clients.
- UDP port 500 - UDP port 500 is used for the phase 1 or IKE (Internet Key Exchange) component of an IPsec VPN connection.
- Protocol 50 - This is used for the phase 2 or ESP (Encapsulated Security Payload) component of an IPsec VPN connection only when negotiating with native IPsec.
- UDP port 4500 - This is used for the phase 2 or ESP (Encapsulated Security Payload) component of an IPsec VPN connection when using NAT-Traversal Encapsulation.
- TCP ports 80 and 443 - The internal firewall of VNS3 initially allows these ports to help customers who don’t realize the VNS3 UI and API runs on port 8000, to receive a redirect. PLEASE DISABLE THESE PORTS, ideally in BOTH the VNS3 firewall (INPUT -p tcp –dports 80,443 -j DROP) and in the cloud security groups.
Address Considerations
VNS3 requires an Overlay Network subnet to be specified as part of the configuration process. Use of the Overlay Network is optional but provides improvements in security, address mobility, and performance. Your VPC CIDR and Subnets cannot not overlap with the VNS3 Overlay Network Subnet.
AWS VPC does allow virtual machine instances to act as networks gateways for unencrypted VPC traffic. Routing traffic from the unencrypted VPC instead of using the encrypted Overlay Network requires configuring the AWS Routing Tables and disabling the Source/Destination Check on the VNS3 instance.
See the unencrypted VPC section at the end of the document for more details on configuration.
Step 1: VPC Deployment Setup
Virtual Network Addressing - Don’t Overlap with VNS3 Overlay
AWS VPCs provide an isolated address space within the Amazon cloud where you run your instances. VPCs allow you to define Subnet address spaces, and associated Security Groups/ACLs allow control of access control policies via the hypervisor firewall.
Cohesive Networks recommends creating a separate VPC Subnet for the VNS3 Controllers that is different from the subnet or subnets defined for the application instances.
Cohesive Networks typically recommends configuring a small subnet at the top of the VPC CIDR for the VNS3 Controller(s). You can then logically segment the lower part of the subnet for your application instances in a single subnet or multiple subnets per instance role (e.g. web server, app server, db, etc.)
| The diagram shows a recommended segmentation of a /24 (255 addresses) VPC for this example deployment. Cohesive Networks typically recommends configuring a small subnet at the top of the VPC CIDR for the VNS3 Controller(s). You can then logically segment the lower part of the subnet for your application instances in a single subnet or multiple subnets per instance role (e.g. web server, app server, db, etc.) |  |
Create a VPC From the VPC Wizard
Create a VPC from the VPC tab at the top of the AWS Console.
Click Start VPC Wizard or Click Get Started in your VPC Dashboard.
Choose either VPC with a Single Public Subnet Only or VPC with Public and Private Subnets. The other two choices will not work with VNS3.
For this example we choose VPC with a Single Public Subnet Only.
You can leave the default values in for the VPC CIDR and VPC Subnet or edit them to fit your addressing requirements. For this example we use 10.10.10.0/24 for the VPC CIDR and 10.10.10.240/28 for the Public Subnet.
Remember the VPC CIDR and VPC Subnets must not overlap with the VNS3 Overlay Network Subnet.
Click Create VPC.
The VPC Wizard creates the VPC, the Subnet, Network ACL, Internet Gateway, 2 Routing Tables, and a Security Group.
Inbound and Outbound VPC ACL Setup
Click Network ACLs in the left column menu under the SECURITY section.
Select the ACL created by the VPC Wizard.
The default settings allow all ports on all protocols from all destinations for both inbound and outbound connections. This due to our selection of a Public Subnet when setting up the VPC. It is recommended you leave the ACLs open during initial configuration of your deployment. Once all connections are established and tested you can lock down the ACL based on the Firewall Considerations outlined on page 7 by deleting the default Rule #100 and adding specific ALLOW rules.
VPC Security Group Setup Option 1: Default Group
Configure Security Groups from the VPC AWS Console.
Click Security Groups in the left column menu under the SECURITY section. Select the Security Group created by the VPC Wizard.
The default settings allow inbound connections on all ports from servers launched in the VPC security group and allow outbound connections on all ports to all routes (0.0.0.0/0). Again, this due to our selection of a Public Subnet when setting up the VPC. It is your choice to leave the default Outgoing rules or modify based on your use case.
From the Inbound tab, click Edit to update the following exceptions:
- TCP port 8000 from your public IP (you can find your IP address by navigating to http://whatismyip.com)
- UDP port 500 from the IP of your Datacenter-based IPsec Device
- Custom Protocol Rule for ESP (50) from IP of your Datacenter-based IPsec Device
Optional Inbound Exceptions:
- UDP port 4500 from the IP of your Datacenter-based IPsec Device (only required if you will use NAT-Traversal encapsulation)
- TCP port 8000 from the Elastic IP of the Controller in the other VPC deployment (only required for deployments across multiple VPCs or between VPC and EC2)
- UDP ports 1195-1197 from the Elastic IP of the Controller in the other VPC deployment or EC2 (only required for deployments across multiple VPCs or between VPC and EC2)
Click Save.
VPC Security Group Setup Option 2: Multiple Security Groups
An alternative to just using the default security group setup by the VPC wizard is to separate the Controllers from the Client Servers. To do this we recommend creating two groups inside the already created VPC: vns3-mgr and vns3-client. Note: no rules are needed in the vns3-client group by default.
Select the vns3-mgr group to Edit the following inbound exceptions:
- TCP port 8000 from your public IP
You can find your IP address by navigating to whatismyip.com - TCP port 8000 from the vns3-mgr Security Group ID (for Peering if needed)
- UDP port 1195-1197 from the vns3-mgr Security Group ID (for Peering if needed)
- UDP port 500 from the IP of your Datacenter-based IPsec Device
- Custom Protocol Rule for ESP/Protocol 50 from the IP of your Datacenter-based IPsec Device Optional Inbound Exceptions:
- UDP port 1194 from the vns3-client Security Group ID if you plan on using the Overlay Network (see page 6).
- UDP ports 1195-1197 from the Elastic IP of the Controller in the other VPC deployment (required for peering) if you are deploying the Overlay Network across multiple VPCs.
- UDP port 4500 from the IP of your Datacenter-based IPsec Device if you plan on using NAT-Traversal encapsulation for your IPsec connection. In this guide we disable NATTraversal on the Controller.
Click Apply Rule Changes.
Step 2: Launching a VNS3 Controller Instance
Launch a VNS3 Controller
Switch to the EC2 tab at the top of the AWS Console.
Click AMIs in the left column menu under the IMAGES section.
Launch a VNS3 instance using the AMI ID supplied by Cohesive.
Be sure to launch the Instance in the VPC and the VPC security group that was created using the VPC Wizard.
Create a VPC Specific Elastic IP and Assign to the Controller Instance
Switch back to the VPC tab at the top of the AWS Console.
Click Elastic IPs in the left column menu under the Network & Security section.
Click Allocate New Address and select the Elastic IP be used in VPC.
Click Yes, Allocate. Click Close.
Associate the Elastic IP Address with your VNS3 Controller Instance by clicking Associate Address.
Select your VNS3 Controller Instance and click Yes, Associate.
Associating an Elastic IP with your VNS3 Controller Instance will make the instance publicly available so you can log into the Controller Web UI to configure your Overlay Network and setup IPsec connections.
Repeat steps outlined on pages 9-14 to create a second VPC deployment. We recommend using different VPC CIDR for each VPC deployment.
Unencrypted VPC Setup
Unencrypted VLAN Setup
In the event you choose to not use the Overlay Network, there are some additional steps required to allow VNS3 to act as the gateway for the VPC Subnet(s).
Remember even if you decide not to use the Overlay Network, you still need to define an Overlay Network address space as part of the initialization. Be sure to choose an address space that DOES NOT overlap with the Azure Virtual Network CIDR or remote network you plan on connecting to via IPsec VPN.
You will need to make changes to the VPC Routing Tables, add appropriate Security Group Rules and disable Source/Destination Check for the VNS3 controller instance.
AWS Route Table Rule
AWS Route Tables need to be configured so the instances running various VPC Subnets will send traffic destined for remote subnets connected to the VNS3 controller via IPsec to the VNS3 controller instead of the IGW or NAT AMI.
In this example we assume there is an IPsec tunnel connected to VNS3 that allows connectivity between the local VPC CIDR of 10.10.10.0/24 and a remote subnet 172.16.0.0/24.
Click Route Tables on the VPC left column menu.
Either add a route to an existing Route Table or create new.
Click Routes.
Click Edit.
Click Add another route.
Enter the remote subnet (our example uses 172.16.0.0/24) as the Destination, and the VNS3 controller instance ID as the Target. Click Save.
Next make sure the Route Table is associated with the appropriate Subnet where the Application Server instances are running (10.10.10.0/25 from our example on page 12).
Click Route Associations.
Click Edit.
Select the appropriate Subnet form the list and click Save.
AWS Security Group Rules
In order for the Application Server instances to send traffic through the VNS3 controller over the unencrypted VPC, Security Group rules need to be added to allow the traffic to flow.
As Security Groups are stateful, you only need to open Inbound rules in the direction of the initiating traffic as all response traffic will be allowed.
In this example we show opening up All Traffic between the VNS3 Controller instance Security Group and Application Server instance security group via the Security Group IDs.
Disable Source/Destination Check on the Controller Instance
Once the Controller Instance is launched, you will need to disable the Source/Destination check on the instance. This step is required so the Controller instance is allowed to forward packets to the client servers. If this is not disabled the Controller will not be able to route traffic appropriately.
To Disable select the Controller Instance the click Instance Actions.
Click Change Source/Dest. Check.
Click Yes, Disable.
Logging in
- VNS3 Web UI - https://VNS3-ip:8000 (e.g. https://123.123.123.623:8000)
- Default UI username - vnscubed
- Default UI password - instance id (e.g. i-0d9098dc28f8229b)