VNS3 Release Notes

Version 4 GA – September 29, 2016

VNS3 Version 4 is a major release in the lifecycle of the VNS3 product family.  Version 4 will be the foundation for a sequence of feature dot releases in the near future.  The initial version 4.0 release focuses on updating the 3.5 product line in preparation for the upcoming feature additions. Here is a summary of those changes.

4.4.1 – 12/23/2018

  • ENHANCEMENT : Clientpacks page now displays most recent connect/disconnect time for clientpack hosts.
    When a clientpack host connects or disconnects to/from a controller, that timestamp is now kept and displayed.
  • ENHANCEMENT : Clientpack hosts can now connect to VNS3 controller via multiple ciphers.
    Previously the VNS3 TLS server only supported one cipher, for example BF-CBS or AES-CBC, which was required to be the same on all connecting hosts. Now when importing from an old deployment – all of the existing clients will connect, but they can be upgraded to newer encryptions one by one.
  • ENHANCEMENT : Edge GRE now supported
    VNS3 has allowed GRE (Generic Routing Encapsulation) over VPN tunnels to create route-based VPNs. Now GRE connections can be made (currently API only) from VNS3 edge, without the need of an encrypted tunnel. The GRE connection to other devices supporting GRE is not encrypted but allows the creation of a tunneled layer-2 link between two hosts. Some network administrators use this mechanism to get “up and over” the limitations of cloud edge gateway constructs without the overhead of encryption (for example over a Direct Connect or Express Route)
  • OPTIMIZATION: Site-to-site configurations can use “mtu=” keyword
    In site to site connections “mtu=” can now be used in the Extra Confgis entry box to control maximum transmission unit (MTU) for both policy-based tunnels and route-based tunnels.
  • OPTIMIZATION: Site-to-site configuration can use “local-peer-id=” keyword.
    In site to site connections “local-peer-id=” can now be used to control the Local IKE id. By default in VNS3 it is the IP address found on the IPsec page as “Local Private IP”. “local-peer-id=” can be used in the Extra Config entry box to override the Local Private IP with an address, a string, or fully qualified domain name.
  • OPTIMIZATION: IPsec tunnel pages now show bytes in/bytes out
    On an Ipsec tunnel “home page” bytes in/bytes out is now displayed. Using the “Refresh” menu on the page updates these fields as the lifetime counters already do. NOTE: When a tunnel rekeys, these values are reset to 0.
  • OPTIMIZATION: Reset Endpoint capability now on Web UI
    The phase 1 Security Association (SA) and any phase 2 SAs of a single IPsec endpoint can all be reset via the “Reset Endpoint” link on the IPsec page.
  • OPTIMIZATION: Allow use of 32bit private ASNs in BGP Peering
    Previously VNS3 could only use the standard private BGP ASN (Autonomous System Number) of 64512 – 65534, as well as the allowed public ASN ranges. VNS3 now supports the larger 32 bit range of 4200000000 – 4294967294.
  • OPTIMIZATION: PSK now uses a hidden field on page but does NOT require knowing the PSK to save an endpoint definition.
    On the IPsec “Edit Endpoint” page, PSK was used as a “mini page password”, meaning a definition could not be saved without knowing the PSK. This restriction caused many customer issues and at their behest this approach has been removed. NOTE: The PSK, like on most vendor security appliances, can NOW BE SEEN BY THE ADMINISTRATOR, although it is shown in a masked form.
  • OPTIMIZATIONs: Exported plugin images are now available for download more quickly
    Previously compression of exported images did not begin for 10 minutes after export. Compression now begins within 60 seconds of export.
  • OPTIMIZATION: Plugin system now allows imports via type 4 signed URLs
    Amazon has recently begun using type 4 signed URLs for S3 object storage in new regions. The plugin system now allows this via the “Dockerfile URL” and “Image file URL” options.
  • OPTIMIZATION: Plugin system now supports an –environment argument via API
    An API call to start a plugin container from a plugin image now can take the –environment argument. The argument must be a space delimited key=value string, for example –environment = “foo=3 bar=4”. Inside the running plugin container references to “foo” and “bar” will resolve to the values assigned in the string.
  • OPTIMIZATION: Plugin system now easier to recover from failed plugin image imports or failed container launches.
    Sometimes when an image import fails (due to script errors or network resource access for example), the image could not be deleted via UI or API. The delete operation has been improved to cover most cases. The same is true for failed container launches.
  • OPTIMIZATION: Plugin image compressed upload size increased to 2G
    Plugin images imported into a controller can now have a compressed size up to 2G. (This limit being raised to 4G in VNS3 4.5.X)
  • OPTIMIZATION: Plugin system local filesystem uploads show progress display bar
    The display bar for uploads makes it easier to understand the status of large image imports.
  • OPTIMIZATION: Controller Peering Token can now be displayed
    When generating the initial keyset of a VNS3 topology, on its first controller a security token or passphrase is requested. It is then used in future to peer controllers into the topology. Since it is asked for in the UI via the “Generate Keys” workflow step – it can now be displayed on the Clientpacks page via “Show Security Token” link.
  • OPTIMIZATION: Firewall has new target “-j MASQUERADE-ONCE”
    In “metal”, “on premise” firewall devices, rules on an SNAT target are stable as the device rarely, if ever, “moves”. In the cloud, a VNS3 snapshot can be imported into a controller in a completely different cloud underlay, and then its SNAT rules are incorrect. The alternative is to use “MASQUERADE” which has lower performance as it looks up the SNAT address target on every invocation. “MASQUERADE-ONCE” is run when the firewall is installed or restarted using the then current gateway address for an SNAT rule, installed at that time – providing both performance and long term flexibility in cloud.
  • BUGFIX: Broadcasting routes with three “0” octets would fail.
    Routes such as 10.0.0.0/8 would fail to be broadcast properly. Since clouds like Amazon have traditionally not allowed over /16 subnets this was unlikely to occur.
  • BUGFIX: Plugin container startup logs were not showing properly
    When clicking through the link to a running container, on the container detail page, the “Container Log Messages” display was always blank. Those log messages are now displayed.
  • BUGFIX: Disabling tunnel now also stops and “Ping Host” operations.
    VNS3 provides a “ping host” function which allows a background process to act as a “vpn monitor” to keep traffic going over an IPsec tunnel. Previously if the tunnel was “Disabled” the ping host operation would still be running. It is now stopped until tunnel is “Enabled” again.
  • BUGFIX: Free and Lite Editions with default license of 100.127.255.192 for encrypted overlay failed to launch if that CIDR overlaps with Cloud VNET/VPC.
    When a Free or Lite edition detects an address overlap with the cloud “underlay” it is launched in, it attempts to shift the default encrypted overlay to a non-overlapping segment.
  • BUGFIX: When using VNS3 “Overlay Engine” plugin to add more encryption/tunneling CPU cores to a controller, route updates could fail.
    Overlay engines could NOT receive some broadcast routes from the topology, this has been corrected.

