Learn how to upgrade previous versions of VNS3 (or older VPN3 versions) to the latest 3.5.x release. Follow along with upgrade steps to update, transfer configure settings, and secure your old and new VNS3 devices. Contact our support team for more information on upgrading to the latest 3.5 version of VNS3.

1. © 2016
VNS3 3.5
Upgrade Instructions
Version 2.x/3.x to 3.5
2016

2. © 2016
Table of Contents
2
Introduction 3
Upgrade Steps 7
1. Create a Snapshot of the 2.x/3.x Manager 8
2. Launch a 3.5 Controller Instance 9
3. Log into the 3.5 Controller 10
4. Upload the Snapshot to 3.5 Controller 11
5. Set the 2.x/3.x Manager to only receive IPsec 12
Review the 3.5 Controller’s Imported
Configuration
13
6. Swap the Public IP or Reconfigure the
Overlay
14
7. Reboot the 2.x/3.x Manager 15

3. © 2016
Introduction
3

4. © 2016
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:net version 3.x Image provided by Cohesive or via public
catalog.
You have scheduled an operational window with any parties connected to or using the
existing Overlay Network (see downtime considerations on the following page).

5. © 2016
Upgrade Downtime Considerations
5
Upgrading between versions of VPN3/VNS3 requires launching and configuring a new
Controller server instance. While steps 1-5 in the following document can be done with no
impact to an existing VPN3 topology, cutting over to the new 3.5 Controller will interrupt service
to the Overlay Network.
Downtime can be greatly reduced if the existing Controller and the Overlay Network topology
has been configured using a user controlled and assignable static Public IP like AWS Elastic IPs.
Step 6 of this document shows the assignment of the Public IP to the new 3.5 Controller
allowing the IPsec tunnels and the Overlay Network client servers to automatically reconnect.
If you cannot control the Public IP address of the new 3.5 Controller, you will need to
reconfigure any IPsec devices connecting to the 3.5 Controller and Overlay Network client
servers to point to the 3.5 Controller’s Public IP address.

6. © 2016
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.

7. © 2016
VNS3 Upgrade Steps
7

8. © 2016
1. Create a VPN3 Snapshot of the 2.x/3.x Manager
8
This Upgrade example will use a VNS3 3.0 Snapshot
to import the running configuration of a 3.0 Manager
to a 3.5 Controller.
Create the VPN3 Snapshot that will be used to import
the running configuration of the existing Manager to
the 3.5 Controller.
From the existing Manager UI, click the View and
Create left column menu item under the Snapshots
section.
On the resulting Runtime 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.

9. © 2016
2. Launch a 3.5 Controller instance
9
Use the 3.5 Controller AMI IDs available in the cloud’s public catalog
or those provided by Cohesive Networks. Launch the 3.5 Controller
in the same Region/Datacenter/Availability Zone as the existing
Manager using the cloud’s console or the command line. Below are
some examples of the launch command in AWS EC2.
Launch your 3.x Controller in US region, in vnscubed-mgr security
group:
ec2run -U https://us-east-1.ec2.amazonaws.com
AMI_ID_US -n 1 -g vnscubed-mgr
OR
Launch VNS3 Controller in EU region:
ec2run -U https://eu-west-1.ec2.amazonaws.com
AMI_ID_EU -n 1 -g vnscubed-mgr
IMPORTANT: 3.5 Controller AMIs do not need to be launched with a
different kernel or ramdisk parameter as with previous VPN3 AMI
versions.

10. © 2016
3. Log into the 3.5 Controller
10
Log into the new 3.5 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 3.5 VNS3 Controller
for the first time. The passwords you enter in this
step will be used by the 3.5 after the snapshot from
the old Manager is uploaded.

11. © 2016
4. Upload the Snapshot to the 3.5 Controller
11
Click the Upload Snapshot left column menu item
under the Initialization section.
Browse and specify the VPN3 Snapshot saved
locally in Step 1.
Click Submit and reboot.
Click OK on the popup window informing you the
3.5 Controller will reboot once the Snapshot is
uploaded.

12. © 2016
5. Set the 2.x/3.x Manager only to receive IPsec
12
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.

13. © 2016
Review the 3.5 Controller’s Imported Configuration
13
No Changes have been made to your existing Controller, cloud-deployment, or negotiated IPsec tunnels in the previous steps 1-5. Validate the Snapshot Upload was
successful (review Peering setup, IPsec configurations, Firewall configurations, Clientpacks, and Topology Name).
Extra Configuration Parameters
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.
CloudWAN Tunnels
The 3.x release changed the way CloudWAN features are surfaced to the customer. 3.x release introduced the concept of tunnels where you define the source and
destination subnets allowing complete control over the IPsec connections. Previously configured CloudWAN subnets will be surfaced as new tunnels as part of the
Snapshot Upgrade. Note: the default tunnels for each Endpoint, with source subnet of the entire Overlay Subnet, will also be automatically created.
Firewall Rules
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
The Next step will initiate the Operational Window and briefly bring both the IPsec and Overlay connections down. Before preceding make sure all parties
involved are aware of the temporary connectivity outage.

14. © 2016
6. Swap the Public IP or Reconfigure the Overlay
14
As previously mentioned Steps 1-5 have no impact on your existing
VPN3 deployment.
If your old Manager and the 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 Manager to the 3.5
Controller will force the IPsec connection and Overlay Network client
connections to reconnect with the new 3.5 Controller automatically.
If you do not have control over the Public IP address of the old
Manager you will need to reconfigure both the IPsec connection and
Overlay Network client server connections (vpncubed.conf/
vpncubed.ovpn) to point to the 3.5 Controller’s Public IP address.
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 2.x Manager and
click Disassociate then Yes, Disassociate in the popup window.
With the same Elastic IP selected click Associate and select the 3.x
Controller instance then click Yes, Associate in the popup window.

15. © 2016
7. Reboot the 2.x/3.x Manager
15
Once the Elastic IP has been associated with
the 3.5 Controller active tunnels (both IPsec
and Overlay Network client servers) will still be
connected to the old Manager. To force the
automatic connect to the new 3.5 Controller
reboot the old Manager from the VPN3/VNS3
Manager UI.
Click the Reboot left column menu item under
the Admin section and confirm you want to
reboot the old Manager 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 ~1-2 minutes.

16. © 2016
8. Review the 3.5 Controller Configuration
16
Once the connections have migrated to the 3.5
Controller validate traffic flow and final
configuration of the 3.5 Controller.
It is recommended you leave the old Manager
running for a 24 hour period in the case you wish
to roll back.
In the event you need to roll back, follow the
steps below.
1.Disassociate the Elastic IP from the 3.5
Controller
2.Associate the Elastic IP with the 2.x/3.x Manager
3.Reboot the 3.5 Controller

17. © 2016
VNS3 Configuration Document Links
17
VNS3 Product Resources - Documentation | Add-ons
VNS3 Configuration Instructions
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 Troubleshooting
Troubleshooting document that provides explanation issues that are more commonly experienced with VNS3.