Running in Google Cloud
Introduction
This guide describes the basic steps to create a VNS3 Image and setup a VPC where you plan on running a VNS3 controller and GCE 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 a GCE account that Cohesive can use for enabling your access to the VNS3 Controller Images (GCE Marketplace coming soon).
Ability to configure a client (whether desktop based or cloud based) to use OpenVPN 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 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
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. Warning: Your overlay network range cannot overlap with the cloud subnet/vpc/vnet the controller is running in.
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 you plan on connecting to via IPsec (however overlaps can be worked around with cooperation between connecting parties)
VNS3 Image Sharing via Compute Image User IAM
Cohesive Networks provides access to VNS3 Images via IAM sharing.
In order to share, Cohesive Networks Support needs the email address associated with the Google Cloud Platform account where you will run the VNS3 controller.
VNS3 SKUs (Free, Lite, and BYOL) will be available in the Google Cloud Marketplace in 2019.
Step 1: VPC Deployment Setup
Virtual Network Addressing - Don’t Overlap with VNS3 Overlay
Google VPCs provide an isolated address space where you run your instances. VPCs allow you to define Subnet address spaces, and associated Firewall Rules to 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 VPC Network
This guide shows how to create a VPC Network and launch a VNS3 Controller instance inside that network. If you already have an existing VPC, we recommend launching in a separate subnet for maximum flexibility and security.
To create a new VPC Network, navigate to the VPC Network console via the Google Cloud Platform left column menu.
Click on VPC networks.
Then click on Create VPC Network.
The Create VPC Network pane allows you to customize your cloud VLAN to your application’s specifications. This guide follows the network address scheme example provided above.
Provide the following information:
- Name
- Description (optional)
- Subnets - in this example we create a subnet for the VNS3 controller and a subnet for the application servers in the same subnet. More complex application use-cases may require additional subnets and regions.
Click Create.
Google Cloud Firewall Rules
Google Cloud Firewall Rules are stateful hypervisor rules that are applied at the network level.
Default/Implied rules allow all outbound (egress) traffic from a VPC instance and deny all inbound (ingress).
The following pages provide steps to open up inbound access to the controller to allow the various network and security functions.
To create a new Firewall Rule, navigate to the VPC Network console via the Google Cloud Platform left column menu.
Click Firewall Rules.
Firewall Rules: VNS3 UI/API
In order to access the VNS3 controller via the UI or API, TCP port 8000 inbound access needs to be allowed via the Firewall Rules.
Click create Firewall Rule.
Create a Firewall Rule with the following relevant information:
- Network: VPC created on page 15, in this example application-vpc
- Direction of traffic: Ingress
- Action on match: Allow
- Targets: this example uses target tags to associate this firewall rule with an instance or instances. Tags applied during instance creation that match with the Firewall Rule tags will associate the Firewall Rule with the instance.
- Target tags: this example uses vns3.
- Source Filter: this example uses IP ranges to specify the source of the traffic to be allowed.
- Source IP ranges: the IP or limited set of IPs where you will be managing the VNS3 controller.
- Specified Protocols and Ports: TCP 8000
Click Create.
Firewall Rules: IPsec
In order to create IPsec tunnels to the VNS3 controller UDP 500, UDP 4500 (for NATTraversal) and/or ESP protocol 50 (for native IPsec) inbound access needs to be allowed via the Firewall Rules.
Click create Firewall Rule.
Create a Firewall Rule with the following relevant information:
- Network: VPC created on page 15, in this example application-vpc
- Direction of traffic: Ingress
- Action on match: Allow
- Targets: this example uses target tags to associate this firewall rule with an instance or instances. Tags applied during instance creation that match with the Firewall Rule tags will associate the Firewall Rule with the instance.
- Target tags: this example uses vns3.
- Source Filter: this example uses IP ranges to specify the source of the traffic to be allowed.
- Source IP ranges: the IP(s) of the remote VPN devices that will be connecting to VNS3 via IPsec VPN.
- Specified Protocols and Ports: UDP 500, UDP 4500, and/or ESP protocol
Click Create.
Firewall Rules: Overlay Network
The VNS3 Overlay Network is optional. If you plan on taking advantage of the speed, flexibility and security of the Overlay Network UDP 1194 inbound access needs to be allowed via the Firewall Rules.
Click create Firewall Rule.
Create a Firewall Rule with the following relevant information:
- Network: VPC created on page 15, in this example application-vpc
- Direction of traffic: Ingress
- Action on match: Allow
- Targets: this example uses target tags to associate this firewall rule with an instance or instances. Tags applied during instance creation that match with the Firewall Rule tags will associate the Firewall Rule with the instance.
- Target tags: this example uses vns3.
- Source Filter: this example uses IP ranges to specify the source of the traffic to be allowed.
- Source IP ranges: 0.0.0.0/0 or a smaller subnet depending on where the overlay connected clients are running.
- Specified Protocols and Ports: UDP 500, UDP 4500, and/or ESP protocol
Click Create.
Firewall Rules: VNS3 Peering
Premium subscriptions of VNS3 (SME and larger) allow for more than on VNS3 controller to be peer together in a mesh to provide HA and federation capabilities. If you plan on building a peered VNS3 mesh UDP 1195-1210 (potentially smaller range depending on the number of peer controllers) needs to be allowed via the Firewall Rules.
Click create Firewall Rule.
Create a Firewall Rule with the following relevant information:
- Network: VPC created on page 15, in this example application-vpc
- Direction of traffic: Ingress
- Action on match: Allow
- Targets: this example uses target tags to associate this firewall rule with an instance or instances. Tags applied during instance creation that match with the Firewall Rule tags will associate the Firewall Rule with the instance.
- Target tags: this example uses vns3.
- Source Filter: this example uses target tags.
- Source IP ranges: this example uses vns3
- Specified Protocols and Ports: UDP 1195-1210
Click Create.
Step 2: Creating a VNS3 Controller Instance
Create a static IP for use when launching the VNS3 instance
Cohesive Networks highly recommends creating then associating a static public IP with any VNS3 controller instance launched in the cloud for maximum flexibility and recovery.
To create a static Public IP, navigate to the VPC Network console via the Google Cloud Platform left column menu.
Click External IP addresses.
Create an External IP address in the same region as the VPC Network created on page 15.
Click Reserve.
Create a VNS3 Controller Instance
To create a VNS3 Controller instance, navigate to the Compute Engine console via the Google Cloud Platform left column menu.
Click VM Instances.
Click Create.
In order to create a VNS3 Controller instance you will need to specify the vns3 image shared to your account by Cohesive Networks as described previously.
To specify the shared VNS3 image, click Change under Boot Disk.
On the resulting popup, click on Custom Images.
Select the Cohesive Networks - dev project from the dropdown.
And select the image name provided by Cohesive Networks.
Launch a VNS3 Controller
Click the Management, security, disks, networking, sole tenancy dropdown to reveal additional configuration parameters.
Click on Networking.
If you are using Network tags for Firewall Rule association (as this example is), enter the appropriate tag.
Edit the Network interface and specify the correct VPC.
Turn IP forwarding On if needed (see page 27). NOTE: This setting cannot be updated after the instance has been created.
Click Done.
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 is the instance-id gotten from the Google Portal as seen in the graphic of the instance screen below.
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 Google VPC Subnet CIDR or remote network(s) you plan on connecting to via IPsec VPN.
You will need to make changes to the Routing Tables, add appropriate Firewall Rules and enabled IP Forwarding for the VNS3 controller instance.
Unencrypted VLAN Setup: Routes
Google Cloud Route 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 default Internet Gateway.
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.
To create a new Route, navigate to the VPC Network console via the Google Cloud Platform left column menu.
Click Routes.
Enter the appropriate destination IP range and specify the Next Hop as the VNS3 controller instance.
Click Create.
Unencrypted VLAN Setup: Firewall 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.