4.3.11 – 10/24/2018

  • ENHANCEMENT: Traffic accounting on a per tunnel basis has been added. Bytes in/Bytes out is now displayed on tunnel home pages, as well as returned in the “desc ipsec status” API call. This allows monitoring systems to alert on tunnels that MAY have lost synchronization if a steady data stream is expected, or if ping hosts/vpn monitor is allowed.
  • OPTIMIZATION: When VNS3 4.x was released we decided to allow devices to auto-negotiate for NAT-T (UDP 4500 encapsulated IPsec) or NATIVE (Protocol 50/ESP) communication, as this is the industry trend. Customer feedback was negative wanting “declarative” configuration of one OR the other. There has been requests to allow the autonegotiate behavior despite configuration. This can be achieved via using a “compatibility” command to feed the request for auto-negotiation into the underlaying IPsec subsystem via “compat:encapsulation=auto” You will need to test/review this setting for your individual use-cases.
  • OPTIMIZATION: In the Container Plugin system, a container image import or build can fail due to improper firewall rules, dockerfile mistakes, bad image formats, etc. Previously many failed imports could then not be deleted. Most import failures can now be deleted.
  • OPTIMIZATION: Disabling a tunnel should de-activate its ping host. Tunnels can be put in a disabled state. If a tunnel had a defined ping host (VPN “monitor”), the pings would still be attempted even if tunnel was disabled. Correcting this behavior is more consistent, reduces background chatter in network sniffing, and uses fewer system resources.
  • OPTIMIZATION: Firewall error messages have been enhanced. When the firewall system cannot parse an entered firewall rule, the error returned is more complete and descriptive.
  • BUGFIX: DPD scheduling was not always occurring. In 4.3.10 Dead Peer Detection was sometimes not being scheduled and DPD probes were not being sent. This has been corrected.
  • BUGFIX: On the Containers page there is an option to display logs for plugins which are running. The logs were not being displayed. This has been corrected.
  • BUGFIX: 4.3.10 had broken backward compatibility on the “add route” API call with some arguments being parsed differently. This has been corrected.
  • BUGFIX: Import VNS3 Snapshot from version 3.x or 3.5.x would improperly import a Native IPsec (Protocol 50) site-to-site IPsec connection configured to use NAT-T. The remediation was to notice VNS3 using port 4500 instead of Protocol 50/ESP and toggle the configuration button to disable NAT-T. This import problem has been corrected.

