VNS3 Upgrade 2.x/3.x to 4.x Instructions

©2018

Table of Contents

2

Introduction 3Review 2.x/3.x Manager Configuration 7Upgrade Steps 8 1. Create a Snapshot from the 2.x/3.x Manager 9 2. Launch a 4.x Controller Instance 10 3. Log into the 4.x Controller 11 4. Swap the Public IP 12 5. Import Snapshot file 13 6. Update Cloud Settings as Needed 14 7. Review the 4.x Imported Configuration 15 8. Validate the Connections 16 9. Set the 2.x/3.x Manager to only receive IPsec 17 10. Reboot or stop the 2.x/3.x Manager 18

©2018

Introduction

3

©2018

Upgrade Requirements

4

• You have an existing VPN3 version 2.x or VNS3 version 3.x Manager launched and configured.

• You have access to a new VNS3 4.x Virtual Image provided by Cohesive or via Cloud Marketplace or public catalog.

• You have scheduled an operational window with any parties connected to or using the existing VNS3 instance (see downtime considerations on the following page).

©2018

Upgrade Downtime Considerations

5

Upgrading between versions of VNS3 requires launching and configuring a new Controller server instance. While steps 1-3 in the following document can be done with no impact to an existing VNS3 topology, cutting over to the new Controller will interrupt service to the networks connected to the VNS3 Controller (Cloud subnet, connected IPsec devices, VNS3 encrypted overlay, etc..).

Downtime can be greatly reduced if the existing Controller configuration as well as cloud environment has been configured using a user controlled and assignable static Public IP like AWS Elastic IPs.

If you cannot control the Public IP address of the new 4.x Controller, you will need to reconfigure connecting IPsec devices configuration, as well as VNS3 Overlay Network clients configured to use the old Controller instance Public IP address.

©2018

Getting Help with VNS3

6

Cohesive Networks offer support and services for VNS3 version upgrades. Audits, snapshot reviews, and chaperoned upgrade windows can be scheduled with your account representative or by emailing us at support@cohesive.net

Please review the VNS3 Support Plans and Contacts before sending support inquiries. If you need specific help with project planning, POCs, or audits, contact our professional services team via sales@cohesive.net for details.

©2018

Review 2.x/3.x Manager Configuration

7

Before any upgrade, review the health of the existing VNS3 device double checking the configuration elements that will be moving to the new VNS3 controller and any other cloud environment settings (Route Tables, IP Forwarding, etc.) that will need to be updated.

OVERLAY CLIENT NOTE: 

When using overlay clients, they receive route information when they connect to their VNS3 controller only. If IPsec connections re-cover after the client connection takes place you might need to reset the client overlay agent. To ELIMINATE this dependency please speak with Cohesive Networks about deploying the VNS3 Routing Agent on your overlay clients.

IPSEC NOTE:

Cohesive Networks STRONGLY recommends against using DH2 as a weak key exchange. VNS3 4.x and later controllers will not allow IPsec connections to be negotiated with Diffie-Hellman Group 2 unless explicitly specified ("dh2") in the IPsec Endpoint Extra Configuration box.

If a connection is negotiated without any configuration parameters on a 2.x or 3.x VNS3 Manager and the connection is using DH2, the imported configuration (via VNS3 snapshot) will reject DH2 during negotiation. If the connection party/device requires DH2 simple enter the explicit configuration into the extra configuration parameters box on the 4.x in Step 6 of this document (page 15).

For any upgrade from older connections - please go to one of the tunnel home pages for the OLD controller - and note the tunnel's negotiated parameters.

©2018

VNS3 Upgrade Steps

8

©2018

1. Create a configuration Snapshot of the 2.x/3.x Manager

9

This Upgrade example will use a VNS3 3.5.2 Snapshot to import the running configuration of a 3.5.2 Controller to a 4.x Controller.

Create the VNS3 Snapshot that will be used to import the running configuration of the existing Controller to the 4.x Controller.

From the existing Controller UI, click the "Snapshots" left column menu item under the Maintenance section.

On the resulting Snapshots page, click Take New Snapshot Now.

The Controller will create a new Snapshot and present a download link. Click the download link and save locally.

©2018

2. Launch a 4.x Controller instance

10

Use the 4.x Controller virtual image available in the cloud’s public catalog or private images provided by Cohesive Networks. Launch the 4.x Controller in the same Region/Datacenter/Availability Zone as the existing Controller using the cloud’s console or the command line.

For greatest stability the new controller should be launched into a cloud segment where the Public IP of the old Controller instance can be assigned to the new instance.

©2018

3. Log into the 4.x Controller

11

Log into the new 4.x Controller instance using the following log in credentials:

username: vnscubed

password: either AWS instance ID (i-xxxxxxxx) or vnscubed depending on the deployment environment

You will be prompted to change both the UI and API password when logging into a 4.x VNS3 Controller for the first time. The passwords you enter in this step will be used by the Controller after the snapshot from the old Manager is uploaded.

NOTE: If you do NOT change the password of the new controller BEFORE importing the snapshot, the password stored in the snapshot file will be used. There is some chance this will be a password you have no record of, if the only snapshot available is old. Change the password of the VNS3 4.x controller BEFORE the snapshot import.

©2018

4. Swap the Public IP and Reconfigure the Overlay

