VNS3 Version 3.5 Upgrade Guide from 2/3
Introduction
Upgrade Requirements
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).
Upgrade Downtime Considerations
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.
Getting Help with VNS3
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.
VNS3 Upgrade Steps
1. Create a VPN3 Snapshot of the 2.x/3.x Manager
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.
2. Launch a 3.5 Controller Instance
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
3. Log Into the 3.5 Controller
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.
4. Upload the Snapshot to the 3.5 Controller
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.
5. Set the 2.x/3.x Manager only to receive IPsec
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.
Review the 3.5 Controller’s Imported Configuration
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.
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
6. Swap the Public IP or Reconfigure the Overlay
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.
7. Reboot the 2.x/3.x Manager
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.
8. Review the 3.5 Controller Configuration
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.
- Disassociate the Elastic IP from the 3.5 Controller
- Associate the Elastic IP with the 2.x/3.x Manager
- Reboot the 3.5 Controller
###