VNS3 3.0.4 Free, Lite, SME and Enterprise Edition for CloudSigma

copyright 2013

VNS3 3.xConfiguration InstructionsCloudSigma Deployments for Free, Lite, SME, and Enterprise Editions2013

1Tuesday, November 26, 13

copyright 2013

Requirements• You have a CloudSigma account.

• You have agreed to the terms of service provided for the VNS3 Manager Images available in the image catalog listing detail.

• 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(4) bugs prevent a stable connection from being maintained.


copyright 2013

Getting Help with VNS3This guide covers a very generic VNS3 setup. If you are interested in more custom use cases and would like CohesiveFT to advise and help setup the topology contact [email protected] for services pricing.

This guide uses Cisco’s Adaptive Security Device Manager UI. Setting up your IPsec Extranet device may have a different user experience than what is shown here. All the information entered in this guide will be same regardless of your UI or cmd line setup.

Please review the VNS3 Support Terms before sending support inquiries to: [email protected]


mailto:[email protected]


http://www.cohesiveft.com/legal/vns3-support

http://www.cohesiveft.com/legal/vns3-support



copyright 2013

Firewall ConsiderationsCloudSigma deployment access is controlled by the CloudSigma Network Policies. This document will show you how to open the correct ports in order to access the Manager, peer Managers, connect clients, and negotiate an IPsec tunnel. VNS3 Manager instance uses the following TCP and UDP ports. This guide uses two Policies - 1 for Managers, 1 for Client Servers.

• UDP port 1194 For client VPN connections; access rule on the VNS3 Manager group must allow UDP port 1194 from all servers that will join VNS3 topology as clients.

• UDP 1195-1197For tunnels between VNS3 Manager peers; must be accessible from all peers in a given topology. Free Edition and Lite Edition will no require UDP ports 1195-1197 access as it is not licensed for Manager Peering (Single Manager Topologies).

• TCP port 8000 HTTPS admin interface; must be accessible from hosts where you will want to obtain runtime status or configure your VNS3 topology, also needs to be open to and from the managers at least for the peering process, and needs to be accessible when downloading credentials for installation on overlay network clients.

• UDP port 500 and 4500IPsec connections to CloudSigma deployments require NAT-Traversal when using IPsec as the Network Policies do not allow you to enable specific protocols (like ESP Protocol) To make NAT-Traversal encapsulated connection to a CloudSigma deployment you will need to allow access via UDP port 500 and 4500.


copyright 2013

Remote Support

5

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

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

In the event CohesiveFT needs to observe runtime state of a VNS3 Manager 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.

CohesiveFT will send you an encrypted passphrase to generate a private key used by CohesiveFT Support staff to access your Manager. 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.

Tuesday, November 26, 13

copyright 2013

Sizing ConsiderationsImage Size and Architecture

VNS3 Edition Manager Images (Free Edition and BYOL-UL) are available as 64bit images to allow the greatest flexibility for your use-case. We recommend Manager instances be launched with at least 512MB of RAM. Smaller sizes are supported but the performance will depend on the use-case.

Clientpack Key SizeVNS3 Managers currently generate 1024 bit keys for connecting the clients to the overlay network via the “clientpacks”. Smaller or larger encryption keys can be provided upon request (from 64 bit to 2048 bit). Future releases of VNS3 will provide the user control over key size and cipher during initialization and configuration.


copyright 2013

Step 1: CloudSigma Deployment Setup


copyright 2013

CloudSigma Configuration: Create a Network Policy

8

Network policies allow you to specify the type of traffic and direction (inbound/outbound) that is allowed to pass through a network port. Select My Network, click Policies, and click Create to create a VNS3 Manager and VNS3 Clients policy group.

Add the following Inbound exceptions to the VNS3 Manager Policy:• 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• UPD ports 1194 from the VNS3-Clients security group• UDP port 500 from the IP of your Datacenter-based IPsec Device• UDP port 4500 from the IP of your Datacenter-based IPsec Device• UDP ports 1195-1197 from the VNS3-MGR security group (only required for

multiple Manager topologies - SME or Enterprise Editions)

Add the following Outbound exceptions to the VNS3 Manager Policy:• TCP/UPD from Any IP from all ports to all ports

NOTE: No VNS3 specific inbound rules need to be added to the VNS3-Clients group other than what is needed for normal ssh or RDP access from your IP.


http://whatismyip.com

http://whatismyip.com

copyright 2013

Step 2: Launching a VNS3 Manager Server


copyright 2013

VNS3 Server Launch: Attach the VNS3 Drive

10

Click My Servers then Create.

Enter a name for the server.

Click on the Drives drop-down item. Select Drives and click Attached Drive from Marketplace.

Select the VNS3 image of your choice - either the BYOL or PAYG Image from. NOTE: The BYOL Image can be configured as a Lite, SME or Enterprise Edition using a license provided by CohesiveFT. Contact [email protected] for pricing and subscription information.




copyright 2013

VNS3 Server Launch: Associate the Network Policy

11

Click the Network drop-down item.

Click Edit. Select the VNS3 Manager Network Policy from the Apply Network Policy drop-down menu.

Click Create.


copyright 2013

Step 3: InitializeVNS3 Manager Server


copyright 2013

Logging in and Configuring the Manager

13

Login to the VNS3 Web UI - https://<Manager IP>:8000

In order to have an encrypted connection to the VNS3 Manager, the web UI uses HTTPS with a self-signed certificate generated on each manager individually on boot. You may need to add a security exception in your browser.