12

If your old Controller and its Overlay Network topology is configured using a user controlled and assignable static Public IP, like AWS Elastic IPs, switching the Public IP from the old Controller to the 4.x Controller will force any IPsec , Peering, and Overlay Client connections to reconnect with the new 4.x Controller automatically.

If you do not have control over the Public IP address of the old Controller you will need to reconfigure IPsec connections and Overlay Network client server configuration files (vnscubed.conf) to point to the 4.x Controller.

For this example the use of Elastic IPs is demonstrated.

From the AWS console click the Elastic IPs left column menu item under the Network & Security section.

Select the Elastic IP currently associated with the 3.x Manager and click Disassociate then Yes, Disassociate in the popup window.

With the same Elastic IP selected click Associate and select the 4.x Controller instance then click Yes, Associate in the popup window.

©2018

5. Upload the Snapshot to the 4.x Controller

13

After the old controller IP address has been associated with the new instance, click the "Upload Snapshot" left column menu item under the Initialization section.

Browse and specify the VNS3 Snapshot saved previously.

Click Submit and reboot.

Click OK on the popup window informing you the 4.x Controller will reboot once the Snapshot is uploaded.

Hitting the blue "Refresh" link in the body of the page will provide a summary of the import steps.

NOTE: The Snapshot import will change your 4.x controller name at the top of the UI and in browser tabs to whatever the name of the PREVIOUS controller was when the snapshot was taken. Confirm the operations you take are on the correct controller.

©2018

6. Update Cloud Settings as Needed

14

Some VNS3 deployments do not use the Overlay and instead use the unencrypted Cloud VLAN/VPC for in-cloud communication. In setups like this there are additional cloud settings to enable the VNS3 to pass traffic to/from other cloud devices on the underlying VLAN/VPC.

Cloud Route Tables

Update the Cloud Route Table to point the route to the new VNS3 Controller VM/Instance.

Source/Destination Check or IP Forwarding

Allow the 4.x Controller to pass traffic where it is neither the source or destination. This is done by either Disabling the Src/Dest Check on the Instance in AWS or Enabling IP Forwarding in Azure.

©2018

7. Review the 4.x Controller’s Imported Configuration

15

Extra Configuration Parameters (2.x or 3.x to 4.x)The 3.x release introduced a new set of arguments for the Extra Configuration Parameters field on the IPsec Endpoint page (see the 3.5 Configuration Guide | Administration Guide for more information). 3.x Controller are backward compatible with 2.x Extra Configuration Parameters entries using the compat: prefix.

Firewall Rules (2.x/3.0 - 4.x)

If you are using negation rules, the underlying VNS3 Firewall Rule syntax has changed. Previously the exclamation mark was used after the -d or -s. for an address space to be excluded. In VNS3 3.5 the exclamation mark is now used before the -d or -s.

Old Syntax - INPUT_CUST -s ! 192.168.1.0/24 -j ACCEPT

New Syntax - INPUT_CUST ! -s 192.168.1.0/24 -j ACCEPT

©2018

8. Validate the Connections

16

Once the connections have migrated to the 4.x Controller validate traffic flow and final configuration of the new Controller.

It is recommended you leave the old controller running for a 24 hour period in the case you wish to roll back. Ideally if supported in your cloud and version of VNS3, stop the old controller.

When using overlay clients, they receive route information when they connect to their VNS3 controller only. If IPsec connections re-cover after the client connection takes place you might need to reset the client overlay agent. To ELIMINATE this dependency please speak with Cohesive Networks about deploying the VNS3 Routing Agent on your overlay clients.

In the event you need to roll back, follow the steps below.

1. Disassociate the Elastic IP from the 4.x Controller 2. Associate the Elastic IP with the 2.x/3.x Manager 3. Reboot the 4.x Controller, and if available, stop it.

©2018

9. Set the 2.x/3.0 Manager only to receive IPsec connections

17

Add the following Extra Parameters on the 2.x Manager to prevent the 2.x Manager from trying to connect after the Upgrade has been completed.

auto=add rekey=no

This allows you to keep the 2.x Manager running in order to rollback if necessary without additional downtime.

On a 3.x and later controllers the parameters are:

connection=receive connection-rekey=no

©2018

10. Reboot or Stop the 2.x/3.x Manager

18

Once the Elastic IP has been associated with the 4.x Controller there is SOME small risk that port floating keeps some connections briefly on the old controller. To help ensure connections to the new 4.x Controller, reboot the old Controller from the VNS3 Manager UI.

Click the Reboot left column menu item under the Admin section and confirm you want to reboot the old controller by clicking "OK" on the popup window.

The reboot will bounce the active tunnels and force them to reconnect. The total time to reconnect is usually ~1-2 minutes.

Most VNS3 instances from 3.5 forward can be "stopped" in the Cloud Console where the instance is running. If available this is the best manner to ensure the old controller does not interfere with any of the connections. Please ensure you are 100% positive that your VNS3 instance can be stopped and restarted if needed.

©2018

VNS3 Configuration Document Links

19

VNS3 Product Resources - Documentation | Add-ons

VNS3 Configuration Instructions (Free & 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 DocumentCovers 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 TroubleshootingTroubleshooting document that provides explanation issues that are more commonly experienced with VNS3.