4.3.10 – 4/26/2018

  • ENHANCEMENT: 4.3.10 introduces the ability for the encrypted overlay network on VNS3 to overlap with CIDR specifications for subnets on the other side of IPsec connections. Specifically, if the VNS3 encrypted network is a more specific subset CIDR, then traffic within that subnet range stays within that subnet, despite the overlap. For example, a VNS3 encrypted overlay of 10.0.0.0/24 can communicate successfully with a tunnel established for 10.0.0.0/8.
  • OPTIMIZATION: This release improves IKEv2 support for the use-case where phase1 and phase2 lifetimes on the connecting side are driving the rekeys of the connection. BROADLY industry interoperability for IKEv2 is very poor. With each release Cohesive expands its support for IPsec connections with IKEv2. Cohesive is committed to broad IKEv2 support.

4.3.9 – 4/23/2018

  • OPTIMIZATION: In release 4.3.8 Cohesive had shrunk the automatic timer for attempting IPsec tunnel restarts (on disconnected tunnels) to 30 seconds. Post-release usage results showed that this is too aggressive. The previous value was 10 minutes, the new value is 5 minutes (300 seconds). NOTE: If a tunnel is disconnected VNS3 attempts to establish it approximately every 20 seconds. However, if a tunnel has not connected, it is sometimes successful to perform the following sequence, “down” the connection, delete it, add it, “up” it. This is the sequence used by the VNS3 internal monitoring agent, and also by “bounce” API calls.
  • ENHANCEMENT: 4.3.8 introduced the ability for plugins with logging enabled to write to the /mnt/logs directory internally in VNS3. This release extend the “writable” permission to sub-directories of /mnt/logs as well.

4.3.8 – 4/18/2018

  • ENHANCEMENT: AWS Userdata can now be used to reset Web UI Password, API Password, and Firewall
    reset_api_password=thepassword
    reset_ui_password=theapipassword
    reset_firewall=true
  • ENHANCEMENT: Support for adding clientpacks incrementally via API “add_clientpacks” with the “–requested-ips” argument. The requested IP addresses should be in the same format as those used when doing initial key generation. (Example: “10.10.10.1-10.10.10.5, 10.10.10.50, 10.10.10.60, 10.10.10.90-10.10.10.100”) This allows one to license a large overlay, say a /22, and then initially only create the clientpacks needed, as opposed to generating all of them up front.
  • ENHANCEMENT: VNS3 4.x requires either a “blank” Extra Config box where it will try to auto negotiate phase1 and phase2 parameters or it will only accept what it is configured for explicitly and will not accept DH2 inbound requests unless configured on it explicitly. 4.3.8 relaxes this constraint and now prefers the explicit configuration, but if the other side does not match will accept phase1 = aes256-sha1;dh14, aes256-sha1;dh5, aes128-sha1;dh5, aes128-sha1;dh2, 3des-sha1;dh2, aes128-sha1,aes256-sha1″ and phase2 = aes256-sha1, aes128-sha1, 3des-sha1. The next release of VNS3 will include a configuration parameter “cryptography-mode” accepting the values “strict” or “permissive” (and in future “fips”)
  • ENHANCEMENT: Clarification of plugin behavior. Previously if you delete a plugin image via UI or API, which has allocated containers, you were allowed to delete the image. This would then cause problems if you attempted to stop/start the allocated containers or a reboot occurred. In the UI your are now warned that your allocated containers will be deleted, and must confirm to proceed. In the API the operation will fail unless you use the non-default –force argument.
  • ENHANCEMENT: Autonomics now attempts to restart IPsec tunnels in disconnected state every 30 seconds instead of previous 10 minutes.
  • ENHANCEMENT: Encrypted overlay key re-generation now takes place parallel to other backgrounded API calls. Large overlays keysets being regenerated could effectively create a self-denial-of-service with other API calls queued up behind the key generation.
  • ENHANCEMENT: VNS3 configuration snapshots containing firewall rules in the pre-3.0 format are automatically converted to the up-to-date firewall format. Previously these rules were dropped.
  • ENHANCEMENT: “Inactive Due to Syntax Error” on the IPsec Endpoint page now display information about the element(s) causing the error.
  • ENHANCEMENT: Encrypted overlay hosts connecting to a VNS3 controller will no longer see an extraneous “Error adding route” message in their log file. This was an “untrue” error message, and no malfunction had occurred.
  • ENHANCEMENT: Ping hosts can now be disabled/deleted via the API by entering a ping host address of “”.
  • ENHANCEMENT: IPsec tunnels can now be enabled/disabled via the API. Enabled/Disabled status is returned by API call to describe tunnel.
  • ENHANCEMENT: Plugins can be created using Dockerfiles and Docker “context directories”. Docker context directories can now be uploaded in zip and b2 formats, as well as .tar.gz.
  • ENHANCEMENT: Improvements to allow Docker context directories to be uploaded.
  • ENHANCEMENT: Overlay addresses can now be routed via. This allows an overlay host to route traffic to/from its underlying cloud subnet. This is done by entering an interface route via tun0 on the routing page, using the overlay address as the gateway address.
  • ENHANCEMENT: Connection marking is now available via the firewall.
  • ENHANCEMENT: Hash marking is now available via the firewall.
  • ENHANCEMENT: Improvements to vnscubed_monitor.log
  • ENHANCEMENT: Allow individual plugin addresses to have static routes defined for them.
  • ENHANCEMENT: Display format improved for DH groups 19 or higher.
  • ENHANCEMENT: Allow individual plugin addresses to have static routes defined for them.
  • OPTIMIZATION: Most background tasks and asynchronous actions now use microseconds to eliminate the chance for out of order operation based on milliseconds.
  • OPTIMIZATION: IPsec log (ipsec.log) information is no longer repeated in auth.log
  • OPTIMIZATION: Tunnel bounce information not in syslog – a timestamp for the tunnel bounce is put into /opt/vpncubed/runtime/tunnels_down/cft_conn_foo file.
  • OPTIMIZATION: Improvements to ping host.
  • OPTIMIZATION: Improved tunnel home page display.
  • OPTIMIZATION: “clientpack:<password>” removed from Status page. This was previously for access to clientpack configuration files, nw retrieved via Web UI or via API.
  • OPTIMIZATION: Improved SNMP configuration
  • OPTIMIZATION: IPsec page would scan the IPsec log for some of the information about an endpoint only needed on the tunnel home pages. For large number of endpoints this was very slow. Additionally, if the log file grew too large it could cause 502 gateway errors from the API server. All of this information now retrieved from runtime memory, not disk logs.
  • BUGFIX: The IPsec process could create runaway logging entries for phase1 connection problems, filling the logs, potentially exhausting available disk space. This release has a “backoff” approach where if connection cannot be made it pauses between attempts.
  • BUGFIX: Background cleaning of directories was removing files in subdirectories of /tmp/ older than five days old. This could cause failures of plugin imports.
  • BUGFIX: Updated plugin container subsystem (Docker engine) eliminating occasional problems stopping/starting plugins, or rebooting a controller with more than five plugins running
  • BUGFIX: Timing issue fixed where stop/start of a plugin within a 30 second window or less could cause a lost route to the plugin.
  • BUGFIX: IPsec verbose negotiation logging was not being enabled/disabled properly.
  • BUGFIX: Previously in the Web UI data table displays, if you are on a page other than page 1, and perform an operation on an element on that page, at the completion o the operation, the data table would jump back to its page 1 display. It now stays on the page where you performed the operation.