Log in with a username and password of vnscubed.

Reset your UI and API passwords:• NOTE: Your VNS3 Manager answers to API calls on the same port 8000 as the

web interface runs on. Ideally make a separate password for the API usage against the manager.

• NOTE: CohesiveFT does not have any key access or remote access to your VNS3 Managers unless provided by you. If you forget these passwords we cannot recover them for you.


copyright 2013

Logging in and Configuring the Manager

14

Login to the VNS3 Web UI - https://<Manager IP>:8000

Three Configuration Options:• Upload License (choose this when launching the first Manager of a Customer

Cloudlet) - Launch a new Manager using the default subnet or use a custom subnet.

• Upload runtime snapshot (choose this when recovering from a Manager failure) - Launch a copy of an old Manager using a locally stored snapshot of the running configuration from another Manager instance.

• Fetch remote configuration (choose this when launching a second Manager of a Customer Cloudlet) - Launch a copy of an existing Manager by grabbing a configuration from a running Manager.


copyright 2013

Logging in and Configuring the Manager Option 1:Upload License

15

Paste the encrypted VNS3 license received from CohesiveFT in the first field. This license will configure the generic Manager.

Enter a security token in the second field. This can be anything but must be the same for all Managers in the same topology.

Click Submit and Reboot.

The resulting screen allows you to choose between the subnet range that comes preconfigured with the license or a customer subnet defined by your specific topo needs.

Click the “Custom” Radio button to specify a custom subnet range.

In addition to selecting a custom subnet range you can specify linear addressing for your Overlay Connected Devices (OLNDs).

In this example we use 172.31.10.0/24 for our custom subnet range. The Manager IPs are 172.31.10.250-253, the VIP is 172.31.10.254, and the “Client Pack” IPs are 172.31.10.1-50. Your specific license might allow for more or less client packs or VNS3 Managers.

Once you complete this step, the manager instance will reboot itself and will come up with your specified topology enabled and running.

Click Submit and reboot. Skip to Generate Keys on VNS3 Manager.


copyright 2013

Logging in and Configuring the Manager Option 2:Upload runtime snapshot

16

If this manager is a replacement for another manager in an existing topology and you have a recent runtime snapshot from the old manager, you can instantiate the manager by uploading the snapshot. Uploading a snapshot will configure the new Manager the same as the old including using the same Client Packs for the connected Overlay Network Devices.

Once you have selected a locally stored snapshot, click Submit and reboot. Skip to Generate Keys on VNS3 Manager.


copyright 2013

Logging in and Configuring the Manager Option 3:Fetch remote configuration

17

Fetching remote configurations can speed the configuration of Managers you wish to Peer to an existing topology.

Specify the IP address of the Manager from where you would like to fetch configuration. The security token is used for negotiation between Manager peers and must be the same for all Managers you intend to Peer with one another.

Click Submit and reboot. Skip to Generate Keys on VNS3 Manager.


copyright 2013

Step 4: Generate Clientpacks


copyright 2013

Generate Keys on VNS3 Manager

19

The Manager is now configured to the License specs (how many managers it can peer with, how many clientpacks are available, and how many ipsec links are available).

Click Generate New under SSL Certs and Keys in the left column.

During key generation you can specify a Topology name to be displayed in the Manager UI for a given set of peered Managers. This can be changed at anytime by clicking on the Topology Name left column menu item.

Click Generate keys link. Key generator will be started in the background, and you can refresh screen to observe progress.

This process will generate the client credentials that will be loaded onto the devices you wish to connect to the VNS3 overlay network.

NOTE: The Client Packs generated will depend on your license and if you selected to a custom subnet.


copyright 2013

Step 5: VNS3 Manager Peering


copyright 2013

Peering the Managers:Peering Manager 1

21

Click Setup Manager Peering.

Managers connect to each other in a process called Peering. Peered Managers create a redundant, highly available and secure overlay network and share traffic load from the overlay network connected servers.

The Peering Setup Page will display the number of Managers allowed to peer together in your topology as defined by the license file used to configure the Manager.

For Manager #1 select "this instance" from drop down, instead of specifying its IP. To be valid, your form must have "this instance" value in one and only one drop-down.

If your topology has unused Managers, leave the extra fields set to "not set”.

If you have a multiple Manager topology, enter the Public DNS address of the second Manager for Manager #2. Repeat this for each additional Manager in your topology.

When done select Save Changes.

If you are using the Free or Lite Edition (single Manager topology), Skip to the VNS3 Manager Status.

You should then get a status page showing that this manager was able to reach the other launched manager instance.


copyright 2013

Peering the Managers:Peering Manager 2, fetch the keyset from Manager 1 (do NOT regenerate)

22

Log in to VNS3 Manager UI on the second manager.

Click Fetch Keyset. (Remember that keys must be generated only once per topology!) Type in private IP address of Manager1 (where keys were generated) and keys will be copied from Manager1 and set up locally.


copyright 2013

Peering the Managers:Peering Manager 2

23

For Manager #1 enter the IP address of MGR1

For Manager #2 select "this instance" from drop down, instead of specifying its IP. To be valid, your form must have "this instance" value in one and only one dropdown.

When done select Save Changes.

You should then get a status page showing that this manager was able to reach the other launched manager instances. Verify that topology checksum on Manager1 corresponds to that of Manager2.


copyright 2013

VNS3 Manager Status

24

The VNS3 Manager is ready to setup an IPsec Tunnel.

You should see all your peered Managers listed under the “Links to Other Managers” section on each Manager Runtime Status Page.


