VNS3 Overlay Network
Overview
The VNS3 Encrypted Overlay Network is an optional feature that provides end-to-end encryption, increased performance (in most cloud environments), and IP address mobility across regions and cloud providers.
The Overlay Network is an essential component of the shared responsibility/trust model when running workloads in a 3rd party controlled environment like a public cloud. Our customers use the Overlay Network to meet and exceed industry regulations like HIPAA, PCI, and NIST Cybersecurity Framework or internal IT requirements when migrating to the cloud.
To deploy the Overlay Network, unique cryptographic X.509 keys (generated on the VNS3 controller) are mapped to specific Overlay Network addresses. These credentials are distributed to the cloud or remote servers and used with a TLS client (like OpenVPN) to create an encrypted connection back to the VNS3 topology. All communication between devices in the Overlay is passed through the VNS3, acting as an encrypted switch. Depending on the use case, communication to remote networks or the public Internet can be routed through VNS3 as well.
YOUR OVERLAY NETWORK RANGE CANNOT OVERLAP WITH THE CLOUD SUBNET/VPC/VNET THE CONTROLLER IS RUNNING IN.
The Overlay Network functionality is optional, but an Overlay Network configuration is required for the VNS3 controller to function. When choosing between the default Overlay Network subnet range or a custom subnet defined by your specific topology needs, avoid any address overlap.
Define an Overlay Network Subnet that does not overlap with:
- cloud VLAN (VPC, VNET, or similar) where the VNS3 controller or cloud clients are running
- datacenter subnets you plan on connecting to via IPsec (however, overlaps can be worked around with cooperation between connecting parties)
Overlay Network Connection Options
Address Considerations
VNS3 provides an encrypted Overlay Network subnet in addition to cloud-provided network access. Cohesive recommends connecting the server to the VNS3 encrypted Overlay Network via SSL Client (OpenVPN) connection using the VNS3 generated Clientpacks. Each Clientpack is tied to a specific Overlay Network Address.
Some clouds offer VLAN capabilities to the user (e.g. AWS VPC, GCE, and Azure). In deployment Environments like these, you have a choice of whether or not to use the Clientpacks. Connections considerations and restrictions are below. In cloud deployments that don’t have VLAN support (e.g. AWS EC2), you MUST use the Overlay Network and Clientpacks.
Restrictions
The VLAN subnet cannot overlap with the VNS3 Overlay Network Subnet.
| VLAN Subnets (eth0) | VNS3 Overlay Network Subnet (tun0) |
|---|---|
| Not Encrypted | Encrypted |
| OpenVPN is not required on Client Servers | OpenVPN is required on Client Servers |
| Clients Packs are not required on Client Servers | Client Packs are required on Client Servers |
| Cannot join generic EC2 directly (public Internet connection required) | Can join generic EC2 services directly (OpenVPN or Peer Controller Required) |
| No Additional Overhead | Additional Overhead (minimal) |
Connecting Client Servers Option 1: Unencrypted VLAN
When using the VLAN isolation only (not in combination with the VNS3 Overlay Network), you will need to add appropriate routing on the client servers in order to use the VNS3 Controller as the gateway or target for the Remote Subnet.
This document shows how to set this up via VPC Routing Tables. If your cloud environment does not have something similar (e.g. HP Routing, GCE Network Routes) you will need to add the appropriate route directly to your VLAN servers.
Click Routing Tables in the left column menu under the VIRTUAL PRIVATE CLOUD section.
Select the Routing Table associated with any and all VPC Subnets created by the VPC Wizard. You can see what subnets are associated with a Routing Table by clicking on the Routing Table and then on the Associations tab in the lower window pane.
Enter the Remote Subnet behind your IPsec device in the Destination field. In our example, we enter 192.168.3.0/24. Select the VNS3 Controller Instance ID as the Target and click Add.
Click Yes, Create on the Create Route popup window.
This change to the Routing Table will allow traffic to be routed through the Controller and down the IPsec tunnel to the datacenter-based remote subnet.
Connecting Client Servers Option 2: Encrypted VNS3 Overlay Subnet
In the context of VNS3, “client” means devices that will be configured as members of the overlay network. These network members will usually be servers running in EC2. In more advanced editions of VNS3, this includes desktop-based client machines. Note the “Client Download” username and password on the Status screen on every Controller (username is “clientpack”).
On any Controller, go to Clientpacks and pick a Clientpack. A Clientpack can run on a single client at a time. If you shut down or disconnect the client from the topology, you can reuse its Clientpack. The number of Clientpacks provided in your license depends on your purchased parameters.
Alternatively, you can use the API to access the Clientpacks. See the VNS3 API documentation for how to use the command line calls get_next_available_clientpack, fetch_clientpack, and edit_clientpack.
Client Configuration: Clientpack Page
VNS3 Clientpacks are unique X.509 credentials created by the VNS3 Controller used to connect client servers to the Overlay Network using the specific Overlay IP addresses you defined during the Controller initialization. The Clientpacks page displays all the available clientpacks in a table displayed below the global options.
Clientpacks are distributed to your client servers and used with TLS client software (OpenVPN, although Wireguard support is under development) to create a virtual network interface and secure TLS VPN tunnel to the VNS3 Controller. The VNS3 Controller then operates as the hybrid network appliance (router, switch, firewall, VPN concentrator, and protocol redistributor) to handle all the Overlay Network traffic and routes.
There are several broad operations at the top of the page, which have an impact beyond the individual operations allowed on each clientpack below via the “Action” menus.
Enable all | Disable all
Selecting one of these options will change the clientpack state for ALL client packs in the topology - even if connected to other controllers.
Extra Clientpack Policies
This allows specific clientpack policies that are not the default to be applied to the configuration file of all clientpacks - on THIS CONTROLLER only. Clientpack policies intentionally do NOT replicate between controllers, allowing distinct control of the configurations per controller. This feature is primarily for organizations doing manual controller configuration as opposed to modifications normally done using Dev Ops / Automation tools.
Show Security Token
NOTE: This value was previously hidden and required Cohesive to recover from a controller. Toggling this link will show the security token/passphrase used when the clientpack generation was done - using the “Generate New” option in the initial controller configuration. This value, combined with cloud security group settings and VNS3 licensing, allows a controller to join this topology.
Clientpack Table
- Clientpack - This is the name of the clientpack. It is the associated Overlay IP address with the “.” Replaced by “_”.
- Status - Displays whether the clientpack is connected to a controller or not.
- Enabled- Displays whether the clientpack is allowed to connect to the controller. If disabled a connection is NOT allowed.
- Checked Out- Displays whether clientpack available or currently being used (checked out). If state is “checked out” this will prevent get_next_available_clientpack API call from offering the clientpack.
Config Files Clientpacks are available as a single configuration file optimized for Linux (vnscubed.conf) and Windows (vnscubed.ovpn). These files have the certificates and keys needed for connecting to the Controller embedded within them.
- Last Connect - Displays the UTC date/time of the last time this clientpack connected to this controller.
- Last Disconnect- Displays the UTC date/time of the last this clientpack disconnected from this controller.
- categories- Tagging lets you keep track of clientpacks based on name/value tagging. Use the “name” value to have the tag displayed on the Runtime Status Page.
Client Configuration: Clientpack Actions
From the Clientpack Page, click on the Action menu for a particular credential to see the available actions that can be taken.
- Checkout - This toggle let you tag a Clientpack as available or being used (checked out) to keep track of the used credentials and to allow or prevent the API get_next_available_clientpack call from fetching a pack that is in use.
- Enabled - This toggle lets you choose to enable or disable the Clientpack. A disabled Clientpack will not be allowed to connect to the Controller.
- categories - Tagging lets you keep track of clientpacks based on name/value tagging. Use the “name” value to have the tag displayed on the Runtime Status Page.
- Regenerate Clientpack - Regenerating the Clientpack allows you to take an old, lost or compromised clientpack and delete the old record and generate a completely new and unique clientpack associated with the same address. This increases the usability of the Overlay Network for road warrior VPNs.
Client Configuration: Clientpack Policies
Clientpack policies are applied to the configuration files on the controller where specified. Changes DO NOT propagate (yet) to already deployed/connected clientpacks.
The customizations are to the client configuration files - not to the server configuration. In this way, we are providing more custom control without potential risk to the server configuration.
### default XXX ### lines are system-needed markers. IF they are there - VNS3 will update the configuration files to use the default inner and outer IP addresses of “eth0” or its equivalent on that controller. If these markers are removed - when this controller’s configuration is imported into a new instance for migration or recovery - there will then be no default addresses. This is useful for some automation use cases.
PROS: This mechanism opens up some of the features for customizing connectivity from clients to the embedded OpenVPN servers used in VNS3 for machine-to-machine encryption.
CONS: The parameters are specific the OpenVPN server, and as such won’t “map” as we add IPsec client support, and Wireguard support for machine-to-machine encryption.
Here are some example use-cases/parameters for clientpack policies. NOTE: all of those are available via clientpack customization upon deployment outside the VNS3 controller and have been used by many customers for years.
float - this value allows you to assign a secondary private IP to the VNS3 “Local Private IP” setting, and allow clientpacks within the same VPC to connect on that private IP alias.
tun-mtu 8192
mssfix 0
fragment 0
This combination of settings raises the default MTU used for clients to 8192 bytes from the standard of 1500 bytes. This is an extreme performance boost in environments like AWS which support Jumbo Frames. Do not use this setting in environments without Jumbo Frames.
remote mydnsname.my.domain 1194 Customers might put the VNS3 controller in their own DNS, Public DNS, Cloud DNS and want to configure clientpacks to use that identifier. This would most likely be combined with removing the “### default” markers from the policy configuration.
dhcp-option DNS 10.x.x.x
dhcp-option DOMAIN mydomain.org
This makes use of the OpenVPN client parameter dhcp-option allowing common network parameters gotten from the network to also be retrieved for use in the encrypted overlay network.
Client Configuration: Firewall
TWO PHILOSOPHIES FOR INSTALLATION
SSH Port 22 Exception Only - Have ssh access into a client server (if only for the duration of installation). Download credentials to your trusted admin machine via the VNS3 Controller “Clientpacks” link. SCP them into the client machines, and then SSH into the client machines to complete the configuration.
Port 22 and Port 8000 Exception - Allow port 8000 and port 22 access as described on the previous pages to a Controller. SSH into the client machine and download the credentials from its command line using the following URL:
curl -k -X GET -H 'Content-Type: application/json' -d '{"name":"<clientpack-name>", "format":"conf"}' https://api:test@<VNS3-Controller-IP>:8000/api/clientpack -o <name-of-file>Something like:
curl -k -X GET -H 'Content-Type: application/json' -d '{"name":"172_16_1_1", "format":"conf"}' https://api:test@12.34.56.78:8000/api/clientpack -o cp2.confNOTE: The VNS3 Controller password is the same default as the UI password and can be changed via the UI or API.
Linux Overlay Client Configuration
You can either install OpenVPN 2.3+ on physical servers or virtual servers you already possess to connect those devices to the VNS3 overlay network.
Extract clientpack contents to /etc/openvpn directory (consult OpenVPN documentation for your OS if not found).
Edit the vnscubed.conf add the Controllers you want this client to connect to in priority at the bottom of the file: remote Controller_DNS_ADDRESS 1194
Use the public DNS URL of the Controller for the remote entry. In multiple Controller topologies, the order of remote commands matters - client will try to connect to the first remote endpoint, if not successful - to the second, and so on. You may want to distribute clients evenly among Controllers by varying the order of “remote” commands on each client.
Start OpenVPN. On Linux OS, this is done using the /etc/init.d/openvpn start command.
Your client will get a virtual IP address that corresponds to the clientpack it received.
WARNING: If you accidentally give the same client credentials to 2 different devices, you will notice the two clients popping off and on the overlay network inside the VNS3 Controller Status screen. Only one device can have a set of credentials in the same topology at a time.
Adjust local firewall on the client if necessary (on Linux, your tunnel device name will be tun0). Verify connectivity by pinging 172.31.3.1, 172.31.3.2 (the IPs we setup for our Controllers on page 15) for Controller MGR1 and MGR2, respectively. Usually, the Controller whose “remote” line appears first in /etc/openvpn/vnscubed.conf will be pingable first, other Controllers will become pingable once they learn about new client.
Windows Overlay Client Configuration
RDP into the Windows Machine using the Administrator credentials specified when launching the server.
Navigate to https://your-controller-ip:8000 in IE.
Login using the default vnscubed for the password and username or the password you changed on your first login.
Click Clientpacks on the left menu.
Download the appropriate Clientpack zip file to the Windows machine.
Install OpenVPN 2.3+ on physical servers or virtual servers you already possess to connect those devices to the VNS3 overlay network. On Vista you will need to have admin privileges to install the software.
You will have to install a Clientpack on the Windows desktop machine and put the Clientpack files in \Program Files\OpenVpn\config\
RENAME vnscubed.conf to vnscubed.ovpn !!!!
Edit the vnscubed.ovpn and add the Controllers you want this client to connect to in priority at the bottom of the file: remote Controller_DNS_ADDRESS 1194
Use the public DNS URL of the Controller for the remote entry. In multiple Controller topologies, the order of remote commands matters - the client will try to connect to the first remote endpoint, if not successful - to the second, and so on. You may want to distribute clients evenly among Controllers by varying the order of “remote” commands on each client.
Start OpenVPN.
Your client will get a virtual IP address that corresponds to the clientpack it received. WARNING: If you accidentally give the same client credentials to 2 different devices you will notice the two clients popping off and on the overlay network inside the VNS3 Controller Status screen. Only one device can have a set of credentials in the same topology at a time.
Adjust the local firewall on the client if necessary.
Verify connectivity by pinging 172.31.10.1 or 172.31.10.2 (the IPs we setup for our Controllers on page 16) for Controller ID1, ID2,respectively. Usually, the Controller whose “remote” line appears first in /etc/openvpn/vnscubed.conf will be pingable first, other Controllers will become pingable once they learn about new client.
When setting up OpenVPN as a Service on Windows2008 there can be an issue with the machine resolving IPv6 instead of IPv4. Follow the steps below to fix the problem.
- Go to “regedit”
- Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters
- Double-click the ArpRetryCount value, type 0, and then click OK. If it does not exist create a new REG_DWORD, rename to ArpRetryCount, and set the value to 0.
- Reboot the machine