4.3.6 – 2/15/2018

  • VNS3 4.3.6 is a patch release with the same feature set as 4.3.5, but with the industry patches for Meltdown and Spectre, as well as several VNS3 bug fixes.
  • BUGFIX: Updated OS kernel to apply the latest patches for the Meltdown (CVE-2017-5754) and Spectre (CVE-2017-5753, CVE-2017-5715) exploits.
  • BUGFIX: Fix for “lost nat-t internal firewall rule in VNS3 4.0-4.3.5”. In VSN3 4.0-4.3.5 a combination of add/edit/deletes of IPsec endpoints on a controller could cause NAT-T endpoints to lose their connection. This was due to an internal firewall rule being inadvertently removed.
  • BUGFIX: Fixes a bug when running more than 5 VNS3 plug-ins, and a re-boot was required, not all of the plugins would be re-started after the reboot.
  • BUGFIX: Fixes a bug where ping host source IP was not correct. VNS3 has a site-to-site VPN monitor function called “Ping Host” which periodically sends traffic over a tunnel to prevent the connecting party from doing “idle timeouts” of the VPN. When editing the ping host entry for a tunnel, it was possible that the source address was not set for the “ping” command. This could seen visually in the web ui, and required “toggling” the interface setting between eth0 and tun0 in order for it to be properly set.
  • BUGFIX: The “enable” or “disable” status for a site-to-site tunnel was not returned in the tunnel information retrieved via the API call for “desc_ipsec_endpoint”. It is now retrieved. The enable/disable argument to the API call for “edit_ipsec_tunnel” and “create_ipsec_tunnel” was not documented. It will be added to the document available on the web site.