copyright 2013

Step 6: IPsec Configuration


copyright 2013

VNS3 IPsec Page

26

Click IPsec under Peering left menu heading.

The NAT-Traversal toggle on the IPsec page allows you to configure tunnels to VNS3 using NAT-Traversal encapsulation or native IPsec. NAT-Traversal encapsulation is a requirement of some public clouds like CloudSigma. NAT-Traversal is currently a global setting for VNS3.

NOTE: When toggling between configuration of NAT-Traversal on and off, you will have to Reboot the Manager by clicking the Reboot link under the Admin section in the left column of the UI.

For the purposes of this document we have enabled NAT-Traversal.

On the IPsec page note the Configuration Settings needed for IPsec tunnel configurations.


copyright 2013

Click Define new remote endpoint.

Enter descriptive name for the Endpoint configuration, this can be anything.

Occasionally there is another router between the IPsec firewall and the Internet. Enter the public facing IP address of either the IPsec device or router between the cloud and the IPsec device (see picture below).

Enter a Pre-shared Key and keep a record of that key to be entered into the IPsec device. In this example we use “test” for to avoid typos or c/p errors.

If your IPsec device is behind a router, enter the external IP interface of the IPsec device (see picture below).

Click Create. One the resulting page click New Tunnel.

Extra Config Parameters:We recommend connecting to the Manager with tunnels using AES256 encryption and SHA authentication for both IKE and ESP. Extra Parameters syntax can be found on the following page. Please contact CohesiveFT Support for assistance.

IPsec Configuration: Define a New Remote Endpoint

27

LAN

IPsec Device Router (optional)

Your Data Center

Overlay Clients

Overlay NetworkPublic Cloud

VNS3

IPsec

If present enterPublic IP as Endpoint

Use Local IP as NAT IP w/routerUse Public IP as Endpoint IP w/o router


http://www.cohesiveft.com/support/support-contacts/




copyright 2013

IPsec Configuration: Extra Parameters

28

VNS3's IPSec subsystem is good at autodiscovery on IKE and ESP choices with a wide range of boxes. We recommend being as specific as possible when entering tunnel parameters. Match the algorithm, hash and DiffieH group for your gateway settings by specifying them in the "Extra Params" text field. We support combinations algorithms 3DES, AES128, or AES256; hashes SHA1 or MD5; and DH groups 2 or 5. VNS3 has “beta” support for DH 14,15,16,17,18.

Example entries for IKE (Phase 1) and ESP (Phase 2) in the extra params box:

phase1=aes128-sha1phase1=aes256-sha1phase1=3des-md5-dh2phase1=aes256-sha1-dh5phase2=aes256-sha1phase2=3des-sha1

PFS Group

Extra params entry for PFS Group is technically required only when it must be different from pfs group in phase1. If that is the case, then use pfsgroup=dh2pfsgroup=dh5

IKE and ESP Lifetimes

phase1-lifetime=3600s (default setting on VNS3)phase2-lifetime=28800s (default setting on VNS3)

Dead Peer Detection - Disabled by default, to enable DPD to attempt to re-connect during periods of no response use the following:

dpdaction=restart (other options are “hold” meaning just wait, or “clear” meaning drop the security association. dpddelay=30sdpdtimeout=90s


copyright 2013

IPsec Configuration: Extra Parameters

29

Other, less frequently used options available are:

connection=bidirectional (default)Other options are “receive” meaning to not initiate connections, only receive them.

connection-rekey=yes (default)Other options are “no” meaning no Phase1 or Phase2 re-key operations are done.

compat:some-textThis option should only be used at the instruction of CohesiveFT. It allows underlying parameters of the IPSec, BGP, Routing, Firewall, or SSL VPN subsystems to be passed straight into the environment with no parsing or validation. It is only used in a small fraction of interoperability situations.


copyright 2013

IPsec Configuration: Setup a Tunnel

30

Enter the subnet behind the datacenter IPsec Extranet Device. In this example we used 192.168.3.0/24.

Enter the subnet you wish linked to the datacenter subnet. This has a couple common options:

• The full subnet of the overlay network in this case 172.31.10.0/24• A subnet of the overlay network, perhaps a specific host like 172.31.10.10/32• A subnet on another network the VNS3 Manager has a route to which could be a

datacenter subnet behind another datacenter remote endpoint, or a subnet in a cloud vlan that the manager has access to.

Provide a name for the tunnel to allow for easy identification in more complex topologies.

External Ping provides a pinging functionality over the IPsec tunnel that can be used in addition to IPsec DPD and Keep Alive settings to ensure the tunnel remains up during low traffic periods.

Enter an IP address of a pingable server located on the Remote Subnet specified.

Set the time interval (in seconds) for the ping.


copyright 2013

IPsec Configuration: Setup a Tunnel

31

Click Create.

Your VNS3 Manager IPsec setup is complete. The next steps will detail setting the IPsec connection from your extranet device. Once the IPsec connection is live, this guide will detail how to add clients to the created overlay network.

Note the “Configuration Settings” values, you will need these to correctly configure your extranet device.


copyright 2013

IPsec Configuration: Cisco ASA VPN Wizard

32

Create a new VPN Tunnel.

The Cisco ASA used in this guide does this through a VPN Wizard. If you are using another facility to create your IPsec Tunnel, make sure to enter the same information we enter in the following slides.

Choose a Site-to-Site Tunnel Type.

Click Next

Tunnel Configuration ConsiderationsIf you want the tunnel to be perpetual and as close to "always on" as IPSec can do, then:

• Your gateway should be using its "keepalive" feature, VNS3 has this enabled by default

• Your gateway should be using Dead Peer Detection (DPD) with a "restart" parameter in the event it believes tunnel is dropped

• Your VNS3 manager has DPD disabled by default, enable it by adding "dpdaction=restart" “dpddelay=30s” and “dpdtimeout=90s” in the extra parameters box (no quotes needed).

• Your gateway should allow the VNS3 manager to make a connection "inbound to it", by default the VNS3 manager allows inbound connections and attempts outbound


copyright 2013


33

Enter the VNS3 Manager’s IP address in the “Peer IP Address” field.

Enter the same “Pre-Shared Key” entered from page 27 (our example used “test”).

Click Next.


copyright 2013


34

Choose your Key Exchange Policy (IKE). Make sure it is the same as the one used in the VNS3 Manager setup. On page 27 we used “AES-256.”

Click Next.


copyright 2013


35

Select the encryption and authentication algos for the Encapsulating Security Payload (ESP). Make sure it is the same as the one used in the VNS3 Manager setup. Again our recommended setup uses “AES-256” from page 27.

Click Next.


copyright 2013


36

Setting up Hosts and Networks.

This is where you specify the subnets that will be advertised to one another over the IPsec tunnel. Source is the local subnet behind the Cisco ASA and Destination is the Overlay Subnet behind the VNS3 Manager. You can specify the entire Overlay Subnet or smaller Cidr blocks. Just make sure the settings on the remote device match the settings entered on VNS3.

Click Next.


copyright 2013


37

Double check that all the information is entered correctly.

Click Finish.


copyright 2013


38

Make sure the IPsec VPN session is up and running.

Goto Monitoring > VPN Statistics > Sessions

You should be able to see the session under LAN-to-LAN

Click Details.


copyright 2013


39

The Session Details will give you expanded information about your Key Exchange and IPsec status.


copyright 2013

IPsec Configuration: Manager Status

40

To check the status of your IPsec connection from the VNS3 Manager click on “Runtime Status.”

Each tunnel will be displayed as a connected tunnel. Click the “Tunnel ID” for tunnel parameters and to access the IPsec log for that specific connection.

If you do not see your tunnel listed, it is not correctly configured. Double check that you have entered all the information correctly in both the VNS3 Manager and your IPsec device. If you are having difficulties see the troubleshooting detail at the end of this document.

Repeat the steps on pages 28-41 to setup a second IPsec VPN tunnel to your overlay network.

NOTE: If you have 2 tunnels servicing the same datacenter subnet, these tunnels should not be up both at the same time.

If you have questions about setting up a second tunnel please contact us at [email protected].

Now that the IPsec Tunnel is up and running, clients in the cloud can be added to the secure Overlay Network extension of your Datacenter.


mailto:[email protected]?subject=VPN-Cubed%20IPsec%20to%20EC2%20Lite%20Edition:%20Tunnel%20Setup%20Question

mailto:[email protected]?subject=VPN-Cubed%20IPsec%20to%20EC2%20Lite%20Edition:%20Tunnel%20Setup%20Question

copyright 2013

IPsec Configuration: Tunnel Detail

41

Each IPsec tunnel has a detail page. Refer to this page for all relevant information about a tunnel including the Tunnel Parameters used to negotiate and the tunnel history.

RestartThe tunnel detail page also allows you to restart the individual tunnel to force a renegotiation of without impacting any other tunnel connections.

DeleteRemove the tunnel from the associated Endpoint Configuration.

Show LogThe resulting pop-up window displays the log message for the specific tunnel.

Configure LoggingAllows you to toggle between standard and verbose logging.

NOTE: Verbose Logging is disabled by default and should remain disabled during normal operations. Leaving Verbose Logging enabled over a extended period of time can fill the Manager instances virtual disk drive. This causes the Manager to become inaccessible via the UI and requires our intervention to free up disk space.


copyright 2013

Step 7: Overlay Client Server Configuration


copyright 2013

Client Configuration: Clientpack Detail

43

As of this release the client pack naming convention of “cp<integer>.<zip tar.gz> has been discontinued. (For example cp1.zip, cp2.zip.)

Client packs are now 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 manager embedded within them.

Additionally, the client packs now have default “REMOTE” lines with the private IP and the public IP of the VNS3 Manager that generated the keyset. For single manager configurations this is a reasonable default that works in most cloud deployments. For multi-manager topologies the configuration files will still need to be configured manually or via automation, otherwise all connections will run through the single manager.


copyright 2013

Connecting Client Servers Option 2:Encrypted VPN-Cubed Overlay Subnet

44

In the context of VNS3, “client” means devices which will be configured as members of the overlay network. These network members will usually be servers running in the coud. In more advanced editions of VNS3 this includes desktop based client machines. Note the “Client Download” username and password on Status screen on every manager (username is “clientpack”).On any Manager go to Client Packs and pick a client pack. A client pack can run on a single client at a time. If you shut down or disconnect client from the topology, you can reuse its client pack. The number of client packs provided in your license depends on your purchased parameters.Alternatively, you can use the API to access the client packs. See the VNS3 API documentation for how to use the command line calls get_next_available_clientpack, fetch_clientpack, and edit_clientpack.


copyright 2013

Client Configuration: Firewall Considerations

45

Depending on what OS your cloud-based clients are running you will need to add access to the vnscubed-client security group via RDP Port 3389 (Windows) or SSH Port 22 (Linux) in order to add the clientpacks. Additionally Port 8000 access will need to be opened between the vnscubed-mgr and vnscubed-client security groups. For Linux Clients Configuration follow the steps on pages 46-49For Windows Clients Configuration follow the steps on page 50-52


copyright 2013

Linux Client Configuration: Install Clientpack

46

TWO PHILOSOPHIES FOR INSTALLATIONa) 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 Manager “Client Packs” link. SCP them into the client machines, and then SSH into the client machines to complete the configuration. b) Port 22 and Port 8000 Exception - Allow port 8000 and port 22 access as described on the previous pages to a Manager. SSH into the client machine and download the credentials from its command line using the following URL:

wget --no-check-certificate https://clientpack:**PASSWORD**@{Manager_IP}:8000/credentials/{name_of_clientpack}.tar.gz

Something like: wget --no-check-certificate https://clientpack:[email protected]:8000/credentials/172_31_1_53.tar.gz

NOTE: The clientpack:password combination is on the status screen of each of the VNS3 Managers.


https://clientpack

https://clientpack

https://clientpack:9c50eb1a78cabfa77663d0429bdd2930c4a3de12@ec2-174-129-124-113.compute-1.amazonaws.com:8000/credentials/172_31_1_53.tar.gz




copyright 2013

Linux Client Configuration: Install OpenVPN

47

You can either install OpenVPN 2.2+ on physical servers or virtual servers you already possess to connect those devices to the VNS3 overlay network. Once OpenVPN is installed, you need to save the desired clientpack on that client server and configure the file /etc/openvpn/vnscubed.conf.

Extract clientpack contents to /etc/openvpn directory (consult OpenVPN documentation for your OS if not found).

Edit the vnscubed.conf add the managers you want this client to connect to in priority at the bottom of the file:

remote MANAGER_DNS_ADDRESS 1194

Use the public DNS URL of the Manager for the remote entry. In multiple Manager 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 evenly distributed clients among managers by varying the order of "remote" commands on each client.


http://openvpn.net/index.php/open-source/downloads.html


copyright 2013

Linux Client Configuration: Start OpenVPN

48

Start openvpn. On Linux OSs 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 manager 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 Managers on page 15) for manager MGR1 and MGR2, respectively. Usually, the manager whose "remote" line appears first in /etc/openvpn/vnscubed.conf will be pingable first, other managers will become pingable once they learn about new client.


copyright 2013

Windows Client Configuration: Install Clientpack

49

RDP into the Windows Machine using the Administrator credentials specified when launching the server.Navigate to https://<Public Manager IP>:8000 in IE.Login using the default vnscubed for the password and username or the password you changed on your first login.Click Client Packs on the left menu.Download the appropriate client pack zip file to the Windows machine.


copyright 2013

Windows Client Configuration: Install OpenVPN

50

Install OpenVPN 2.2+ 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 client pack on the Windows desktop machine and put the client pack files in \Program Files\OpenVpn\config\

RENAME vnscubed.conf to vnscubed.ovpn !!!!

Edit the vnscubed.ovpn and add the managers you want this client to connect to in priority at the bottom of the file:

remote MANAGER_DNS_ADDRESS 1194

Use the public DNS URL of the Manager for the remote entry. In multiple Manager 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 evenly distributed clients among managers by varying the order of "remote" commands on each client.




copyright 2013

Windows Client Configuration: Launch OpenVPN

51

Start openvpn. On Windows XP and Vista this can be done through the Services tool or via the command line “openvpn vnscubed.ovpn”.

On Vista if you run it from the command line you will need to know how to start a command line with administrative privileges. Details here: http://www.howtogeek.com/howto/windows-vista/run-a-command-as-administrator-from-the-windows-vista-run-box/

Alternatively, start the OpenVPN service from the Services tool. On Vista and Win2k servers OpenVPN also has a graphical tool - OpenVPN GUI.

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 manager 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.

Verify connectivity by pinging 172.31.10.1 or 172.31.10.2 (the IPs we setup for our Managers on page 16) for manager ID1, ID2,respectively. Usually, the manager whose "remote" line appears first in /etc/openvpn/vnscubed.conf will be pingable first, other managers will become pingable once they learn about new client.


http://www.howtogeek.com/howto/windows-vista/run-a-command-as-administrator-from-the-windows-vista-run-box/






copyright 2013

Windows Client Configuration: Windows 2008 RegEdit Consideration

52

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.

1.Go to "regedit"2.Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters3.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.4.Reboot the machine


copyright 2013

Step 8: Review Completed Configuration


copyright 2013

Client Configuration: Clients in the overlay network

54

The key elements of the display to look for are the connections to that manager’s peer, both showing the local processes are running and the link as up. You should see the clients listed in the client table at the bottom, connected to the appropriate manager.

If this is not the case please check the items listed on the “Troubleshooting” page of this document.


copyright 2013 55

Appendix: VNS3 Firewall


copyright 2013

VNS3 Firewall - Overview

56

VNS3 Firewall features are controlled using IPTables syntax. For more information see - http://linux.die.net/man/8/iptables and look for the PARAMETERS section. Another useful guide is available here: http://www.thegeekstuff.com/2011/06/iptables-rules-examples/

In general, you write a specification of a packet to match and then specify what to do with this packet. These are referred to as “customer” rules and are applied as appropriate in the overall firewall rule structure on the manager. This means in addition to the standard security and firewall features of VNS3, you can create your own rules to restrict traffic to and through the VNS3 Manager.

