Running in Azure
Introduction
This guide describes the basic steps to create a VNS3 Image and setup a VNET where you plan on running a VNS3 controller and Azure 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 Azure account Click here for a Free Azure trial
You have the ability to configure a client (whether desktop based or cloud based) to use the OpenVPN TLS VPN client software.
You have a compliant IPsec firewall/router networking device:
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 devices 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.
*Azure allows Protocol 50 past its edge, but at the time of this document’s publication, the network security group configuration requires all protocols to be open between a specific source IP and the VNS3 controller NIC/Subnet.
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 VLAN CIDR and Subnets cannot not overlap with the VNS3 Overlay Network Subnet.
The Azure cloud does allow virtual machine instances to act as networks gateways for unencrypted VLAN traffic. Routing traffic from the unencrypted Azure VLAN instead of using the encrypted Overlay Network requires configuring the Azure Route Tables and enabling IP Forwarding. The Route Tables are configurable via Powershell, Azure CLI, and Azure UI. IP Forwarding is configurable via Powershell only.
See the VLAN traffic section at the end of the document for more details.
Virtual Network Addressing - Don’t Overlap with VNS3 Overlay
Microsoft Virtual Networks provide an isolated address space within the Azure cloud where you run your VMs. Virtual Networks allow you to define address spaces, and associated Network Security Groups allow control of access control policies via the hypervisor firewall.
Cohesive Networks recommends creating a separate Virtual Network Subnet for the VNS3 Controllers that is different from the subnet or subnets defined for the application VMs
Cohesive Networks typically recommends configuring a small subnet at the top of the Virtual Network range for the VNS3 Controller(s). You can then logically segment the lower part of the subnet for your application VMs in a single subnet or multiple subnets per VM 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.) |  |
Launch VNS3
From External Azure Marketplace
VNS3 Free and Lite Edition virtual machine images are available in the Azure Marketplace. To launch from the Marketplace page: Latest VNS3
Click Get it Now. You will be instructed to login.
From the popup, select the VNS3 Edition and click Continue. For access to a private unlicensed VNS3 VM, contact our support team.
You’ll be redirected to the Azure Portal. Click Create.
From Inside Azure Portal
VNS3 Free and Lite Edition virtual machine images are available in the Azure Marketplace. You can search for VNS3 or launch from the Marketplace page:
In the resulting window pane, type VNS3 to see all VNS3 Marketplace offerings. For access to a private unlicensed VNS3 VM, contact our support team.
Click on the VNS3 Edition and click Create.
Confirm VNS3 Image
On the resulting product description window pane, there is information about the VNS3 product line, benefits, and resources.
Make sure the Resource Manager is selected for the deployment model (this option is not available for new Azure accounts - they are all Resource Manager accounts).
Click Create.
1. Configure Basics
On the resulting Basics window pane, name your VNS3 VM. Spaces are not allowed, so use hyphens to separate the words of an instance name.
Choose Standard (HDD) or Premium (SSD) disk type. This is impact your size and storage costs on Azure. We recommend HDD.
The Azure portal requires a username and an SSH key or password. Regardless of your entry, Cohesive Networks does not provide shell access to customers for VNS3 appliances.
These entries are required, but will not be used.
Add the the VM to your existing Resource Group.
Click Next.
2. Configure Disks
On the resulting Disks window pane, choose disk size.
VNS3 should have at least one core and 1.5GB of memory, so the “A2 Basic” instance type is a good place to start. Depending on need, VNS3 can be run as a very large instance to provide more throughput for the virtual network, site-to-site connections, firewall rules, or other network functions.
Click Next.
3. Configure Network
Create a new Virtual Network, here we use 10.10.10.0/24.
Also create new Subnet, here we use 10.10.10.240 / 28. Click OK.
Next, create a new Public IP address. Select Static. Click OK.
Create a new Network Security group. 2 defaults may appear:
- Edit and keep TCP 8000 from Internet
- Delete SSH 22 access from all
- Add other optional rules. See page 6 for rules and details.
Click Next.
4. Review and Create
Review the settings on the Summary window pane.
Click Create.
Logging in
- VNS3 Web UI - https://VNS3-ip:8000 (e.g. https://123.123.123.623:8000)
- Default UI username - vnscubed
- Default UI password - In legacy versions prior to 4.4.0, the default password in Azure is “vnscubed”
- In 4.5+ the default password is now derived from instance name and private ip: “azure instance name-azure private ip”. For example, if the Azure instance name is “my-vns3” and the private VNET IP is “10.0.0.9”, the password is “my-vns3-10.0.0.9”. We do this because the Azure portal does not make the virtual instance ID readily visible. For more information: https://docs.cohesive.net/tutorials/getting-started/
Optional Set Up: VNS3 Unencrypted VLAN 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 Azure Virtual Network 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 create a Azure Route Table and enable IP Forwarding for the VNS3 controller VM.
Create a Route Table
Click Route Tables in the Left Column Menu and click Add.
In the resulting Create route table window pane, enter a name and select the resource group previously created.
Click Create.
Once created click on the Route Table, then All Settings.
Click on Routes.
On the resulting Routes window pane, click Add.
In the resulting Add route window pane, enter a Route Name, Address prefix (the remote network you will connect to via VNS3 IPsec tunnel), Set Next hop type as Virtual appliance, and enter the VNS3 controller Azure private IP address as the Next hop address.
Click Save.
Enable IP Forwarding for the VNS3 VM
Enabling IP Forwarding allows the VNS3 controller VM to pass traffic where it is neither the source or the destination of the packet. It allows VNS3 to act as a gateway.
At the time of this document’s publication, IP Forwarding is only controllable via PowerShell. The link to the Azure documentation for IP Forwarding is below.