4.3.5 – 1/4/2018

  • Added VNS3 Controller password reset capability at Amazon Web Services via user metadata.
  • Background removal of key state synchronization data now reduces the saved transactions to a 15 day window.
  • BUGFIX: 4.x was not importing some license information for licenses created in 2008 and 2009.

4.3.4 – 11/7/2017

  • Improved CPU load information on the VNS3 Status page.
  • Improved memory utilization information via UI and API by taking into account what the VNS3 linux-based OS is caching/buffering.
  • Changed IKEv1 Native IPsec behavior to behave like VNS3 3.x system wide Native IPsec to reduce upgrade issues.
  • BUGFIX: Regression in the underlying IPsec library where DPD was not always working as expected.
  • BUGFIX: IPsec tunnel description was not being saved when entered via the API.
  • BUGFIX: System log that is made available for the Logging Container plug-in was not being rotated.

4.3.3 – 8/6/2017

  • VNS3 in AWS now defaults to the enhanced network driver for SRIOV support. (This corrects a situation where there can be packet loss on network packets smaller than 125 bytes due to an AWS/Xen bug.)
  • Alpha Release of firewall enhancements supporting customer created subchains and firewall host and port sets.
  • Improved firewall locking
  • Allow container plugins to be retrieved from site with self-signed cert
  • Improved VNS3 snapshot size and performance with the removal of unnecessary log data from the snapshot.
  • VNS3 snapshot files now include NTP data if configured via API
  • Improved handling of cloud underlay address overlaps with networks across an IPsec tunnel.
  • Support for AWS BYOL Marketplace image added
  • Support for Google Cloud Marketplace (Launcher) added
  • BUGFIX: It was possible for a valid overlay certificate to be seen as invalid, not allowing the overlay client to connect.
  • BUGFIX: Status page sometimes did not show the cloud underlay IP address of overlay clients connected to peered controllers
  • BUGFIX: Re-saving cluster peering information could cause a BGP “best path route” to be lost

4.3.2 – 5/21/2017

  • BUGFIX: Checksum mismatch in topology synchronization could occur in 4.0.x – 4.3.1
  • BUGFIX: Upgrade license synchronization could fail in 4.0.x – 4.3.1
  • Beta release of Overlay Engines

4.3.1 – 5/2/2017

  • Increased API throughput
  • Improved cluster performance for topologies with 16 or more controllers
  • Improved firewall performance
  • Improved UI for Routing and Clientpacks
  • Reduced api server default logging level
  • Significantly enhanced dynamic BGP peering capabilities
  • Reduced size of configuration snapshot files by removing unneeded log data
  • Alpha release of “overlay engines” (ability to add more encryption and tunneling cores)

4.0.10 – 3/22/2017

  • Fixed issue with import of VNS3 Snapshot from Controller using default addressing and Clientpack Upgrade License
  • Fixed issue with new IPsec selection between NAT-Traversal encapsulation and Native IPsec
  • Fixed issue with NAT-Traversal NAT firewall rules
  • Upgraded IPsec subsystem

4.0.8 – 1/13/2017

  • Fixed issue with IPsec subsystem restart
  • Fixed issue with internal service listening on port 3001
  • Fixed issue with Snapshot import backward compatibility to allow import of Snapshots created on legacy versions of VNS3
  • Cleaned up default Overlay Addressing to move to sequential default Clientpacks

4.0.1 – 12/23/2016

  • VNS3 UI stylesheet and text updates
  • Cleanup of License and Clientpack files
  • Secured some Clientpack file directories
  • Fix issue with reboot – redirect to home page to avoid possible resubmit of reboot

4.0 – 9/29/2016

  • Update of the VNS3 hardened OS to version 4.0
  • Update of all underlying components of VNS3 including the IPsec subsystem, TLS server, Routing mechanism, Monitor, and Certificate Generator
  • Redesigned UI to take advantage of paginated, sortable and searchable tables for Peered connections, Overlay Network devices, Clientpacks, and IPsec tunnels
  • Improved IPsec controls including NAT-Traversal control on a per endpoint basis, fully supported IKEV2, Exo Ping with selectable source interface, and the ability to disable a tunnel
  • Configurable HTTPS certificates for Web UI and API access
  • Additional Overlay Network authentication and encryption choices for improved security
  • Increased entropy for added certificate generation randomness

Version 3.5 Dot Releases since April 30th, 2014

Beta – April 1st, 2014 | Alpha – January 28th, 2014 VNS3:vpn and VNS3:net had a major release in April 2014, Version 3.5 A series of dot releases have been made since then to address feedback from customers on the overall release, the new L4-L7 Container system and to support VNS3:turret in private clouds and virtual infrastructures.  Here is a summary of those changes.

3.5.3 (LTS) – 7/31/2017

  • Fixed a potential non-reproducible condition where the IPsec subsystem hangs.