The order of rules matter - rules are applied from top to bottom until the first match. If no match is found, the packet is allowed to continue on. Important note: If your customer rules don't reject a packet, it will be allowed by default.

However, this “default” is fairly restrictive. Traffic is allowed from “known” VLANS. Known VLANs are VLANS that are listed in IPSec tunnel rules, and the VNS3 virtual VLAN. Allowing traffic from other sources requires adding firewall rules to accept that traffic.


http://linux.die.net/man/8/iptables

http://linux.die.net/man/8/iptables

http://www.thegeekstuff.com/2011/06/iptables-rules-examples




copyright 2013

VNS3 Firewall - Basic Syntax

57

VNS3 creates a firewall table for your rules which is implicitly used by any firewall commands you enter.

As a result, the firewall syntax varies from standard iptables in that you don’t specify an “append” or “-A”. The chain names for your commands use restricted chain names of INPUT_CUST, OUTPUT_CUST, FORWARD_CUST, PREROUTING_CUST and POSTROUTING_CUST.

These tables go into the top of the corresponding VNS3 internal firewall chains. The INPUT_CUST, OUTPUT_CUST, and FORWARD_CUST go into the iptables Filter table, and the PREROUTING_CUST and POSTROUTING_CUST go into the Nat table.

For example the full IPTable syntax would be something like:

iptables -A INPUT_CUST -p tcp -s 172.31.1.1/32 --dport 8000 -m state --state NEW,ESTABLISHED -j DROP

In VNS3 enter the same elements without the “iptables” command and the “-A”:

INPUT_CUST -p tcp -s 172.31.1.1/32 --dport 8000 -m state --state NEW,ESTABLISHED -j DROP


copyright 2013

VNS3 Firewall - Examples

58

"-j ACCEPT" allows a packet. "-j DROP" drops a packet. "-j REJECT" sends an appropriate notification to sender saying such and such packet was rejected (depends on protocol).

Some Basic examples:

* Drop all packets from 1.1.1.1 to 2.2.2.2 INPUT_CUST -s 1.1.1.1 -d 2.2.2.2 -j DROP

* Drop all traffic from 192.168.3.0/24 (entire subnet) except 192.168.3.11: INPUT_CUST -s 192.168.3.11/32 -j ACCEPT INPUT_CUST -s 192.168.3.0/24 -j DROP

