AWS VPC Cloud Environment Setup

©2018

Table of Contents

2

Introduction 3Requirements 5Step 1: VPC Deployment Setup 11Step 2: Launching a VNS3 Controller Instance

17Unencrypted VPC Setup 20VNS3 Configuration Document Links 25

©2018

Introduction

3

7 ©2018

Introduction

4

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@coheisve.net.

VNS3 is an Appliance as a Service that provides network security and connectivity - Security Appliance, Application Delivery Controller and Unified Thread Management all rolled into one - to your cloud-based applications.

=+ +UTM

unified threat management

ADCapplication

delivery controller

SA

security appliance

VNS3

©2018

Requirements

5

©2018

Requirements

6

• 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).

• 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. *Known Exclusions  Checkpoint R65+ requires native IPSec connections as Checkpoint does not conform to NAT-Traversal Standards and Cisco ASA 8.4(2)-8.4(any) bugs prevent a stable connection from being maintained.

©2018

Getting Help with VNS3

7

Support for VNS3 is provided through the Cohesive Networks Support Site according to our Support Plans.

We recommend reviewing the Support Site FAQs and this document before opening a support ticket.

If you need more information on how to setup a specific cloud environment or prefer video instructions, please see our Product Resources page for additional links.

If you need specific help with project planning, POCs, or audits, contact our professional services team via sales@cohesive.net for details.

©2018

Firewall Considerations

8

VNS3 Controller instances use the following TCP and UDP ports:

• UDP port 1194 For client VPN connections; must be accessible from all servers that will join VNS3 topology as clients.

• UDP 1195-1203For tunnels between Controller peers; must be accessible from all peers in a given topology. VNS3:vpn and VNS3:net Lite Edition will not require UDP ports 1195-1197 access as it is not licensed for Controller Peering.

• TCP port 8000 HTTPS admin interface; 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 500UDP port 500 is used for the phase 1 or IKE (Internet Key Exchange) component of an IPsec VPN connection.

• ESP Protocol 50 and possibly UDP port 4500Protocol 50 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* is used for the phase 2 or ESP (Encapsulated Security Payload) component of an IPsec VPN connection when using NAT-Traversal Encapsulation.

*AWS VPC allows Protocol 50 past its edge.

© 2018

Address Considerations

9

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.

©2018

Remote Support

10

Note that TCP 22 (ssh) is not required for normal operation.

Each VNS3 Controller is running a restricted SSH daemon, with access limited only to Cohesive for debugging purposes controlled by the user via the Remote Support toggle and key exchange generation.

In the event Cohesive needs to observe runtime state of a VNS3 Controller in response to a tech support request, we will ask you to open Security Group access to SSH from our support IP range and Enable Remote Support via the Web UI.

Cohesive will send you an encrypted passphrase to generate a private key used by Cohesive Support staff to access your Controller. Access to the restricted SSH daemon is completely controlled by the user. Once the support ticket has been closed, you can disable remote support access and invalidate the access key.

©2018

Step 1: VPC Deployment Setup

11

©2018

Virtual Network Addressing - Don't Overlap with VNS3 Overlay

12

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.

NOTE: The VPC CIDR you configure CANNOT overlap with the VNS3 Overlay Network you create during initialization/configuration of your VNS3 Controller instance.

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 at the right shows recommended segmentation of a /24 (255 addresses) VPC for this example deployment.

open

open

open

application 10.10.10.0/25

10.10.10.128/26

10.10.10.192/27

10.10.10.224/28

VPC CIDR 10.10.10.0/24

VNS3 10.10.10.240/28

©2018

Create a VPC From the VPC Wizard

13

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.

Note: More complex VPC deployments can be set up (more than one VPC Subnet inside a VPC CIDR) but the VNS3 Controller must be launched in a Public VPC Subnet.

©2018

Inbound and Outbound VPC ACL Setup

14

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.

©2018

VPC Security Group Setup Option 1: Default Group

15

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.

©2018

VPC Security Group Setup Option 2: Multiple Security Groups

16

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 http://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 NAT-Traversal on the Controller.

Click Apply Rule Changes.

©2018

Step 2: Launching a VNS3 Controller Instance

17

©2018

Launch a VNS3 Controller

18

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.

NOTE: On Step 3: Configure Instance Details, in the Launch Wizard you can specify a particular IP Address for the Controller Instance on the VPC Subnet that was created using the VPC Wizard. AWS will automatically assign an IP inside the VPC Subnet if this field is left blank (as we did for this example).

©2018

Create a VPC Specific Elastic IP and Assign to the Controller Instance

19

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.

©2018

Unencrypted VPC Setup

20

©2018

Unencrypted VLAN Setup

21

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.

©2018

AWS Route Table Rule

22

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.

©2018

AWS Security Group Rules

23

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.

©2018

Disable Source/Destination Check on the Controller Instance

24

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.

©2018

VNS3 Configuration Document Links

25

©2018

VNS3 Configuration Document Links

26

VNS3 Product Resources - Documentation | Add-ons

VNS3 Configuration Instructions (Free and Lite Editions | BYOL)Instructions and screenshots for configuring a VNS3 Controller in a single or multiple Controller topology. Specific steps include, initializing a new Controller, generating clientpack keys, setting up peering, building IPsec tunnels, and connecting client servers to the Overlay Network.

VNS3 Administration Document Covers the administration and operation of a configured VNS3 Controller. Additional detail is provided around the VNS3 Firewall, all administration menu items, upgrade licenses, other routes and SNMP traps.

VNS3 Container InstructionsExplains the value of the VNS3 3.5 Docker integration and covers uploading, allocating and exporting application containers.

VNS3 Troubleshooting Troubleshooting document that provides explanation issues that are more commonly experienced with VNS3.