3.5.2 – 9/23/2016

  • This release comes ahead of the 4.0 release and will be the “Long Term Server” version for the 3.5 product line.
  • Upgraded IPsec system
  • Bug fixes for the Free and Lite Editions registration and licensing process available in major cloud catalogs.

3.5.1.14 – 3/18/2016

  • This release now allows use of an instance as an HA backup controller via the VNS3:ms system.
  • Disabled SSLv3
  • Relax firewall constraints allowing more customer control using SNAT and MASQUERADE
  • Sorts the Endpoint section of the IPsec page by name, as it is in the Status page table.
  • More robust startup code for secondary network interfaces.
  • Interface Routes now take an optional gateway specification.
  • Overlay server can use jumbo frames when available via change to client side config file.
  • Allow PREROUTING_CUST and POSTROUTING_CUST customer firewall chains to use and valid jump target for the NAT table.

3.5.1.10 – 10/18/2015

  • Increased IPsec interoperability – added support for more Diffie-Hellman groups, additional hashings (sha2_512, sha2_256). Updated IPsec subsystem for increased performance, support and foundation for future IPsec HA features and functions. Memory utilization improvements to support larger VNS3 topologies with more Peered controllers, Overlay Network clients, and IPsec tunnels. Added more error checking to IPsec endpoint configuration page extra configuration parameters box. BUG FIX: The reset_defaults defaults feature was incorrectly reverting the API password to the original default. BUG FIX: License import was incorrectly parsing

3.5.0.8 – 6/3/2015

  • Improved performance of the Status page with a large number of IPsec tunnels. Previously the full status of each tunnel was being retrieved (all of the information seen on a tunnel home page). Now only the necessary status information is retrieved.
  • Restart of SNMP agent by autonomics. Previously if the SNMP daemon crashed a reboot was required to restart it. Now the autonomics agent recognizes the failure and restarts it.
  • Updated logos, links and copyrights for Cohesive Networks
  • Reverted a behavior introduced in 3.5.0.4 where we attempted to streamline the import of VNS3 snapshot into a replacement instance where the IPsec connections were made with native IPsec protocol (ESP / Protocol 50). The new approach did not significantly streamline the process, and created other artifacts. The proper process for migrating a VNS3 instance snapshot to a new instance with native IPsec connections is as follows:
    • Download current snapshot from existing VNS3 instance.
    • Launch replacement instance in same cloud VPC/VLAN and Security Groups/Port Filtering mechanisms.
    • Re-map public IP from existing instance to the new instance.
    • Reboot the new instance and access it’s web UI via the new address to ensure mapping has completed.
    • Import the snapshot file from previous instance into the new instance.
    • It will re-boot, and the migration should be complete.
  • Internal firewall limitation on number of API calls per 5 seconds was increased from 20 to 50.
  • Fixed a bug where the Edit of a tunnel “ping host” or “ping host interval” caused the tunnel description field to be cleared.
  • Added a feature allowing edit of the local or remote subnet of a tunnel. Previously these could not be changed. WARNING: Changing these values will remove the Phase2 IPsec SA and create a new one with the new values. This operation should only be used to correct a misconfigured tunnel that is not carrying traffic.
  • Base VNS3 hardened OS updated with latest security patches.
  • Modified “grub” command line so console output would be seen on AWS HVM images via the “get console log” command. This capability was missing in 3.5.0.7.

3.5.0.7 – 2/2/2015

  • Replaced one of the command-line-based ip address lookup services used outside of clouds with meta data services to get public ip of the VNS3 instance.
  • Added console display of the ip address on the “outer” network adapter, which is usually eth0. This is quite useful in virtualization consoles, or virtual environments without full console support.
  • Routes can now be made which are “advertisements” only, not requiring that there be an attached network to the VNS3 Controller itself, but rather a network the Controller knows how to route to.
  • Fixed a bug where in some cases the Controller would not properly display the “up/down” events on an IPsec tunnel’s home page.

3.5.0.6 – 1/21/2015

  • Fixed bug in multicast retransmitter startup/shutdown.
  • Added better IP address display logic for private-cloud or datacenter-based VNS3 systems.
  • Container UI now lets you upload containers or docker files from local filesystem, eliminating private cloud users from needing URL-accessbile object storage like S3.
  • Improved API support for VNS3:ms and automatic snapshot retention.
  • Updated the working set size of the multicast transmitter to a more “modern” size.
  • Fixed a bug where imported snapshots contained the information for managers added via upgrades – but did not import properly.
  • Fixed a bug where snapshots with pre-3.5 licenses could not receive upgrades which enabled containers, added containers or added container images

