VNS3 3.5 Upgrade Instructions

Transcription

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

2 Agenda Introduction 3 Upgrade Steps 7 1. Create a VPN3 Snapshot of the 2.x/3.x Manager 8 2. Launch a 3.5 Controller instance 9 3. Swap the Public IP or Reconfigure the Overlay Log into the 3.5 Controller Upload the Snapshot to the 3.5 Controller Set the 2.x/3.x Manager only to receive IPsec Reboot the 2.x/3.x Manager 14 Review the 3.5 Controller's Imported Configuration 15 2

3 Introduction 3

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

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

6 Getting Help with VNS3:net Cohesive Networks offers support and services for VNS3:net version upgrades. Deployment audits, snapshot reviews, and chaperoned upgrade windows can be scheduled with your account representative or by ing Please review the VNS3 Support Plans and Contacts before sending support inquiries related to upgrades. It is recommended that you coordinate your upgrade window with the Cohesive Support Team to ensure resources are in place. 6

7 VNS3 Upgrade Steps 7

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

9 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 AMI_ID_US -n 1 -g vnscubed-mgr OR Launch VNS3 Controller in EU region: ec2run -U 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. 9

10 3. Swap the EIP or Reconfigure the Overlay 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. 10

11 4. 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. 11

12 5. 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. 12

13 6. 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. 13

14 7. Reboot the old 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. 14

15 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. 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! /24 -j ACCEPT New Syntax - INPUT_CUST! -s /24 -j ACCEPT 15

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