* Drop tcp traffic from 172.31.1.1 on port 8000 (Stop overlay clients from using the overlay IP of 172.31.1.1 with port 8000 (the port used to access the Manager’s Web UI).

INPUT_CUST -p tcp -s 172.31.1.1/32 --dport 8000 -m state --state NEW,ESTABLISHED -j DROP

INPUT_CUST -p tcp --sport 8000 -m state --state ESTABLISHED -j DROP


copyright 2013

VNS3 Firewall - NATing (network address translation)

59

It is now common for clouds to provide VLAN isolation.

One of these is “NATing” which allows the machines in the VLAN to use the VNS3 Manager as a gateway to services on the Internet, with all VLAN machines sharing the Manager’s public IP address.

This is the same behavior used in your home or office, where many devices can access the Internet via one shared public ip address. When a VLAN device accesses the Internet, its return traffic is routed to it.

Basically, VNS3 lets you use your cloud VLAN just like you treat your home or office network, isolated from inbound requests for service, but allowing most outbound service requests.

Simple Syntax: -o eth0 -s 10.199.1.0/24 -j MASQUERADE

In this example - your VNS3 Manager is in a VLAN subnet with a network from 10.199.1.1-10.199.1.254. Many clouds with VLAN capabilities map a public IP to the private IP on eth0 via DNS.

Here we are telling the VNS3 Manager to “masquerade” for traffic coming from that subnet out to the Internet and then return the response packets to the requesting machine. NOTE: With MASQUERADE you don’t specify a chain for the rule to go into.


copyright 2013

VNS3 Firewall - Port Forwarding

60

With CloudSigma, you can choose whether you servers have a public interface or not.

What if you want to be able to access one of the machines (for example like you might do on your home network) from the Internet? This is where port forwarding comes in.

A common use case would be using a Windows Remote Desktop on one of your cloud servers, as the “jump” box for then remoting to all the other cloud servers in your cloud deployment. VNS3 lets you do this with your deployment, just like you could for your home or office network, allowing specific traffic, from a specific source, on a specific port to be “forwarded” on to another machine.

Simple Syntax: -o eth0 -s 10.199.1.0/24 -j MASQUERADEPREROUTING_CUST -i eth0 -p tcp -s 69.69.70.70/32 --dport 3389 -j DNAT --to 10.199.130:3389

Using the same example network, assuming a source network public IP of 69.69.70.70 from which the RDP client is running, do the following:• NATing needs to be enabled for port forwarding to work• Specify the port to be forwarded, in this case “RDP” or 3389• Specify the source network address, here 69.69.70.70/32• Specify the machine for port 3389 traffic, here 10.199.1.130 using the “--to” syntax• Use the “-j DNAT” syntax to specify destination network address translation.• NOTE: MASQUERADE doesn’t take a chain specification.


copyright 2013

VNS3 Firewall Warning

61

The VNS3 firewall allows customers complete control of the INPUT, OUTPUT, FORWARDING, PREROUTING and POSTROUTING behavior of traffic as it first enters the VNS3 Manager and as it exits the VNS3 Manager.

The VNS3 internal firewall is still there to “protect” the internal mechanisms of VNS3, however, customer rules can be created that have undesirable effects. Essentially rules that ACCEPT or REJECT/DROP all traffic are likely to create a device that is un-reachable or one that is too permissive in accepting traffic.

Customer rules are evaluated and if there is not a match in the _CUST chains, then they flow through into the interior VNS3 chains which are quite restrictive. Accepting all traffic prevents most of the interior rules from being evaluated which might block unsafe traffic. Blocking all traffic prevents most of the interior rules from being evaluated which accept necessary traffic such as the API and WebUI management utilities. (Blocking port 8000 from all traffic will make the VNS3 instance un-manageable.)

Do not have rules of either of the following forms:INPUT_CUST --dport 8000 -j REJECTINPUT_CUST -j REJECTINPUT_CUST -j ACCEPT


copyright 2013

Change Username and Password

63

Username and Password can be changed via the Left Column Menu Items.


copyright 2013

Runtime Snapshots save the Manager Configuration

65

Once your VNS3 Managers and Clients are configured and running, save the configuration with Runtime Snapshots. Snapshots can be used to reconfigure a new Manager with the same SSL Certificates and Keyset with just one file upload.

Click the “Runtime Snapshots” link to take a new snapshot or view/download available snapshots.

Download the snapshot to your local network. In the event of a Manager failure or re-provisioning event, you can upload the snapshot file to a new VNS3 Manager. The new Manager will retain all the configuration settings as your saved snapshot.

If you are utilizing Elastic IPs, once the Elastic IP is transferred to the new Manager, your overlay network devices will automatically connect back with the Managers. Save time on both Manager and client configuration.


copyright 2013

Save and Download a Snapshot

66

Click the “Take New Snapshot Now” button to generate a new Snapshot.

The resulting screen will have the snapshot download link. Download the Snapshot and save locally.


copyright 2013

Save and Download a Snapshot

67

To use a Snapshot to configure a Manager click the “Import Runtime Snapshot” link.

Browse for your saved Snapshot and upload. The Manager will reboot with the updated configuration. The same client packs will be available in the manager, so redistribution to each server on the virtual network is not necessary.

A slight configuration change on each server on the virtual network is necessary if you do not assign the Cloud IP used on the previous Manager. The OpenVPN configuration file (vnscubed.<conf ovpn>) distributed to each client server will need the new Cloud IP of the new Manager referenced in the remote commands section.


copyright 2013

Upgrading Licenses

69

To upgrade a license click on the “License Upgrade” link in the left column of the Web User Interface.

A license upgrade needs to be deployed to all of the managers of a peered VNS3 topology.

In order to upgrade you will need the upgrade keyset ID which is shown in bold in the image displayed here. Provide that license keyset to CohesiveFT Support and they will use it to generate your upgrade license.

In order to apply the new license click “Import a new license upgrade”, and paste the contents of the license you received, and click “Submit”.


copyright 2013

Confirming the successful license upgrade

70

Along with the license upgrade key you will have received with the key a “License Upgrade ID”.

After clicking “Submit” your License Upgrade ID is displayed on the user interface. It should be the same as the one you received with your license upgrade.

If your license upgrade requires any new data such as IP Addresses to use for new client packs, there will be an opportunity to enter it on the screen, and then you “finalize” the upgrade by hitting “Submit again.

You will then see the contents of the license displayed, and should confirm that your new license contents has the parameters you expected.

In this example case the license upgrade added the ability to have 2 more remote endpoint definitions for use with IPsec tunnels. Looking at the previous picture you will see the total of “ipsec_max_endpoints” was 50, and after the upgrade is increased to 52.


copyright 2013

SNMP Support - Beta

72

VNS3 now supports a number of industry standard MIBs for use from a monitoring system doing SNMP polling. We do not currently support any SNMP traps.

VNS3 SNMP support is enabled through the firewall. In the future we will provide API calls and user interface to provide more control of the SNMP experience.

To enable access to the SNMP information add the following rule to your firewall using a source address from your network (either your public IP, or an internal IP available to the manager via IPsec or client pack). There is no SNMP authentication in this beta. An example rule would be “-p udp -s 69.69.70.70/32 --dport snmp -j ACCEPT” (where 69.69.70.70 is your network’s public IP address).

On your SNMP monitoring system:

- Use SNMP v1c or v2 - Community string of “vns3public”- The access to the SNMP information is “read only”

You should then be able to use a utility like “snmpwalk” to test:snmpwalk -v 1 -c vns3public -O e <vns3_manager_public_ip>

In order to discuss additional MIBs needed please contact your CFT account representative or support (at) cohesiveft.com

snmpwalk -v 1 -c vns3public -O e <vns3_manager_public_ip>SNMPv2-MIB::sysDescr.0 = STRING: Linux vpncubed 2.6.32-344-ec2 #46-Ubuntu SMP Wed Mar 7 13:47:05 UTC 2012 x86_64SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1651090) 4:35:10.90SNMPv2-MIB::sysContact.0 = STRING: [email protected]::sysName.0 = STRING: VNS3 version 3.0100.7-20130322173305SNMPv2-MIB::sysLocation.0 = STRING: VNS3 Cloud Container

Example of response from “snmpwalk”




copyright 2013

Peering Troubleshooting: Fetch Keyset Error

74

Fetch Keyset appears to hang or not work. Check to see if the Cloud Sigma Policy is correct for port 8000 between the manager you are getting the keyset from and the manager you are do the fetch from.


copyright 2013

Peering Troubleshooting: Not Reachable

75

Manager Peering Status Table Detail•Remote Manager ID: References the Manager # from Peering Setup•Remote Manager IP: The Public IP of the Remote Manager•Local Endpoint (server or client): which Manager initiates the Peer connection•Local Process Running? (running or not): Is the peering process running on the local

Manager•Direct Link Status (up or down): Is there a direct link between the local Manager and

the remote Manager•Remote Manager Reachable? (reachable or not): Is the remote Manager connected

Local Process Not Running - Usually the status right after configuring Peering. If this status persists (>5mins) contact CohesiveFT Support.

Direct Link Down - The peering connection between the Managers has not been established. Double check the hypervisor firewall/security group rules allow the peering ports UDP 1195-1197 for two Manager topologies.

Mesh: Direct Link Down but Reachable - While the peering connection between Manager 1 and Manager 2 has not been established, the Peered mesh is passing traffic between Manager 1 and 2 via Manager 3. Double check the hypervisor firewall/security group rules allow the peering ports UDP 1195-1202 for three Manager topologies.

Successful Connection

Local Process Not Running

Direct Link Down

Mesh: Direct Link Down but Reachable




copyright 2013

Overlay Troubleshooting

77

Client Servers join the Overlay Network by connecting to the Manager mesh using a clientpack and OpenVPN. OpenVPN uses the clientpack to create a new virtual network interface (usually tun0) and assigning the Overlay IP associated with the clientpack. When troubleshooting check both the VNS3 Manager Status page and the Client Server network configuration (ifconfig, ipconfig or similar depending on OS and preference).

Client Server is not joining the Overlay Network - The OpenVPN virtual network interface is not being created. Check the OS firewall isn’t blocking the OpenVPN outbound connection to the VNS3 ManagerCheck the cloud hypervisor firewall/security group isn’t blocking the incoming OpenVPN connection from the client server to the Manager on UDP port 1194WindowsMake sure you are running the OpenVPN app/service as AdministratorDouble check you don’t need to make a RegEdit modification detailed on slide 53

Client appears to be “hopping” on and off the network. This is usually the result of the same client keys being installed on two client machines in the network. Only one client machine can use a set of credentials at a given time.


copyright 2013

IPsec Troubleshooting: Tunnel Detail

79

IPsec troubleshooting should start at the IPsec Tunnel Detail page associated with the tunnel that is not connecting.

Use the Show Log link to pop up the log information for this specific tunnel. When contacting CohesiveFT Support also include as much information from this page as possible to frame the scenario.

Refer to the IPsec Troubleshooting Guide and the VNS3 Support Checklist.




http://www.cohesiveft.com/dnld/VNS3_3.x_IPsec_Troubleshooting_2013.pdf

http://www.cohesiveft.com/dnld/VNS3_3.x_IPsec_Troubleshooting_2013.pdf

http://www.cohesiveft.com/dnld/VNS3_3.x_Support_Checklist_2013.xls

http://www.cohesiveft.com/dnld/VNS3_3.x_Support_Checklist_2013.xls

copyright 2013

IPsec Troubleshooting: Network Sniffer

80

The Network Sniffer is a useful tool in determining the cause of a connected tunnel that isn’t passing traffic by allowing you to monitor the Overlay Network Interface (tun0) and the interface used by the IPsec connections (eth0).

Test 1: Monitor Traffic from the Overlay Network to the Remote Subnet

1. Setup a continuous ping from a connected client server to the remote subnet advertised behind the Remote IPsec Device

2. Monitor the VNS3 Manager's Overlay interface (tun0) with the source set to your connected client server overlay IP address. This checks whether packets from the connected client server make it to the VNS3 Manager. If the packets are arriving, move to step 3. If the packets are not arriving, double check your connected client servers have the appropriate routes for the customer's remote subnet and no OS port filtering is blocking the traffic on the connected client server.

3. Monitor the VNS3 Manager's IPsec/Public interface (eth0) with the destination set to the customer's endpoint public IP. This checks whether the ping packets are being encapsulated and sent down the tunnel. The packets will be encapsulated and sent at the interval set in your continuous ping. If you see packets going out, continue to step 4. If you don't see packets going out, double check the VNS3 firewall rules aren't blocking the traffic.

4. Have the customer monitor the outside interface of their device and follow the "bread crumbs" from there.


copyright 2013

IPsec Troubleshooting: Network Sniffer

81

Test 2: Monitor Traffic from the Remote Subnet to the Overlay Network

1. Setup a continuous ping from the remote subnet to a connected client server's Overlay IP

2. Confirm the packets are making it out of the remote IPsec device and into the tunnel.

3. Monitor the VNS3 Manager's IPsec/Public interface (eth0) with the source set to the remote endpoint public IP. This checks whether the ping packets are reaching the VNS3 Manager instance via the IPsec tunnel. If you see packets coming up the tunnel, continue to step 4. If you don't see packets making it to the VNS3 Manager, double check the hypervisor firewall/security groups and VNS3 firewall rules aren't blocking any of the traffic. Revert to step 2.

4. Monitor the VNS3 Manager's Overlay interface (tun0) with the destination set to your connected client server overlay IP address. This checks whether packets from the remote side are making it through the Manager and out to the client server on the Overlay. If the packets are not arriving, double check your connected client servers have the appropriate routes for the remote subnet and no OS port filtering is blocking the traffic on the connected client server.


VNS3 3.0.4 Free, Lite, SME and Enterprise Edition for CloudSigma

Documents

Transcript of VNS3 3.0.4 Free, Lite, SME and Enterprise Edition for CloudSigma