3.5.0.5 – 11/23/2014

  • Fixed a bug where using clientpack tags would cause extraneous mesh synchronization events.
  • Remove remote support keys from snapshots, so that they are not included in the snapshot and not imported if they are included in an older snapshot.
  • Fixed a bug where tunnels made without descriptions could cause Web UI display errors or API call errors.
  • Fixed a bug where NAT-ing issues could occur in environments where ETH1 is the “outer” network adapter instead of eth0.
  • Improved support for network overlaps between subnets behind VNS3 and across and IPsec tunnel.
  • Eliminated possible file handle exhaustion problem which was theoretically possibly with large number of tunnels (hundreds).
  • Fixed bug where a BGP route could be lost when doing transitive routing for an Amazon VPC mesh.
  • Improved autonomics of BGP system.
  • Fixed a bug where the autonomics system agent could fail, causing other processes to not be healed/restarted.

3.5.0.4 – 9/2/2014

  • Allow use of signed HTTPS URLs in the docker/lxc container import capability.
  • Improved error handling in create_ipsec_tunnel API call.
  • Re-moved container/image meta-data from snapshots.  Snapshots currently do not include Container information.

3.5.0.2 – 7/16/2014

Fixed omission where Status page stopped displaying “Connected”/”Disconnected” status in green or red as appropriate.

Version 3.5 GA – April 30th, 2014

Beta – April 1st, 2014 | Alpha – January 28th, 2014 Version 3.5 that contains additional features and user-requested updates.  Version 3.5 is currently available in AWS Marketplace and on request.

Fixed Issues

  • Import Snapshot improvements for better compatibility with upgrade/stackable licensing.
  • Runtime Status page load slowness when a large number of IPsec tunnels are connected (introduced in 3.0.4).

New Features

TrendMicro Integration Use both VNS3 and Trend Micro Deep Security central management platform to simplify and streamline security operations. Integrate your security functions across all of your physical, virtual and cloud environments. “Routing Robot” The new “routing robot” keeps your topology connected. The client-side routing agents automatically manages any cloud network modifications by checking the network addresses with  the VNS3 Manager routing agent. Automatic routing saves network operators time and resources while increasing network uptime. Docker Integration VNS3 3.5 now provides the ability to co-create customizable, flexible networks with Docker containers built in, and tailor virtual networking functionality to specific use cases when extending corporate and data center networks to public, private and hybrid clouds. VNS3 3.5 delivers a new way for partners and customers to collaborate on the creation of custom network functions – including proxy, reverse proxy, WAN optimization, load balancing, and more – giving IT teams more control over network security and connectivity. VNS3 OS Update The VNS3 Network OS (specially tuned network specific OS based on Ubuntu) has been updated. Component Updates The components of the underlying VNS3 network stack have been updated to the latest versions and ensuring backward compatibility with all previous supported versions of VNS3. Support for GRE Tunneling VNS3 Manager can now provide Layer 2 Bridging over GRE as well as GRE tunneling over IPsec.  This increases the connectivity options when building hybrid clouds between parties that have connection agreements like AWS direct Connect and Equinix Data Centers worldwide Clientpack Road Warrior Support Features Clientpacks now include a per-pack detail popup that shows connection information, specific log messages for that clientpack and a regenerate clientpack feature.  Quickly and easily regenerate and redistribute any lost or compromised clientpacks to get  remote users up and running. Scriptable Networks Additional Support The Clientpack API call fetch_next_clientpack now allows the user to specify a range of IPs to fetch the next clientpack.  This feature released backed by popular demand as more and more users are building their cloud-based Overlay Networks automatically and on-demand. System Health UI Addition Added displays for basic VNS3 Manager system health information like memory utilization, swap and disk space. Additional Key Randomness Added entropy for added randomness when generating larger key sizes for the Overlay clientpacks. Support Access Improvements Simplified the Multi-party/factor support access allowing customers to easily regenerate new or revoke outstanding ssh credentials.

Version 3.0.4 – November 26th, 2013

Version 3.0.4 will be the last release in the 3.0 line before the upcoming 3.5 release.  This release is an update rollup of the VNS3 across all cloud deployment targets that contains fixes and feature updates.

Fixed Issues

  • Version 3.0.1 clientpack pre-configured addresses inside the .conf and .ovpn clientpack files were not updated in the event of a new public IP address.
  • License upgrades increasing the number of clientpacks where not being imported correctly into newly created snapshot files.

New Features

VNS3 Firewall Upgrade Outbound NAT capabilities have been added to allow VNS3 to replace the AWS VPC NAT AMI. When running Private VPCs you can use your VNS3 Manager in the place of the NAT AMI reducing your deployment complexity and saving the NAT AMI runtime fees. IPsec Tunnel Management Improved IPsec tunnel state to allow for easier management and troubleshooting.  Tunnel home pages now show Phase 1 (IKE) and Phase 2 (IPsec) remaining lifetime.  It also shows the IPsec SA inbound and outbound “SPIs” (Security Parameter Index).  These designations are shared with the connecting endpoint and are useful debugging connection issues. Cloud Consistency Consistency improvements for clouds other than Amazon EC2.  All VNS3-supported clouds are now based off of a common source tree which differentiates cloud environment by configuration settings.  This creates a much more uniform customer experience when federating cloud networks. Larger Web UI Keysize The SSL Certificate for the VNS3 Manager Web UI Server has been upgraded to 2048 bits. Increased Overlay Network Security The overlay network has been enhanced to use a high level negotiation handshake which improves VNS3 Manager resilience against some DDOS attack attacks. Check IN/Check OUT Clientpacks can now be marked as “checked in” or “checked out” via the Web UI.  This functionality was previously only controllable via the API. Shutdown Removal The “Shutdown” link has been removed from the Web UI.  Please use the cloud or virtual infrastructure console to shutdown an instance of VNS3. Browser Topology Naming VNS3 Topology Name now shows up in Web browser title bar.  This makes it easier to work with multiple VNS3 Managers and topologies via the UI. Native IPsec Improved native IPsec interoperability with older (approaching EOL) Cisco routers.

Version 3.0.1 – April 17th, 2013

This is a minor release that contains a bug fix and feature updates.

Fixed Issues

Fixed potential race condition in version 3.0 There is a set of conditions that can cause newly created IPsec Endpoints and Remote Subnet additions to not be appropriately added to the VNS3 IPsec Subsystem. The UI will display the connections, but the tunnels will not be negotiated and will not return any log messages. Version 3.0 users will be contacted separately with patch and upgrade information but are also free to contact support.

New Features

“NAT’ing” Outbound NAT capabilities have been added to allow VNS3 to replace the AWS VPC NAT AMI. When running Private VPCs you can use your VNS3 Manager in the place of the NAT AMI reducing your deployment complexity and saving the NAT AMI runtime fees. Port Forwarding Use your VNS3 Manager as the “front door” to your VNS3 virtual network and your VPC by specifying both port and src/dst IP to allow you to forward traffic to specific hosts protected in your VPC. Enhanced VLAN Support Dual honed network support for clouds that use eth1 for VLAN capabilities (IBM SCE, GoGrid, ElasticHosts, etc.). In these clouds just a click on the “Private VLAN” menu item and enter the VLAN network and gateway information. SNMP Support for the most popular MIBs! VNS3 now provides SNMP support for most major commercial and open source monitoring systems. Network monitoring systems like Zenoss and Cacti. Easier Client Configuration Clientpacks are now available via a single configuration file for Linux/Mac, Windows, iOS and Android target environments. Additionally each clientpack configuration file comes pre-configured with remote entries for the VNS3 Manager already included. Simply load the clientpack to the configuration directory on your cloud servers to join the VNS3 virtual network. No additional configuration necessary. Enhanced Snapshot Management The VNS3 snapshot feature is a powerful means for recovering and re-creating VNS3 Managers in the cloud. Now it has gotten easier allowing you to use the username/password set embedded in the snapshot – or to set new UI and API credentials for you rnew VNS3 installation.

Version 3.0 – September 12, 2012

This is a major release that contains feature updates. VPN-Cubed was rebranded to VNS-Cubed (VNS3) as part of this release.

New Features

Expanded Network Sniffer Functionality VNS3 Network Sniffer (Network Interface Monitor) can monitor either the tun0 (Overlay Network) or eth0 (IPsec Connections) interfaces. IPsec troubleshooting no longer requires intervention from the Cohesive Networks support team. Simply monitor the interface for detailed packet/traffic analysis.

Improved IPsec Tunnel Management Increased visibility of IPsec tunnel status on both the UI and API. Tunnel pages display all negotiated tunnel parameters, encryption domains, tunnel history and log messages for the specific tunnel. The tunnel pages also allow restart and delete of individual tunnels.

License Upgrade Upgrading between Editions or adding capacity to SME/Enterprise now requires no operational window. Upgrades are applied to running Managers via the License Upgrade feature and additions are immediately available.

Updated API Deploy scriptable cloud networks using an expanded REST API. Not only have the number of calls increase to provide greater programatic control over a VNS3 topology, individual calls are now more powerful.

CloudWAN Use your VNS3 topology as your low cost, rapidly deployable global WAN leveraging the globally distributed public cloud data center network. The CloudWAN feature allows users to establish connectivity between multiple endpoints to launch a “telco-ready” network.