VNS3 Release Notes

Table of Contents

Latest Release - Version 6.1.x

Initially Released August 24th, 2023

6.1.9 Release - 12/25/23

  • ENHANCEMENT Locking is now used to prevent more than one “create snapshot” command from running Increased “dev ops” usage surfaced conflict between VNS3 snapshots which might be being created by a UI user, the VNS3ms management system, and an API-driven process. To prevent any overlap, snapshot calls are now sequenced and locking is used to prevent more than one from happening at a time.

6.1.8 Release - 12/20/23

  • BUGFIX: Firewall rules entered into subtables could fail. This has been corrected.

  • ENHANCEMENT Initial, albeit not complete, support for AWS MetaDatav2 Current support does allow using the “optional” flag - but testing via AWS Cloud Trails. Full support of AWS MetaDatav2 in release 6.2.2.

  • OPTIMIZATION Improvements to Border Gateway Protocol (BGP) dynamic configuration management VNS3 manages a wide array of BGP elements without direct user configuration of BGP configurations. Some of the configuration data was only maintained via the underlying subsystem config files, versus being generated from database information. BGP information maintained in the VNS3 database and from that config files are dynamically generated.

6.1.6 Release - 10/31/23

  • BUGFIX: Route advertisements that were not associated with a specific network interface were not being removed from the advertisement list when disabled. This has been corrected and disabled routes are disabled regardless of network interface association.

  • BUGFIX: Firewall rules were not being added to subtables. This has been corrected.

6.1.5 Release - 10/18/23

  • OPTIMIZATION Improvements for LNKe High Availability patterns Changes which now allow LNKe interfaces to have static routes to 0/0

6.1.4 Release - 10/11/23 (BUILD DATE in IMAGE NAME is 20231011)

  • INDUSTRY SECURITY EVENT: Updated to include latest “curl” utility and “libcurl” libraries. Fixes for two CVEs, one with severity high (did not affect VNS3) and one severity low (could affect VNS3) were released. VNS3 6.1.4 has been rebuilt with only difference being these updates applied. More detail on the CVE’s here https://www.cohesive.net/support/security-responses/

6.1.4 Release - 10/04/23 (BUILD DATE in IMAGE NAME is 20231004)

  • OPTIMIZATION: Several redundant routing calls which caused no harm, but added no value were removed.

  • BUGFIX: When creating an IPsec BGP peer, and exiting via the “Cancel” option, we returned an error.
    This has been corrected and you are returned to the IPsec page.

  • BUGFIX: BGP ACLs were ignoring “qualifiers” in “deny” statements.
    VNS3 has integrated route “access lists” and “prefix lists” into a generalized ACL entry. When providing a “ge” (greater than or equal to) or “le” (less than or equal to”) qualifier in a “deny” statement the qualifiers were displayed in the UI, but were not actually entered into the system runtime. “Deny” statements using qualifiers now work correctly. (Example: out deny 172.31.1.0/24 ge 25 le 32)

  • BUGFIX: VNS3 “Link” function required a firewall rule to be entered to allow connections. VNS3 can be a Wireguard or OpenVPN client of another system, including other VNS3 controllers. In order for the connection to work a firewall rule needed to be entered before attempting the connection. This connection rule is now automatically entered allowing the connection response traffic to be received.

  • BUGFIX: Windows Wireguard clients could not connect without removing default “blank” MTU and DNS settings from the configuration. A VNS3 “clientpack” for Wireguard overlay has a standard configuration section, and a Cohesive advanced configuration section. We were leaving an MTU = , and DNS = , blank statement in the standard configuration section which Windows Wireguard clients could not parse. These have been removed.

6.1.3 Release - 9/25/23

  • BUGFIX: Routing issues in multi-controller meshes using Wireguard.
    When using a multi-controller topology, with Wireguard for the overlay mesh encryption (now the default), routing traffic from a client connected to one controller to a client on another controller could have problems. This was due to incorrect internal firewall rule. This has been corrected.

6.1.2 Release - 9/05/23

  • BUGFIX: BACKWARD COMPATIBILITY REGRESSION - Import of OIDC configuration fails.
    The import of OIDC configuration for either VNS3 Admins or VPN Users fails. Newly configured 6.1.1 deployments are fine, but imports of OIDC configuration from 6.0+ can fail. This has been corrected and you have our deepest apologies.

6.1.1 Release - 8/24/23

  • OPTIMIZATION: Roll up of all the changes through 6.0.18.
  • OPTIMIZATION: Updated base operating system.
    VNS3 runs on a hardened Ubuntu OS, currently based on release 20.04.5 with all latest security patches and kernel updates.
  • OPTIMIZATION: Cohesive VPN clients do not need access to the interface with the public IP of the controller for OpenID/Oauth authentication. Native Wireguard(tm) client does not support OpenID authentication but the Cohesive VPN GUI and “cnvpn” command line do support it. In release 6.0.x this required the Cohesive VPN clients to authenticate against the port 8000 control plane of VNS3, which made customers uncomfortable. The client VPN and authentication workflow for the VNS3 Controller have been re-factored so that port 8000 no longer needs to be accessible on the public facing interface. Other Wireguard(tm) clients were unaffected by this in the 6.0.x releases and should not notice any issues as a result of this refactoring.
  • ENHANCEMENT: Additional changes will be noted here shortly.

Release - Version 6.0

Initially Released April 29th, 2022

6.0.19 Release - 9/05/23

  • BUGFIX: BACKWARD COMPATIBILITY REGRESSION - Import of OIDC configuration fails.
    The import of OIDC configuration for either VNS3 Admins or VPN Users fails. Newly configured 6.0.18 deployments are fine, but imports of OIDC configuration from 6.0+ can fail. This has been corrected and you have our deepest apologies.

6.0.18 Release - 8/11/23

  • OPTIMIZATION: Roll up of all the changes from limited releases since 6.0.8.
    Sometimes releases are made to a small subset of customers to mitigate an issue or receive feedback on new capabilities. This is the case with releases 6.0.9 thru 6.0.17.
  • OPTIMIZATION: Refactoring and removal of older api paths.
    Older code paths used prior to VNS3 4.5 were removed.
  • BUGFIX: Editing the Plugin Network with running plugins left the plugins in an uncertain state.
    The “proper behavior” for VNS3 if the Plugin Network is changed while plugins running, is to stop the plugins, and leave them available to have a new network address provided via the UI or API.
  • BUGFIX: 6.0+ releases could improperly import LDAP/Auth settings from 5.x or earlier releases.
    The internal representation of this data was changed, and some older settings imported via configuration snapshot would not import properly. This has been corrected.
  • BUGFIX: 6.0+ releases could NOT properly import “network sniffers” from 5.x or earlier via configuration snapshot.
    The internal representation of this data was changed, and network sniffers imported via configuration snapshot looked correct, but could not be started (without interacting with our support staff). This has been corrected.

6.0.17 Release - 8/1/23 (limited release)

  • BUGFIX: Multiple routing fixes.
    When rebooting, or if a route-based VPN tunnel dropped, BGP route advertisements for that route were not being dropped. When using static route metrics, with the route not going into “main” routing table, disabling/enabling a route could cause it to go into the wrong route table. These conditions have been fixed.

6.0.15 Release - 6/16/23 (limited release)

  • Optimization: Further improvements automatically upgrading plugins with VNS3ms (VNS3 Management System) and Terraform Provider. This is primarily for support of VNS3 Terraform Provider.

6.0.14 Release - 6/1/23 (limited release)

  • OPTIMIZATION: Warn before deleting a firewall rule.
    The UI now warns if you attempt to delete a firewall rule. Cohesive found that it was too easy to select “delete” when the intended UI target was “disable”.
  • OPTIMIZATION: Reset passwords, Reset firewall, Reset admin username, available via User Data at Azure VNS3 instances do not have an email-based password reset/recovery for security reasons. At AWS there has been the ability to reset the API password, UI password, UI admin username, and Disable all firewall rules via a reset command set in cloud “user data”. This feature has been extended to Azure.
  • OPTIMIZATION: Better error handling during “import snapshot” operations, primarily for improvements to VNS3 Terraform provider. During the import of a configuration snapshot into a new VNS3 instance and a subsequent automatic reboot, the ability to programmatically “know” when the VNS3 Controller was available for further configuration could be unclear. The instance will now return a “503” API Not Available error. Further refinements are anticipated as we improve the ability to know initial controller status programmatically.

6.0.13 Release - 6/1/23 (limited release)

  • Optimization: Further improvements automatically upgrading plugins with VNS3ms (VNS3 Management System) and Terraform Provider.

6.0.12 Release - 5/25/23 (limited release)

  • ENHANCEMENT: Initial attempts at recovery of running plugins when using the VNS3ms or Terraform Provider for version upgrades. The VNS3 plugin system is quite powerful allowing any open source, commercial source, proprietary source that can be “containerized” to be run in-path inside your virtual network as opposed to on your virtual network, and controlled with routing and firewall directives. To date, when upgrading to a new virtual image, the new instance needed plugins re-installed by the user. The VNS3ms management system can increasingly perform this function for you.

6.0.11 Release - 4/28/23 (limited release)

  • OPTIMIZATION: Allow VNS3 to advertise 0.0.0.0/0 and receive 0.0.0.0/0 with BGP Peers. The restriction was done as a “safety belt” to prevent inadvertently sending all traffic to a peer, which can cause all connections to break. However, customers made the case for its need. In the UI you are warned when you attempt to allow this configuration.
  • BUGFIX: Error setting BGP access lists. Usage over time could cause an automatically generated ID in BGP access lists to exceed a 32bit number, causing an error where access list entries could not be entered and saved. This has been corrected.
  • BUGFIX: Rsyslog configuration was causing un-needed messages in syslog. This has been corrected.
  • BUGFIX: Fireplace rules imported via snapshot with “-j LOG” target were allowed, but new entry was not parsed successfully.
    This has been corrected. The UI/API now properly parses the “-j LOG” target.

6.0.10 Release - 4/5/23 (limited release)

  • BUGFIX: Issues with “snapshot import” when using VNS3 Terraform provider.
    This release was for customers with early access to Terraform provider.

6.0.9 Release - 3/23/23

  • OPTIMIZATION: Allow larger plugin configuration files. Plugin configuration file size can now be configured, now allowing larger config files if desired.
  • OPTIMIZATION: Break display lines on long firewall rules to prevent need for horizontal scrolling. Firewall rules with many characters did not line wrap nicely for display, this has been corrected.
  • BUGFIX: Marketplace “PeopleVPN” skus had incorrect boot up behavior when using OpenVPN as base VPN (instead of Wireguard)
    This has been corrected. An upgrade to the 6.0.9 Cloud Image is required for OpenVPN-based PeopleVPN.

6.0.8 Release - 2/20/23

  • BUGFIX: Route advertisements failed on reboot for duplicated interface routes with metrics.
    Routes with the same CIDR (10.0.0.0/24 for example) pointing to different interfaces (ipsec_vti1 and ipsec_vti2 for example, with different metrics (1 and 2 for example) that are advertised, were failing to be recovered on reboot. This has been corrected.
  • BUGFIX: Disabled routes on VTI or GRE IPsec interfaces were inadvertently enabled when tunnel resets or reboots occur. This has been corrected.
  • BUGFIX: Enabling verbose logging could disrupt VPN connections
    If this occurs, disable verbose logging, and reset any endpoints or tunnels affected.
    This has been corrected.

6.0.7 Release - 2/10/23

  • BUGFIX (MAJOR REGRESSION): Route failures on reboot
    Routes on VTI interfaces were not being recovered on reboots. When using routing tables other than “main”, any default routes were not being recovered on reboots. When using Wireguard overlay routes were not being recovered for the tun0 interface upon reboot. These have been corrected.
  • BUGFIX: Public IP lookup via cloud metadata fails at Google Compute Cloud
    A code regression caused this to fail and has been corrected.
  • BUGFIX: Firewall rules not being created with unique ids
    When using automation frameworks it is possible that if rules are added too quickly that rules can be created with duplicate ids. This creates “downstream” issues using the API. Rules added via the UI by manual interaction did not suffer this issue. This has been corrected.
  • OPTIMIZATION: Improving definition of “API ready to use” for automation frameworks
    As high volume automation framework use of the VNS3 API increases we are working to refine automation awareness of system state. While it is best practice to wrap API calls with error handling, we have made our customers rely on this too heavily. We have begun a series of steps to make it more clear when the API is ready to use after first boot or reboots.

6.0.6 Release - 1/20/23

  • BUGFIX: Interfaces not correctly displaying historical throughput information
    The interfaces page has a “Tools” section offering a historical throughput table. This table was not being displayed. This has been corrected.
  • BUGFIX: Firewall rules not being created with unique ids
    When using automation frameworks it is possible that if rules are added too quickly that rules can be created with duplicate ids. This creates “downstream” issues using the API. Rules added via the UI by manual interaction did not suffer this issue. This has been corrected.
  • OPTIMIZATION: Improving definition of “API ready to use” for automation frameworks
    As high volume automation framework use of the VNS3 API increases we are working to refine automation awareness of system state. While it is best practice to wrap API calls with error handling, we have made our customers rely on this too heavily. We have begun a series of steps to make it more clear when the API is ready to use after first boot or reboots.

6.0.5 Release - 12/05/22

  • SECURITY-FIX: POTENTIAL RCE by unauthenticated user has been FIXED
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely via port 8000 access in a VNS3 instance of version 5.2.1-5.2.9 and 6.0.0-6.0.4.

    Cohesive is still evaluating the efficacy of filing a CVE but our assessment is this should be ranked as a “High” Risk Rating with a CVSS of 7.7.

    A successful attack requires TCP port 8000 access to a VNS3 controller which could allow an unauthenticated user to inject and execute arbitrary code. Prior to release 6.0.0 our recommendation has been do not allow port 8000 access beyond your operations addresses and Cohesive’s remote support address as appropriate. In 6.0.0+, if using the Wireguard VPN, we have required port 8000 to be open to VPN clients. If using the OpenVPN VPN, normal port 8000 restrictions should apply - which is a strong mitigating factor.

    Affected Products and Version:

    • VNS3 5.2.0-5.2.9
    • VNS3 6.0.0-6.0.4

    Mitigating Actions: Restrict port 8000 access to only your known “allow list” addresses. (Please include Cohesive Remote Support IP 54.236.197.84)

    Solution: Live patches are available from Cohesive Networks (successful patch validated by VNS3 version number appended with “-p1”) for any existing controller. Alternatively upgrading VNS3 to the following versions will eliminate exposure:

    • VNS3 5.2.10 or later
    • VNS3 6.0.5 or later

    Questions? Open a ticket with Cohesive Networks (https://support.cohesive.net or email support@cohesive.net).

  • BUGFIX: Compression display error returned with “describe clientpacks” API call
    When running describe clientpacks API call on a controller configured with Wireguard VPN, an erroneous response would be included because there is NOT a compression option for the Wireguard configuration (there is for OpenVPN configuration).
    This has been resolved.

  • BUGFIX: Pre 6.0 firewall use of “MACRO_CUST” rule with –copy-to improper import
    When importing a “macro cust” rule from a pre-6.0 firewall using the “copy-to” option, that rule was not being imported properly. These imports now work.

  • BUGFIX: Syntax errors in pre-built rules in the NATe and PeopleVPN marketplace offerings.
    A number of the VNS3 offerings in the cloud marketplaces come with pre-built firewall rules for their specific use-case. There were syntax errors in the NATe and PeopleVPN offerings preventing some of the rules from being properly installed. These have been resolved.

  • BUGFIX: Removed “New BGP Peer” option from Policy-based VPN pages
    BGP is not an option over policy-based VPNs and the menu item was in error.

  • BUGFIX: Some older snapshot configurations with Alerts failed to import
    Some saved “Alerts” in configuration snapshots could not import, and then when clicking on the Alerts UI page, a 500 error was seen. This has been resolved.

  • BUGFIX: GRE connections in some older snapshot configurations failed to import
    In this case the GRE interfaces would no longer be visible/available. This has been resolved.

  • OPTIMIZATION/BUGFIX: Increased checks for database busy issues
    As customers are running larger configurations of clientpacks, firewall rules, fwsets, etc there have been some failures importing configuration snapshots due to database locking issues. We have reduced this significantly and continue to work at eliminating these issues altogether - yet still remain “lean” enough to run on cloud “nano” instances.

  • OPTIMIZATION: Redirect from tcp ports 443 and 80
    Some new users of VNS3 do not realize its UI and API runs on port 8000 and would get “hung” using https or http in their URL without a port specification. There is now a redirect page in the UI to provide an explanation and a redirect link.

  • OPTIMIZATION: Improved default firewall rules for LNKe enterprise offering
    VNS3 network platform has an enterprise SKU “LNKe”. It behaves like an AWS Transit-Gateway connector to a VNS3 cloud backbone cluster (federation network), but is multi-cloud, lower priced, and has more direct visibility of traffic and routes. This release has default internal firewall rules allowing tcp port 8000 traffic OUT. Port 8000 out is used by LNKe controllers configured as Wireguard VPN clients to a VNS3 Federation Network.

6.0.4 Release - 11/17/22 (UPGRADE to 6.08+)

  • SECURITY-ISSUE: POTENTIAL RCE by unauthenticated user
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely. Upgrade to 6.0.5. See 6.0.5 release notes above.
  • OPTIMIZATION/BUGFIX: Improvements for LNKe Client
    VNS3 network platform has an enterprise SKU “LNKe”. It behaves like an AWS Transit-Gateway connector to a VNS3 cloud backbone cluster (federation network), but is multi-cloud, lower priced, and has more direct visibility of traffic and routes. This release brings the capabilities that have existed when using “openvpn” as the client side of a “LNK”, to the use of “wireguard” as the client side of a “LNK”.
  • BUGFIX: Inconsistent PSK (pre shared key) behavior on Wireguard-based clientpacks
    Toggling between OIDC (auth) on / off and PSK on/off could create a state where the clientpack configuration file had missing data for the “Endpoint=” part of the configuration. Without this setting, no connection would take place. This has been resolved.

6.0.3 Release - 11/14/22 (Upgrade to 6.0.8+)

  • SECURITY-ISSUE: POTENTIAL RCE by unauthenticated user
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely. Upgrade to 6.0.5. See 6.0.5 release notes above.
  • OPTIMIZATION/BUGFIX: Improvements to Firewall UI for Grouping and FWSets
    Release of some pending improvements for Firewall FWSets (our API/UI wrapper around the Linux “ipset” capability.

6.0.2 Release - 10/27/22 (Upgrade to 6.0.8+)

  • SECURITY-ISSUE: POTENTIAL RCE by unauthenticated user
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely. Upgrade to 6.0.5. See 6.0.5 release notes above.
  • OPTIMIZATION: Improvements to the Wireguard Client “LINKs” function
    Multiple API and UX improvements to the Wireguard Client side of a VNS3-to-VNS3 link. Many of the API enhancements were made for supporting the newly released Cohesive VNS3 Terraform provider for HashiCorp. https://github.com/cohesive/terraform-provider-cohesivenet

6.0.1 AWS Lite Edition Rebuild - 11/11/22 (Upgrade to 6.0.8+)

  • SECURITY-ISSUE: POTENTIAL RCE by unauthenticated user
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely. Upgrade to 6.0.5. See 6.0.5 release notes above.
  • BUILD ERROR: The preconfigured Lite Edition license built into the AWS 6.0.1 Lite release was incorrect. This has been fixed and included in this build with no code changes.

6.0.1 Release - 10/17/22 (Upgrade to 6.0.8+)

  • SECURITY-ISSUE: POTENTIAL RCE by unauthenticated user
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely. Upgrade to 6.0.5. See 6.0.5 release notes above.
  • BUGFIX: Network Sniffer “any interface” regression
    Preview Release fixed an issue introduced into the network sniffer in Beta6.
    This fix did not work for the interface choice of “any”. This has been resolved.

6.0.0 Release - 10/11/22 (Upgrade to 6.0.8+)

  • SECURITY-ISSUE: POTENTIAL RCE by unauthenticated user
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely. Upgrade to 6.0.5. See 6.0.5 release notes above.
  • OVERVIEW: Misc enhancements and bug fixes from Preview Release usage.
  • BUGFIX: HA integration with VNS3 Management System Regression
    Beta6 release introduced a regression preventing proper function of the VNS3 HA functions in the VNS3ms Management System. This has been resolved.

6.0.0 Preview Release - 9/27/22 (Upgrade to 6.0.8+)

  • SECURITY-ISSUE: POTENTIAL RCE by unauthenticated user
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely. Upgrade to 6.0.5. See 6.0.5 release notes above.
  • OVERVIEW: Misc enhancements and bug fixes from beta(6) usage.
  • ENHANCEMENT: Geneve protocol capability added (beta)
    VNS3 can now do basic Geneve connections with other hosts.
  • ENHANCEMENT: VXLAN protocol capability added (beta)
    VNS3 can now do basic VXLAN connections with other hosts.
  • OPTIMIZATION: Improved Firewall Rule entry
    Improvements to the “Add Rule Wizard”
  • OPTIMIZATION: Improved FWset entry
    FWSets now allow descriptions for the addresses entered making tracking of network objects easier.
  • OPTIMIZATION: Improved integration between clientpack tags and FWsets
    A clientpack tag can now be referenced to make all clientpacks with the tag into an FWset.
  • OPTIMIZATION: Improved “add route” capability
    Multiple “add route” or “delete route” calls in parallel could get a database lock error. This capability has better retry logic to reduce this significantly.
  • OPTIMIZATION: OverlayEngine plugin improvements
    Overlay engine now runs using Layer 3 routing vs. the previous Layer 2 approach which allows the container to run with lowered privileges in the VNS3 host.
  • OPTIMIZATION: Plugin catalog now supports versioning coordination with VNS3 host
    Plugins can now be marked as compatible with specific versions of VNS3 allowing better control of the plugin options available within a VNS3 network
  • OPTIMIZATION: New VNS3 home page with improved support accessibility
    Each edition of VNS3 Network Platform (Free/Lite, LNKe, NATe, PeopleVPN, etc) has more differentiation of the information provided on the Home page, as well as a link for receiving onboarding support.
  • BUGFIX: Network Sniffer regression fixed
    Beta6 release introduced a regression preventing proper function of the network sniffer. This has been resolved.

6.0.0 Beta(6) - 8/26/22 (Upgrade to 6.0.8+)

  • SECURITY-ISSUE: POTENTIAL RCE by unauthenticated user
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely. Upgrade to 6.0.5. See 6.0.5 release notes above.
  • OVERVIEW: Misc enhancements and bug fixes from beta(5) usage.
  • BUGFIX: IKEv2 Tunnel home page display errors
    The parsing of the IPsec runtime state for IKEv2 connections had a regression and most of the state information was missing from the tunnel home page display. This has been corrected.
  • BUGFIX: Firewall MASQUERADE-ONCE rules could fail without warning.
    “MASQUERADE-ONCE” is a Cohesive “macro” for SNAT to the address of the gateway interface indicated at the time the rule is installed. This allows the ip address on the interface to change between migrations or stop/start operations and the SNAT to be correct in the new instantiation. This is done vs. using “MASQUERADE” by default for efficiency, yet now falls back to MASQUERADE if the gateway address CANNOT be determined for a specific SNAT.
  • BUGFIX: JWKS keys for OIDC were being cached - and could expire before being cleared from cache causing OIDC logins to fail.
    This has been corrected.

6.0.0 Beta(5) - 8/3/22 (Upgrade to 6.0.8+)

  • SECURITY-ISSUE: POTENTIAL RCE by unauthenticated user
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely. Upgrade to 6.0.5. See 6.0.5 release notes above.
  • OVERVIEW: Misc enhancements and bug fixes from beta(4) usage.
  • BUGFIX: OIDC config for Google Workspaces had regression, was not working.
    This issue has been resolved.
  • ENHANCEMENT: Web UI username can now be reset via AWS userdata
    Similar to other AWS userdata resets there is now “reset_ui_username=”
    By putting a name after the “=” the Web UI username is changed to that value, for example reset_ui_username="bob”

6.0.0 Beta(4) - 7/21/22 (Upgrade to 6.0.8+)

  • SECURITY-ISSUE: POTENTIAL RCE by unauthenticated user
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely. Upgrade to 6.0.5. See 6.0.5 release notes above.
  • OVERVIEW: Misc enhancements and bug fixes from beta(3) usage.
  • OPTIMIZATION: “Edit Description” API call for an IPsec Endpoint improved.
    When using the Edit Description API call for an IPsec Endpoint, the full response showing the edit had in fact succeeded is now returned.
  • BUGFIX: “Addresses” API call returned an error
    This issue has been resolved.
  • BUGFIX: Traffic Pairs “disable” call via API did NOT disable the traffic pair
    The disable operation now works as expected.
  • BUGFIX: Peering multiple 6.0 beta controllers together could fail
    The error condition no longer occurs.
  • BUGFIX: Wireguard Clientpack endpoint address incorrect
    In a peered environment, the clientpack configuration file for a Wireguard address has the IP address of the VNS3 controller it resides on as the “endpoint” to connect to. When a clientpack was regenerated, and synced to other controllers, the clientpack had the endpoint address of the controller where the regeneration happened, when it should be the controller the clientpack resides on. This has been fixed.
  • KNOWN ISSUE: Google OIDC configuration failing for user login
    A regression causes OIDC configuration for Google Business Suite to fail. Okta still works, and fixed in Beta 5.

6.0.0 Beta(3) - 6/25/22 (Upgrade to 6.0.8+)

  • SECURITY-ISSUE: POTENTIAL RCE by unauthenticated user
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely. Upgrade to 6.0.5. See 6.0.5 release notes above.
  • OVERVIEW: Misc enhancements and bug fixes from beta(2) usage.
  • BUGFIX: Clientpack name tags fail to resolve if not “lower case”
    This issue has been resolved.
  • BUGFIX: Missing “Home” page text in Marketplace Free editions
    The missing content has been restored.
  • BUGFIX: Changing plugin network does not recover plugins cleanly
    The error condition no longer occurs.
  • BUGFIX: Network sniffer output too large for UI display approach
    The “grey box” display of network sniffer output is not paginated. It merely loads the output file content from the network sniffer. If the packet capture file is too large it can overwhelm the UI process or even the VNS3 virtual machine itself. The sniffer output size had been increased from its previous size of 3000 packets, and has now been limited to 5 megabytes. The display approach will be refined in a future release.
  • ENHANCEMENT: Add OIDC support for VNS3 Admins
    VNS3 admin authentication can now be set up via an OpenID Connect provider such as Okta. This is in addition to the current LDAP/AD support.

6.0.0 Beta(2) - 6/1/22 (Upgrade to 6.0.8+)

  • SECURITY-ISSUE: POTENTIAL RCE by unauthenticated user
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely. Upgrade to 6.0.5. See 6.0.5 release notes above.
  • OVERVIEW: Misc bug fixes from beta(1) usage.
  • KNOWN ISSUE: Built in Firewall Rule needs “space” character removed.
    There is a set of firewall rules built in for NAT-ing traffic to the Internet. One of them has a space character in it - which we are not removing - causing the rule installation to fail. In the rule below, edit it and remove the space character between NEW and ESTABLISHED.
    “FORWARD -i eth0 -ctrack NEW, ESTABLISHED,RELATED -j ACCEPT”
  • KNOWN ISSUE: Clientpack name tags fail to resolve if not “lower case”
    When naming a clientpack via the “name” tag, a system variable is automatically created for use in Firewall Rules and Firewall “Sets” (FWsets). If the tag value is all lower case characters, resolution succeeds. Mixed case and upper case do not resolve.
  • KNOWN ISSUE: Missing “Home” page text in Marketplace Free editions
    In cloud marketplaces there are pre-built editions with built in licensed capabilities. Upon logging into VNS3, the first page seen is a “home” page with information specific to the edition, along with pointers to documentation and support. This information is missing in the Free Edition.
  • KNOWN ISSUE: Changing plugin network does not recover plugins cleanly
    If the plugin network is edited to change the subnet in any way, while a plugin is running, the expected behavior is for the running container to be removed (with a warning), and the network change to be applied. The current behavior shows an error condition. The workaround is to stop/delete plugins, and re-allocate them after the network addressing changes are made.

6.0.0 Beta(1) - 4/29/22 (Upgrade to 6.0.8+)

  • SECURITY-ISSUE: POTENTIAL RCE by unauthenticated user
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely. Upgrade to 6.0.5. See 6.0.5 release notes above.
  • OVERVIEW: Now with wireguard protocol, new firewall and Plugin Catalog
    While more extensive documentation is in the works, VNS3 Beta has been released in a free edition allowing 5 devices and/or people to use VPN clients that support wireguard protocol, along with the new Cohesive firewall user experience. Newly updated plugins are available in the Plugin Catalog - now also based on updated, hardened, Ubuntu 20.04 container.
  • KNOWN ISSUE: Clientpack name tags fail to resolve if not “lower case”
    When naming a clientpack via the “name” tag, a system variable is automatically created for use in Firewall Rules and Firewall “Sets” (FWsets). If the tag value is all lower case characters, resolution succeeds. Mixed case and upper case do not resolve.
  • KNOWN ISSUE: Missing “Home” page text in Marketplace Free editions
    In cloud marketplaces there are pre-built editions with built in licensed capabilities. Upon logging into VNS3, the first page seen is a “home” page with information specific to the edition, along with pointers to documentation and support. This information is missing in the Free Edition.
  • KNOWN ISSUE: Changing plugin network does not recover plugins cleanly
    If the plugin network is edited to change the subnet in any way, while a plugin is running, the expected behavior is for the running container to be removed (with a warning), and the network change to be applied. The current behavior shows an error condition. The workaround is to stop/delete plugins, and re-allocate them after the network addressing changes are made.

Latest LTS - Version 5.0

Initially Released February 5, 2021

5.2.11 Release - 2/20/22

  • BUGFIX (MAJOR REGRESSION): Route failures on reboot
    Routes on VTI interfaces were not being recovered on reboots. When using routing tables other than “main”, any default routes were not being recovered on reboots. These have been corrected.
  • BUGFIX: Route advertisements failed on reboot for duplicated interface routes with metrics.
    Routes with the same CIDR (10.0.0.0/24 for example) pointing to different interfaces (ipsec_vti1 and ipsec_vti2 for example, with different metrics (1 and 2 for example) that are advertised, were failing to be recovered on reboot. This has been corrected.
  • BUGFIX: Disabled routes on VTI or GRE IPsec interfaces were inadvertently enabled when tunnel resets or reboots occur. This has been corrected.
  • BUGFIX: Enabling verbose logging could disrupt VPN connections
    This has been corrected.
  • BUGFIX: Public IP lookup via cloud metadata fails at Google Compute Cloud
    A code regression caused this to fail and has been corrected.

5.2.10 - 12/5/22

  • SECURITY-FIX: POTENTIAL RCE by unauthenticated user has been removed
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely via port 8000 access in a VNS3 instance of version 5.2.1-5.2.9 and 6.0.0-6.0.4.

    Cohesive is still evaluating the efficacy of filing a CVE but our assessment is this should be ranked as a “High” Risk Rating with a CVSS of 7.7.

    A successful attack requires TCP port 8000 access to a VNS3 controller which could allow an unauthenticated user to inject and execute arbitrary code. Prior to release 6.0.0 our recommendation has been do not allow port 8000 access beyond your operations addresses and Cohesive’s remote support address as appropriate. In 6.0.0+, if using the Wireguard VPN, we have required port 8000 to be open to VPN clients. If using the OpenVPN VPN, normal port 8000 restrictions should apply - which is a strong mitigating factor.

    Affected Products and Version:

    • VNS3 5.2.0-5.2.9
    • VNS3 6.0.0-6.0.4

    Mitigating Actions: Restrict port 8000 access to only your known “allow list” addresses. (Please include Cohesive Remote Support IP 54.236.197.84)

    Solution: Live patches are available from Cohesive Networks (successful patch validated by VNS3 version number appended with “-p1”) for any existing controller. Alternatively upgrading VNS3 to the following versions will eliminate exposure:

    • VNS3 5.2.10 or later
    • VNS3 6.0.5 or later

    Questions? Open a ticket with Cohesive Networks (https://support.cohesive.net or email support@cohesive.net).

5.2.9 - 10/19/22 (Upgrade to 5.2.10+)

  • SECURITY-ISSUE: POTENTIAL RCE by unauthenticated user
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely. Upgrade to 5.2.10 or 6.0.5. See 5.2.10/6.0.5 release notes above.
  • OPTIMIZATION: New VNS3 home page with improved support accessibility
    Each edition of VNS3 Network Platform (Free/Lite, LNKe, NATe, PeopleVPN, etc) has more differentiation of the information provided on the Home page, as well as a link for receiving onboarding support.

5.2.8 - 9/22/22 (Upgrade to 5.2.10+)

  • SECURITY-ISSUE: POTENTIAL RCE by unauthenticated user
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely. Upgrade to 5.2.10 or 6.0.5. See 5.2.10/6.0.5 release notes above.
  • OPTIMIZATION: Versioning support for plugins in plugin catalog
    The Plugin Catalog now supports versioning of plugins across VNS3 versions and plugin versions. Plugin creators can tag their plugins for VNS3 compatibility.
  • BUGFIX/ENHANCEMENT: API “put” of a remote configuration could return incorrect result.
    The workflow for VNS3 automation has a “remote config” flow similar to the Web UI “Remote Config” option. The correct workflow is to call the “put” operation to begin the process, and then do successive “get keyset” operations to confirm the current state, pending until the operation was complete. If instead one called “put” operation repeatedly there was a window of time where it would not return the correct error. The proper response is now provided.

5.2.7 - 8/29/22 (Upgrade to 5.2.10+)

  • SECURITY-ISSUE: POTENTIAL RCE by unauthenticated user
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely. Upgrade to 5.2.10 or 6.0.5. See 5.2.10/6.0.5 release notes above.
  • BUGFIX/ENHANCEMENT: Prevent DB busy errors on route updates via API
    When using automation calling the VNS3 API, successive “add route” or “delete route” calls could get a database error. This has been resolved.

5.2.6 - 8/23/22 (Upgrade to 5.2.10+)

  • SECURITY-ISSUE: POTENTIAL RCE by unauthenticated user
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely. Upgrade to 5.2.10 or 6.0.5. See 5.2.10/6.0.5 release notes above.
  • BUGFIX: Network sniffer output too large for UI display approach
    The “grey box” display of network sniffer output is not paginated. It merely loads the output file content from the network sniffer. If the packet capture file is too large it can overwhelm the UI process or even the VNS3 virtual machine itself. The sniffer output size had been increased from its previous size of 3000 packets, and has now been limited to 5 megabytes. The display approach will be refined in a future release.
  • BUGFIX: Traffic Pairs “disable” call via API did NOT disable the traffic pair
    The disable operation now works as expected.
  • BUGFIX: IKEv2 Tunnel home page display errors
    The parsing of the IPsec runtime state for IKEv2 connections had a regression and most of the state information was missing from the tunnel home page display. This has been corrected.
  • OPTIMIZATION: “Edit Description” API call for an IPsec Endpoint improved.
    When using the Edit Description API call for an IPsec Endpoint, the full response showing the edit had in fact succeeded is now returned.

5.2.5 - 6/04/22 (Upgrade to 5.2.10+)

  • SECURITY-ISSUE: POTENTIAL RCE by unauthenticated user
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely. Upgrade to 5.2.10 or 6.0.5. See 5.2.10/6.0.5 release notes above.
  • ENHANCEMENT: Source-based routing and interface-specific route tables
    Now each interface in VNS3 has its own route table available. For MANY standard use-cases these will NOT be used, but do allow for more complex routing criteria if needed. Users can add routes to these tables and use the special -j LOOKUP firewall target to select which table to use for certain packet flows. (This requires using the “ROUTING_CUST” virtual firewall table designator. In 6.0+ this artifact is removed and -j LOOKUP can be used more naturally.). With the use of this target, routing can be based not only on source/destination address, but any metric which can be distinguished by standard Linux iptables discriminators. Such configurations are useful in situations with overlapping routable subnets or where packet routing by “customer” or by “arriving interface” or port/protocol/payload content is desirable. As such route table can now be designated via UI and API for “add route” and “delete route” operations.
  • OPTIMIZATION: Azure Public IP auto-discovery improvements
    Azure auto-discovery previously could not auto discover Azure “Standard” Public IPs due to limitations in the Azure metadata service. This Azure issue has been resolved and VNS3 auto-discovery now makes use of the Azure improvement.
  • OPTIMIZATION: Reduced plugin permissions inside VNS3 host
    Removed unnecessary default permissions in the underlying VNS3 host operating system configuration to further “harden” the VNS3 controller appliance.
  • OPTIMIZATION: DH31 support added for IPsec pfs groups
    Use pfsgroups=dh31 in the Extra Config box for an IPsec endpoint.
  • DOCUMENTATION: Open Source disclosures updated conforming to GCP needs
    Google Compute Platform Marketplace has specific requirements for open source disclosures which have been updated in VNS3 Web UI.
  • BUGFIX: Controller peering API and UI did not respect MTU settings
    The peering interfaces used their default MTU of 1500. This can now be increased for better use of jumbo frames BUT can cause issues if the MTU setting is laerger than the actual underlying network path.
  • BUGFIX: Connected policy-based tunnel COULD show as dis-connected
    When resetting or bouncing a policy-based tunnel the display information cached for performance reasons could be out of sync with the actual IPsec runtime. We believe this issue has been fully resolved.
  • BUGFIX: Routes applied to a VPN interface (vti interface) could be lost on reboot.
    When adding routes for a VTI interface the user is offered to make a route by selecting a VPN Endpoint name OR the actual VTI interface (ipsec_vti12 for example). Routes configured by specifying the vti interface were not recovered on a reboot. This has been resolved.
  • BUGFIX: Changing plugin system network address gives unhelpful error
    If the plugin network is edited to change the subnet in any way, while a plugin is running, the expected behavior is for the running container to be removed (with a warning), and the network change to be applied. The current behavior shows an error condition. The workaround is to stop/delete plugins, and re-allocate them after the network addressing changes are made.
  • BUGFIX: “Addresses” API call returned an error
    This issue has been resolved.

5.2.4 - 3/17/22 (Upgrade to 5.2.10+)

  • SECURITY-ISSUE: POTENTIAL RCE by unauthenticated user
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely. Upgrade to 5.2.10 or 6.0.5. See 5.2.10/6.0.5 release notes above.
  • SECURITY-FIX/ENHANCEMENT: Fix for CVE-2022-27666
    A vulnerability has been found in the Linux Kernel version 5.16.14 and earlier that can allow a buffer overflow of ESP protocol packets by an AUTHENTICATED administrator or partner/customer connected via AUTHENTICATED/NEGOTIATED IPsec tunnel. No unauthenticated remote buffer overflow, code execution, DoS, or other vulnerability is possible. VNS3 was built with an updated kernel including the patches for this issue.

5.2.3 - 1/04/22 (Upgrade to 5.2.10+)

  • SECURITY-ISSUE: POTENTIAL RCE by unauthenticated user
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely. Upgrade to 5.2.10 or 6.0.5. See 5.2.10/6.0.5 release notes above.
  • SECURITY-FIX/ENHANCEMENT: Fix for CVE-2022-23094
    A CVE was raised against VNS3’s underlying IPsec library where a malicious IKEv1 packet can cause the libreswan server to restart. The latest patched version is NOT vulnerable to this. and is included in this release.
  • ENHANCEMENT/BUGFIX: Includes any changes made in 5.2.2
  • OPTIMIZATION: Firewall restrict IPsec Ports
    Previously the VNS3 Controller by default allowed UDP 500/4500 and Protocol ESP packets from any source address. This made some customer support resolutions easier and more obvious. In this release we now restrict those ports to a source address defined as part of an IPsec Endpoint configuration. As a result future exploit attempts such as CVE-2022-23094 will not be possible (unless attempted by a customer’s network administrator from their edge or IPsec network device).
  • BUGFIX: Plugin Manager data records not removed by reset_defaults operation
    This has been resolved.

5.2.2 - (not released publicly) (Upgrade to 5.2.10+)

  • SECURITY-ISSUE: POTENTIAL RCE by unauthenticated user
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely. Upgrade to 5.2.10 or 6.0.5. See 5.2.10/6.0.5 release notes above.
  • ENHANCEMENT: Dramatically faster peering mesh available for new deployments
    Behind the scenes Cohesive has been building Wireguard tunneling capabilities into VNS3 since late 4.x releases. We are pleased to now offer this to our BYOL customers deploying new topologies. Contact Cohesive support for a license which enables this feature BEFORE any deployment configuration. The wireguard-based mesh can achieve peering throughput very close to the underlying virtual instance NICs. (Hats off to Jason Donenfeld (https://www.wireguard.com)) and the team for an amazing system.)
  • BUGFIX: Upgraded Javascript library to include security patches.
  • BUGFIX: Fixes to un-reported Plugin Manager conditions.
  • BUGFIX: 5.2.1 missing Windows clientpack file
    On 5.2.1 (only) there was an error when referencing the Windows Clientpack (.ovpn) file on the Clientpacks page. The workaround was to use the Linux “.conf” version and rename to “.ovpn”. This has been resolved.

5.2.1 - 11/16/21 (Upgrade to 5.2.10+)

  • SECURITY-ISSUE: POTENTIAL RCE by unauthenticated user
    In testing and code review of our most current release we discovered a real, but very obscure way an unauthenticated user could execute code remotely. Upgrade to 5.2.10 or 6.0.5. See 5.2.10/6.0.5 release notes above.
  • ENHANCEMENT: “Traffic Pairs” to simplify deployment of secure route-based VPNs
    This new feature allows local/remote subnet pairs to be defined via UI or API for a route-based VPN. This is very similar to how policy-based “tunnels” are defined. When using traffic pairs, VNS3 manages the default state of routes and ACLs for those pairs. Additional routing and acl operations are not needed when using traffic pairs. “Traditional” configuration is still supported as originally presented since VNS3 4.4.1. This new approach makes it easier for customers integrating VNS3 into their infrastructure to leave the state management of routes and acls to VNS3, rather than incorporating related state into their database.
  • ENHANCEMENT: In-place installation of plugins via Plugin Catalog
    VNS3 Main Menu now lists “Plugins” –> “Catalog” which allows access to a number of additional monitoring, logging, and security functions provided via plugins. The catalog allows in-place installation inside the VNS3 UI - as opposed to requiring access via the Cohesive Website.
  • ENHANCEMENT: Plugin Dashboard now released
    VNS3 Main Menu now lists “Plugins” –> “Dashboard” which allows simplified access to management of plugins.
  • ENHANCEMENT: Dramatically faster peering mesh available for new deployments
    (Deferred to Release 5.2.2)
  • OPTIMIZATION: “Plugins” replaces “Container” main menu item
    The previous Container submenu items are available via the Dashboard. On the right hand side of display there is a “Developer” menu which provide access to the lower level “Container”, “Images” and “Network” functions for the plugin system.
  • OPTIMIZATION: Ping hosts work for route-based VPNs
    Previously the “ping host” function (sometimes called a VPN Monitor by other vendors) worked only for policy-based VPNs. It now works for VTI and GRE route based VPNs.
  • OPTIMIZATION: BGP event logs available
    BGP event logs for external BGP peers and VNS3 Mesh peers now available via Logging Plugin in /mnt/logs/vns3_connection_logs/bgpd.log
  • OPTIMIZATION: BGP session up/down alerts available
    There are now alerts for bgp session up and bgp session down for BGP peers.
  • OPTIMIZATION: Additional IPsec Parameters
    We “re-allowed” DH22 for customers who refuse to believe it should not be used.
    We now support elliptical curve DH 31.
  • BUGFIX: This release includes all of the fixes in 5.1.1 to 5.1.8

5.1.8 - 11/12/21

  • OPTIMIZATION: Better error handling of failed plugin image imports
    Image imports which failed due to size issues (too big for internal disk) or network interruptions are handled more cleanly, with better error message.
  • BUGFIX: Parsing problem for firewall rules logging to NFLOG target via API
    NFLOG targets which worked via the UI, failed via API
    This has been corrected.

5.1.7 - 10/01/21

  • OPTIMIZATION: Added BGP session alerts
    The VNS3 “Alerts” function allows push HTTPS alerts to popular platforms like Slack, Pagerduty, Microsoft Teams, etc. as well as custom targets. A “bgp session” up/down alert has been added which can send an alert when a BGP Peer session disconnects/connects.

  • OPTIMIZATION: Updated IPsec subsystem - further IKEv2 improvements.
    While Cohesive still recommends against PFS for IKEv2 connections (for interoperability purposes), Cohesive believes it now has very strong IKEv2/PFS support.

  • BUGFIX: Network Sniffers can stop without a stop command being issued.
    VNS3 5.x introduced “named” network sniffers so that multiple users could be running “sniffs” at once, and multiple different sniffs could run at once. A synchronization problem caused them to stop spuriously. This has been corrected.

  • BUGFIX: Mismatched local/remote subnet pairs could disrupt site-to-site VPN
    A bug in the IPsec subsystem could disrupt all tunnels on an IPsec VPN connection if there is a local/remote subnet pair mismatch. Without a misconfiguration, there were no issues.

  • BUGFIX: Firewall “Grey” Box Display Improvement
    The firewall “operating system” or “grey box” display sometimes would not show the “POSTROUTING_CUST” header, making it unclear which part of the firewall the displayed rules were in. This has been corrected.

  • BUGFIX: Inconsistent “topology name” behavior
    When importing from snapshot or using the “remote config” operation - the controller would get the topology name first given to the controller, not any subsequent names. An initial fix for this in 5.1.3 corrected the snapshot import issue, but not the remote config issue. It has now been corrected for both use cases.

  • BUGFIX: Extraneous IPsec log messages for missing BGP peers removed

    VNS3 5.x introduced detailed BGP controls to the UI for VNS3 Mesh topology peers. Previously Cohesive attempted to make this a pure black box for the sake of simplicity. Due to growing topology sizes and additional customer use-cases we now show the same controls as available to VPN BGP Peers. Prior to this release (since 5.1.1) this created an invalid file in the IPsec configuration directory which would trigger attempted BGP connections against the internal loopback 127.0.0.1. While, no harm came to the VNS3 system, the log messages were an annoyance in the ipsec.log files.
    This has been corrected.

5.1.6 - 9/10/21

  • BUGFIX: “Reset Clients” function not working via Status page nor API
    This has been corrected.
  • BUGFIX: Interfaces page was returning “No Data” for the Interface “throughput” report. This has been corrected.

5.1.5 - 7/20/21

  • BUGFIX: Changed behavior in /status and /ipsec/status API calls.
    The performance improvements in 5.1.3 introduced a change in the data returned for each of these API calls. This was unintentional, and the original responses are now returned.
  • OPTIMIZATION: Updated IPsec subsystem - IKEv2 improvements.
    While Cohesive still recommends against PFS for IKEv2 connections (for interoperability purposes), Cohesive believes it now has very strong IKEv2/PFS support.

5.1.4 - 7/7/21

  • BUGFIX: Default route OR 0.0.0.0/0 broadcast incorrectly to topology peers
    The performance improvements in 5.1.3 introduced a bug for VTI route-based VPNs such that in multi-controller topologies, a controller with a VTI IPsec connection would broadcast an improper default route, causing routing issues. This has been corrected.
  • BUGFIX: Network sniffer output files captured in configuration snapshot backups
    With the advent of the new Network Sniffer, in 5.x, the output files were stored in a location where the “Create Snapshot” function picked them up. This could cause failures in snapshot retrieval or High Availability operations in the VNS3 Management System. Workaround to be able to take reasonable snapshot is to stop/delete all defined network sniffers.
  • OPTIMIZATION: Improved support for AD/LDAP groups used for authentication
  • OPTIMIZATION: When using packet monitor type of “conntrack”, byte counts for connection flows are now captured.

5.1.3 - 6/21/21

  • BUGFIX: Incorrect “topology name” retrieved when using “Upload Snapshot”
    When creating a VNS3 topology peer using the Upload Snapshot method, the topology name retrieved would be the first topology name ever assigned to the source controller, not the name assigned to the source controller at the time of the operation.
  • ENHANCEMENT: Speed improvements retrieving Tunnel Status/IPsec Page
    API and UI both improved to more quickly return tunnel status (as seen on Status page) and IPsec information (IPsec page).

5.1.2 - 6/14/21

  • BUGFIX: Some instance launches did not complete correctly
    5.1.0 introduced a timing issue where some on-boot initialization processes did not complete properly. This has been corrected.
  • BUGFIX: Not all connected IPsec subnets properly propagated to peers
    VNS3 topology peers were not receiving all connected subnets from other peers. This has been corrected.
  • ENHANCEMENT: Support for VNS3 as an “aggressive mode” IPsec client.
    This is supported for IKEv1 only currently. Documentation pending.
  • ENHANCEMENT: Plugin Manager Enhancements
    Early “plugin manager” support can be found on the “Action” menu of a running container.

5.1.1 - 6/02/21

  • BUGFIX: This release includes all of the fixes in 5.0.1 to 5.0.8
  • BUGFIX: Firewall comment blocks lost when rules added or deleted via API
    Previously when the API was used to add/delete a rule from the firewall, any comment lines which had been entered via the Web UI were lost. This has been corrected.
  • ENHANCEMENT: Secondary IP Support
    Secondary IP’s are now auto-discovered via metadata at AWS, Azure, Google. They now display in the Interfaces page, and can be tagged, as well as “labeled” - thus allowing them to appear as traditional sub-interfaces (“eth1:10” for example). Additionally, corresponding static IPs are also discovered and shown next to their related secondary IP.
  • ENHANCEMENT: Firewall connection tracking can now be reset by administrators
    There is now a “Reset Connection Tracking” link at the bottom of the Firewall page. In rare situations this is required - and we have enabled it to be a self-service operation. Previously customers had to contact Cohesive Support to perform this operation.
  • ENHANCEMENT: Routes can now be disabled via UI and API
    Routes can now be disabled allowing “pre work” for upcoming changes, or the temporary suspension of a route for debugging purposes. Previously a route would have to be deleted, and then re-entered at a later time.
  • ENHANCEMENT: Automatic High Availability for “clientpack” routes
    VNS3’s encrypted overlay is often used as a “machine to machine” VPN as opposed to a “people vpn”. In this use case routes can be entered which target networks/devices “behind” the clientpack address. Cohesive calls these “clientpack routes”. Now a clientpack route to the same target can be entered on multiple peered controllers. Whichever controller the clientpack is connected to, the route is active. If the clientpack drops the connection and reconnects via a different controller in the topology, that route is activated. This allows for interesting HA IoT use cases.
  • ENHANCEMENT: Topology Peers can now have their BGP configuration customized
    VNS3 “topologies” made of two or more controllers, as well as being cryptographic peers, are also BGP peers. The basic configuration occurs as a result of the simple peering commands - and MOST users have not needed to use features such as BGP access controls, or network distance via “ASN prepending”. With the advent of large SASE solutions like Workforce Service Edge, Partner Connect, Customer Connect and MultiCloud Federation networks such tuning became important. We have retained the initial simplicity, but now a “Configure” link is available via the Controller Peering page for customizing the VNS3 BGP Peer relationships.
  • ENHANCEMENT: Improved “drop log” visibility
    A more complete set of DROP log messages can now be seen using our logging container AND turning on the connection tracking packet monitor. By default this functionality is disabled, but can be enabled with a packet monitor of type “conntrack” and name of “conntrack” with a duration of “forever” via the API. Packet filters of this type will be added to the UI in future.
  • OPTIMIZATION: Firewall API now allows the upload/replacement of the full contents of the firewall.
    The Firewall API now allows the equivalent of replacing the entire rule set in one operation - as if copy/pasting a whole set into the Web UI.
  • OPTIMIZATION: Tunnel up/down alerts now have a hardcoded 60 second limit between notifications
    Flapping tunnel down/ups cause too much noise. Now they are limited to one notification every 60 seconds. In future the API and UI will be modified for this to be tuned, and to provide the ability to limit other notification types.
  • OPTIMIZATION: Improved Firewall UI response showing errors or successful update.
    Firewall UI now has a “grey box” display of the Operating System view of the firewall - this view is now better synchronized to the editable UI rule display.
  • OPTIMIZATION: Improved IPsec Page Endpoint UI
    Cohesive moved the IPsec Endpoint display to a tabular form in 4.11. Our reason for doing so was to try to have the same level of simplicity for large scale deployments of hundreds of endpoints as we had for a smaller number. The results were in the right direction in 4.11 - but we continue to make refinements.
  • OPTIMIZATION: Signed certificates uploaded by administrator could not have "” (double quotes) around the Issuer or Subject. The certificate parse operation would fail. This is now allowed.
  • OPTIMIZATION: Configuration snapshots imported into 5.0+ with configuration elements older than 8 years included a 1024 bit DH prime, no longer valid for use with the encrypted overlay network.
    Import snapshot function now replaces this with a 2048 bit DH prime.

5.0.8 – 4/26/21

  • Optimization: API now allows upload of local plugin image
    Previously the Web UI allowed a plugin image file upload from the API caller’s local filesystem. However, the API did not. This has been added to the API.
  • BUGFIX: Improper peer status shown
    On the Status page, peer controllers did not always show correct peering status.
    This has been corrected.

5.0.7 – 4/20/21

  • BUGFIX: Stopped plugin containers would restart on reboot
    In the update of Docker components in 5.0 a required configuration parameter change was not incorporated. This allowed stopped plugins to restart upon reboot. This has been corrected.

5.0.6 – 4/15/21

  • BUGFIX: Firewall rules entered via API can have associated comments.
    Previously the firewall API would eliminate freeform comments from the visual firewall display. In enhancing this feature the API no longer took an insert argument of index “-1” - meaning to put the rule at the top position in the firewall. This has been corrected.

5.0.4 – 4/1/21

  • BUGFIX: Saving BGP Access List information reset BGP session
    With the introduction of “local ASN alias”, where VNS3 can appear to be any BGP ASN to a peer connection, we inadvertently caused a session reset each time access list information was changed. This has been corrected.

5.0.3 – 3/21/21

  • Optimization: Peered controllers allowed to use compression
    Given the configuration and deployment model for the VNS3 full mesh cluster, the controllers continue to use compression with encryption. In future this will be a controllable server setting. This also allow partial peering of 5.0+ VNS3 controllers in a mesh with 4.11.5 and earlier controllers.
  • OPTIMIZATION: Site-to-site Tunnel Up/Down Alert Suppression
    VNS3 supports sending tunnel up/down alerts using web hook technology, allowing alerts to Slack, MS Teams, etc.. Sometimes 2 devices will be so out of “sync” that a tunnel can be set up and torn down dozens of times per second. This creates extra system load and annoyance of “alert storms”. Tunnel up/down events will now onnly be sent a maximum of once per sixty seconds. Future release will allow this suppression time to be customized.
  • BUGFIX: Plugin Network MTU was too large
    The plugin network MTU is supposed to be the MTU of the underlying network where the VNS3 is running. It was set to a default value of 48000, and not updated properly on instance launch. This required workaround rules in the firewall to adjust the MTU on the way in/out of the plugin network. This has been corrected.

5.0.2 – 3/12/21

  • ENHANCEMENT: Web UI and API now allow “Reset Connection Tracking”
    The VNS3 Platform firewall now allows the administrator to reset the connection tracking system. This clears out all “memory” of destination address translations, source network address translations, and status of open connections being routed by VNS3. Resetting connection tracking is not a common operation, should for the most part be done only when recommended by Cohesive Support, but DOES not cause any significant traffic interruption unless called repeatedly with no delay between invocations.

  • OPTIMIZATION: Site-to-site VPN tunnel flapping - alert suppression
    Sometimes a site-to-site VPN configuration can be so out of synch, that the two sides of the connection connect and disconnect many times per second. If using the tunnel up-down alert types - this is problematic. Now the tunnel up-down events are sent a maximum number of 1 time per minute. In a future release the API and UI will allow an alert to be “snoozed” for a specified duration, as well as allow customized suppression time durations on a per alert basis.

  • OPTIMIZATION: Improved Firewall “Save” experience
    The VNS3 Platform firewall now provides better feedback when the firewall is updated and successfully “saved”. It also does a better job of highlighting malformed firewall rules which need correction.

  • OPTIMIZATION: Improved Plugin/Container name handling
    Container Names in the VNS3 plugin system are not allowed to have whitespace in their names. Rather than showing an error, the system now attempts to convert the name offered into an appropriate format.

  • OPTIMIZATION: BGP Peer Passphrase now visually obfuscated
    When creating a BGP Peer, an optional shared passphrase can be configured. Previously this was seen on the Web UI. It is now obfuscated with “*****", with a “Show/Hide” option next to it in the display.

  • BUGFIX: Edge GRE connections not working on reboot
    Edge GRE connections were not recovered properly upon reboot in VNS3 5.0 and 5.1. The workaround is to enable/disable the Edge GRE interface via the API. This has been corrected.

    BUGFIX: Delete Image issue
    In 5.0 and 5.0.1 if containers had been allocated from an image, and an attempt is made to delete the source image, an error window with confusing HTML occurs. The work around is to stop the containers, delete them, and then delete the image. In 5.0.2, like earlier versions of VNS3, a pop up window offers to stop/delete the containers for you.

  • BUGFIX: Edge GRE interface edit command failed via command line tool
    In 5.0 and 5.0.1 the ruby language-based command line tool (vnscubed.rb) was unable to edit Edge GRE connections successfully. This has been corrected.

  • BUGFIX: Site-to-site VPN “Ping Host” not working
    In 5.0 and 5.0.1 the Ping Host function by which a timed icmp packet can be sent across a VPN tunnel was not working properly. There is no workaround. This has been corrected.

5.0.1 – 2/12/21

  • ENHANCEMENT: 5.0.1 fully compatible with VNS3 Management System
    Initial 5.0 release did not support using the VNS3 Management system High Availability features (Hot, Warm, Cold HA)
  • OPTIMIZATION: 5.0 Platform support for Cohesive PeopleVPN
    5.0 Platform now has a PeopleVPN offering (includes 10 base users at no charge).

5.0.0 – 2/5/21

  • NON-BACKWARD COMPATIBLE: Overlay clients must use a version of openvpn agent and an operating system capable of negotiating with TLS v1.2 or higher.
    Less secure, older versions of TLS will not be allowed.

  • BACKWARD COMPATIBILITY WARNING: Compression is NOW DISABLED on overlay client communication.
    When importing snapshots of old configurations into 5.0+ compression will be disabled AND when clients connect to the 5.0 controller a signal will be sent to them to disable compression. In some cases this will reduce throughput of data from 1gbps+ to approximately 650mbps. Use of compression can be maintained by using an OpenVPN 2.5 client AND calling the “enable compression” API call on the VNS3 controller to explicitly allow the use of compression. While use of compression CAN be a security risk over the open Internet, it is NOT a significant risk in machine-to-machine VPN use-cases “in cloud.” For those use-cases, Cohesive imagines customers would want to explicitly re-enable compression.

  • SECURITY-FIX/ENHANCEMENT: Underlying OS and all libraries upgraded.
    VNS3 5.0 runs on a hardened Ubuntu 20.04 operating system. All underlying libraries and components have been updated.

  • ENHANCEMENT: User Interface Updates.
    While keeping the simplicity VNS3 is known for, significant usability and formatting changes have been made.

  • ENHANCEMENT: Significant improvement in encrypted multicast performance.
    Up to 10 overlay clients, properly configured and using VNS3 MulticastHub, can have bidirectional multicast streams up to 150mbps with virtually no packet loss.

  • ENHANCEMENT: Significant improvements to Network Sniffer.
    Network Sniffer page now allows multiple users to create and monitor packet captures simultaneously. Defined captures can be seen/shared by all users. Easy download in “pcap” format for import into other tools. All monitors self-terminate after 1 hour to prevent overlogging.

  • ENHANCEMENT: Network sniffer on an Interface home page uses identical implementation as Network Sniffer page.
    This functionality creates a cleaner, more consistent user experience.

  • ENHANCEMENT: Routes can now be enabled/disabled.
    Previously a questionable or incorrect route had to be deleted (for the moment at least). This was cumbersome and created opportunity for mistakes to be made. Routes can now be disabled/enabled to make it easier to confirm their efficacy.

  • ENHANCEMENT: Dynamic failover for Overlay Gateway Routes
    Overlay addresses can be used in routes as nexthop gateways to addresses/networks BEYOND the clientpack host. In multi-controller topologies VNS3 did NOT support the routes being dynamically adusted when a clientpack dropped its connection to one controller in a cluster, and re-connected on a different controller. This incredibly useful IOT use-case is now supported.

  • ENHANCEMENT: Routing agent available for systems with python3
    Contact Cohesive for access.

  • OPTIMIZATION: VNS3 Firewall extension “MASQUERADE-ONCE” now supported on any interface.
    Previously MASQUERADE-ONCE only worked with the “outer” primary network interface, usually eth0. It now works properly when other interfaces are specified.

  • OPTIMIZATION: Further improved IKEv2 support

    Full IKEv2 interoperability remains an industry challenge. We continue to improve our support.
    Cohesive still recommends disabling PFS and disabling DPD when using IKEv2.

  • OPTIMIZATION: VNS3 Plugin Manager is now at BETA
    It can be found via the Action menu for a running container.

  • OPTIMIZATION: Controllers can now have individual names, separate from the topology name.
    This reduces the effort of managing multi-controller topologies.

  • OPTIMIZATION: System log retention increased from 7 days to 14 days

  • OPTIMIZATION: Additional kernel memory allocated for network performance

  • OPTIMIZATION: Certificate Authority expiration warning on Clientpacks page
    The initial VNS3 Controller in a topology is a unique, secure, self-signed, certificate authority for the cryptographic credentials used by the overlay. When the certificate authority expires, the overlay network’s communication ability ends with it. There is currently no way for this to be extended automatically without redeploying clientpack configurations to the overlay network hosts. To facilitate readiness for the required maintenance window – a warning now shows on the clientpacks page when a certificate authority is within 6 months of expiration. Initial topologies from earlier releases had a 10-year life, new topologies now have a 20 year life without need for re-deployment. Cohesive is experimenting with enhancements to our “Routing Agent” to become a ‘Clientpack Mgmt Agent’ to eliminate this need in future.

  • OPTIMIZATION: IPsec subsystem makes use of available CPU cores more effectively
    When supporting a large number of IPsec connections, additional cores improve ability to process those connections.

  • OPTIMIZATION: Addition of “OS View”
    VNS3 has multiple “gray box” displays. These indicate that Cohesive is showing the internal information from the operating system WITHOUT any editorial changes or Cohesive “point of view.” The “gray box” view which previously was on the top of the Firewall Page, is now found on an adjacent tab labeled “OS View” on the Firewall Page. There is also now a routing “OS View” on the Routes Page. An upcoming release of VNS3 will allow selection of one of the displayed routing tables as the destination for a route being entered.

  • OPTIMIZATION: Improved experience for providing HTTPS certs
    The HTTPs certs upload experience has been improved. Feedback welcome!

  • OPTIMIZATION: Local ASN Alias for BGP Peering
    The private ASNs (autonomous system numbers) for a VNS3 topology are set by the license configuration as a default, and can be customized as part of the initial configuration. They canot be changed thereafter without resetting the entire configuration via “reset defaults.” This can be complicated if a connecting party has an overlap in their private ASN configurations in their network. Now when creating a BGP peering configuration an ASN “alias” can be provided using any valid ASN acceptable to your connection partner.

  • BUGFIX: Prior versions of VNS3 would delete an interface route to a CIDR if a separate route advertisement for the same CIDR was deleted.
    This erroneous behavior has been corrected.

  • BUGFIX: Topology name gotten via remote config could be wrong.
    When adding another controller to a topology, the most common approach is the “Remote Config” option. If the initial controller had ever had its topology name changed, the remote config operation would still retrieve the initial name. This has been corrected.

  • BUGFIX: Meta data lookup failure for “primary public ip” problems
    VNS3 uses cloud metadata when available to set the public ip of the primary outer interface (usually eth0). When that meta data lookup failed for any reason a “blank” ip was configured internally, which cuased problems especially for IPsec connections. VNS3 now will also attempt to resolve its outer public IP dynamically calling out on port 80 to well known Internet services which provide the source address of the interaction.

  • NEW OFFERING BASED ON VNS3 PLATFORM: NATe dedicated NAT-Gateway providing less expensive alternative to cloud platform offering with NO DATA TAXES.

  • NEW OFFERING BASED ON VNS3 PLATFORM: NATe Free dedicated NAT-Gateway providing free alternative to cloud platform offering with NO DATA TAXES, but limited to 50mbps throughput.

  • NEW OFFERING BASED ON VNS3 PLATFORM: PeopleVPN Free – 10 user vpn supporting LDAP/AD/Gsuite integration and MFA.

  • NEW OFFERING BASED ON VNS3 PLATFORM: McastHub<25, 50, 75, 100> Preconfigured multicast hub for use in a hub-spoke topology, in a single cloud subnet, providing reliable, encrypted multicast among overlay clients.

4.11

4.11.4 – 3/9/21

  • ENHANCEMENT: High Availability use-case for clientpack gateways
    For IoT usecases, and database cluster quorum scenarios, VNS3 allows clientpack addresses to be used as next hop gateways. This now works in paired controller scenarios where a clientpack device can failover from its primary controller to a secondary controller and all the routing to the devices/interfaces BEHIND the clientpack is automatically handled. (KNOWN ISSUE: System reboot may cause inconsistent routing, fixed in 4.11.5.)
  • ENHANCEMENT: Routes can now be enabled/disabled
    Routes entered via the API or the Web UI against interfaces can now be disabled. A disabled route will display on the Web UI as “grayed out”, meaning the route information is in the system database - but is not currently in force in the operating system.
  • ENHANCEMENT: Certificate Authority warning displayed
    The VNS3 controller encrypted overlay network has an internal certificate authority which is used to create clientpacks, and to regenerate them. Older versions of VNS3 had certificates that expired without warning - requiring a remote support operation by Cohesive Networks to extend the lifetime. Now the Status page and Clientpacks page will display a warning if the CA is expiring within 6 months of the current date, leaving sufficient time for a new CA to be provided.
  • OPTIMIZATION: User Interface improvements in IPsec Endpoint display
    Cohesive continues to improve the user experience so it supports small networks with several endpoints, as well as environments with hundreds of endpoints.
  • OPTIMIZATION: IKEv2 improvements
    Latest available IPSec runtime used in the 5.0 release brought to 4.11.x release. Cohesive still recommends AGAINST using PFS with IKEv2.
  • OPTIMIZATION: Cohesive’s firewall directive MASQUERADE-ONCE improvement
    The MASQUERADE-ONCE firewall directive only worked with the outer interface of the VNS3 controller, usually ETH0. The “-o” specifier now allows the specification of any existing interface.
  • BUGFIX: Editing container network address while container running was confusing
    Attempting to edit the network address of a running container was an undefined behavior. Now an attempt to do so provides a warning that the container must be stopped before such an operation is successful.
  • BUGFIX: Password “unknowable” if Cloud metadata query failed
    Initial cloud instance password is derived from data retrieved from the cloud platform metadata service. When there was a failure reaching the metadata service - the initial default password was not set to any knowable value. In the event of metadata failure the initial default password is now “vnscubed” - which is the default value in cloud environments with no metadata service.
  • BUGFIX: Improper route removal could occur
    If a route was entered as an “interface route” AND advertised to BGP, removing the route from the interface would remove the advertisement EVEN if a separate advertisement record existed. In this case the Routes display would show the advertisement, when in fact the system has no such advertisement in force. This has been corrected.
  • BUGFIX: Status page improperly displayed “disabled” tunnels
    Disabled tunnels, which correctly showed as disabled on the IPsec page, showed as “Disconnected” on the Status page. This has been corrected.
  • BUGFIX: Disable tunnel not always successful
    Disable tunnel had a timing issue such that it was possible for a tunnel to not truly be disabled. It would show disabled on the display - while showing connection information because the disable had failed. This has been corrected.

4.11.3 – 9/16/20

  • ENHANCEMENT: Alpha Release of VNS3 Plugin Manager
    VNS3 Plugin Manager makes managing running plugin containers significantly easier.
  • OPTIMIZATION: TLS Cipher support for certain Apple IOS releases
    Some Apple IOS releases will only work with the OpenVPN client application if the server offers TLS-DHE-RSA-WITH-AES-256-CBC-SHA256. This has been added to the VNS3 VPN server configuration.
  • OPTIMIZATION: Firewall FWsets now support LIST types
    VNS3 has a simplifying wrapper on top of the underlying Linux IPset functionality called FWsets. Previously the supported sets were “PORT” sets and “NET” sets. Now “LIST” sets can be made that hold entries of PORT or NET sets.
  • BUGFIX: Problems sending alerts to the Slack webhook endpoint
    VNS3 allows push alerts to be sent to the messaging application Slack. An API change by Slack caused issues with how VNS3 pushed alerts. This has been corrected.

4.11.2 – 8/28/20

  • SECURITY FIX: CVE-2020-8130
    Upgraded underlying component for which no network vector was available, hence no practicable risk.
  • OPTIMIZATION: Support People VPN users authenticating against Gsuite.
  • OPTIMIZATION: “Description” field added to IPsec Endpoint
    Customers have asked for a “note” field to use when creating/modifying an IPsec Endpoint. This allows tracking details about the endpoint; most common use-case is to note the Make/Model/SW Revision of the device being connected to.
  • OPTIMIZATION: Improvements to IPsec Page display
    Over the last several releases the IPsec page was changed to support a much greater volume of endpoints (100s vs. 10s). In doing so some of the simplicity and clarity that existed for smaller deployments regressed. While we have not fully re-captured all of that, significant progress was made, with more to come.
  • OPTIMIZATION: Improvements to Identity Management Page
    Improved layout, tooltips.
  • BUGFIX: Connection status was sometimes wrong on Status Page (although correct on IPsec Page)
    This has been corrected.
  • BUGFIX: API regression in “fetch clientpack” due to parameter name change.
    Original argument was “fileFormat,” which was inadvertently changed to “format”. This affected users of the older tar.gz/zip file retrieval instead of the newer approach of .ovpn or .conf with embedded certificates. Both arguments are now acceptable.

4.11.1 – 6/29/20

  • SECURITY FIX: CVE-2020-15467 / POST packet_monitor iface Validation
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15467
    Mandiant Security discovered that the iface POST parameter was not properly sanitized by the server, resulting in a command injection vulnerability. As a result the Web UI interface of VNS3 is vulnerable to an AUTHENTICATED user gaining access to the VNS3 host.
  • SECURITY FIX: Security Patches to Underlying Software Packages
    None of the underlying issues allowed any actions by non-authenticated users. All of the patches applied protect from actions which are for the most part less severe than any action the administrator can perform with the Web UI itself. CVE-2017-5029, CVE-2017-15412, CVE-2015-8806, CVE-2015-7581, CVE-2016-0751, CVE-2020-7595, CVE-2017-16932, CVE-2017-9050, CVE-2018-14404, CVE-2019-11068, CVE-2018-3769, CVE-2016-6316, CVE-2015-7578, CVE-2015-7580, CVE-2019-16782, CVE-2019-5419, CVE-2016-6317, CVE-2016-4658, CVE-2016-0753, CVE-2015-7577, CVE-2018-1000119, CVE-2015-7499, CVE-2019-16779.
  • ENHANCEMENT: IPsec Subsystem Upgrade
    IPsec subsystem improves IKEv2 support and interoperability focusing on making initial negotiations easier to achieve and tunnels more stable when connecting to devices that exhibit unexpected behavior. This upgrade also includes the Security Fix for CVE-2020-1763: Unauthenticated Denial of Service which was included in version 4.9.2.
  • ENHANCEMENT: IPsec Subsystem AGAIN allows PFS Groups 22-24
    Due to PFS groups 22,23, and 24 being broadly suspect for cryptographic integrity, they had been removed. However, despite these admonitions, some of Cohesive’s customers’ customers insist on this support, so they are again allowed. HOWEVER, COHESIVE RECOMMENDS AGAINST THEIR USE IN THE STRONGEST TERMS.
  • ENHANCEMENT: Alert available for Clientpack connect and disconnect
    The Alert system now allows setting alerts for when any clientpack address is connected or disconnected. For machine to machine encryption use-cases where the network connection should be permanent, this provides critical reliability information.
  • ENHANCEMENT: LDAP Microsoft NPS Server Support
    Added authentication via Microsoft NPS for users connecting to the Overlay Network via clientpack connection.
  • ENHANCEMENT: Stream Control Transmission Protocol (SCTP) now supported
    VNS3 can now route SCTP packets. SCTP is a protocol built on top of IP, making it similar to TCP and UDP, but used only for specific purposes.
  • ENHANCEMENT: Routing support for global Azure WVD deployments
    Updates to VNS3 controllers to support Azure Multi-Factor Authentication for Workforce Service Edge users. Routing support to transit Azure Windows Virtual Desktop traffic with customer encryption through Azure backbone instead of over the Internet.
  • Optimization: Task Status can now be queried before licensing
    Long running jobs return task ids to the API. These task ids can now be queried before the licensing step. https://docs.cohesive.net/apis/vns3/v/4.9.2/#get-task-status
  • Optimization: Multicast Performance
    Increased performance and reduced packet loss for Multicast transmissions at higher throughput. With sufficient number of virtual CPUs the maximum supported rate has gone from 24mbps to 50mbps. Unsupported rates up to 70mbps have been achieved.
  • Optimization: Snapshot creation can now run asynchronously via API
    Snapshot creation now takes an “async” parameter which when true returns a task id, allowing the API caller to monitor for when snapshot creation is complete.
    https://docs.cohesive.net/apis/vns3/v/4.9.2/#create-snapshot
  • Optimization: Separate LDAP groups for VNS3 Administrators and PeopleVPN users.
    The LDAP/Active Directory configuration now allows specifying a group for administering VNS3, and a separate group for authenticating VPN users.
  • Optimization: Support for TLS/LDAPS connection with PeopleVPN
    Additional configuration options for connecting to LDAP/AD
  • BUG FIX: “mesh0” interface displays properly in network sniffer
    VNS3 has “beta” support upon request for using Wireguard technology in VNS3 clusters. The mesh0 interface is used to reference this – but was not displaying properly in the network sniffer.
  • BUG FIX: LDAP
    Various fixes for the LDAP integration including user sort and allowing no password login.
  • BUG FIX: Snapshot Creation Timeout
    The timeout for snapshot creation has been increased to avoid UI error when creating snapshots of long running controllers with large network topologies.
  • BUG FIX: API – POST routes Optional Parameters
    The optional parameters “gateway” and “interface” were creating undefined method errors if not specifically included in the call body with a null value. These parameters are now optional as intended.
  • BUG FIX: API – GET keyset Status Code
    Running Get keyset on an unlicensed controller was was returning an HTTP 200 with an appropriate message (“Must be licensed first.”). The HTTP code has been updated to 404 for better response parsing.
  • BUG FIX: API – PUT keyset Status Code
    Running PUT keyset on a controller that already had a keyset was returning an HTTP 200 with an appropriate message (“Keyset already exists.”). The HTTP response code has been updated to 400 for better response parsing.
  • BUG FIX: API – GET license Missing my_manager_vip
    The return of GET license did not include my_manager_vip. This has been added back to the response.
  • BUG FIX: Clientpack UI Download Re-authentication
    Clientpack files downloaded via the UI no longer require additional authentication. The current authenticated user is now used and the additional password prompt has been removed.

4.9

Initial GA 4.0 – 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.9.2 – 3/30/20

  • Optimization: Alerting available for clientpack connect/disconnect
    The alerting system can now send alerts whether a clientpack has connected or disconnected. This is globally on for all clientpacks - it cannot yet be specific to a single clientpack.
  • Optimization: API call to return “task” status now allowed before controller is licensed
    API operations that have variable runtimes (key generation, snapshot export, etc.) return a task ID that can then be queried to check the API operation for completion. The job status call was not allowed before licensing was complete which meant the “import snapshot” operation for example could not have a status check. Task status is now allowed pre-licensing.
  • Optimization: Pre-configured licenses allowed login before completion
    Some VNS3 offerings have built in licenses which do initial configuration (keyset generation, self-peering) for a pre-determined set of licensed capabilities. It was possible to log into a controller while the initial configuration was running, which could be confusing. The UI now blocks the login and displays a message indicating that initial configuration is still underway.
  • Optimization: Import Snapshot was synchronous, not allowing API status checks
    Import Snapshot API call can now be called with an API parameter :async true, which returns a task id for status checking. This improves VNS3 use with automation frameworks.
  • BUGFIX: “Add Route” API call was improperly parsing the case where no gateway was supplied.
    If there is not a gateway specified the argument was still required with a value of “". Omitting the value attempts to use the default gateway for the subnet. HOWEVER it is best to always provide the gateway address explicitly.
  • BUGFIX: “405” errors not being returned properly
    When a 405 error was hit it was being returned as a 500 Server error. This has been corrected.

4.9.1 – 03/11/20

  • ENHANCEMENT: LDAP/AD Integration
    Added comparable LDAP/Active Directory connectivity as exists in the VNS3ms (Management System). More complete configuration options, better group support, and ability to configure with Google GSuite for controller administrator authentication. Additional support for on-line directory-as-a-service providers like JumpCloud. Better “test connection” feedback.
  • ENHANCEMENT: LDAP/AD user identity integrated to logging
    Now when a controller is integrated to a directory service, admin user’s login name is added to logfiles as operations are performed.
  • ENHANCEMENT: Simple OpenLDAP Plugin allowing a user directory for a VNS3 Controller Topology.
    VNS3 plugin system allows plugins to be loaded into controllers and service chained as needed via firewall directives. Cohesive is adding a simple OpenLDAP plugin to the Cohesive Plugin Library. This is useful for small team deployments and also for training purposes.
  • ENHANCEMENT: Significant ALERTS improvements
    VNS3 4.8.2 introduced the use of “webhook” technologies to allow VNS3 to push alerts to popular collaboration tools and dashboards like Slack, Webex Teams, and OpsGenie. This release adds a more sophisticated “integration builder” for adding push integrations to systems that are not provided as pre-built templates. It also adds a number of new alerts: ‘process_change’ (used when an internal process requires a restart by the autonomics/monitoring system), ‘user_password_change’, ‘controller_reboot’, ‘controller_reset_defaults’, and ‘system_general’ (this will be the initial way to send alerts from custom plugins until a “create_alert_type” API call is introduced.)
  • OPTIMIZATION: Controllers encrypted overlay “vip” address returned via API
    Each controller has a shared address that is the same for all controllers in a topology. That address is now returned with the “describe license” API call.
  • OPTIMIZATION: Updated IPsec Endpoint User Interface
    IPsec Endpoints have now been put into a data table similar to Clientpacks, Images, Containers, and other system objects. This is to allow better management of large numbers (dozens to hundreds) of IPsec Endpoints.
  • OPTIMIZATION: Beta Support for using Wireguard encryption in inter-controller peering
    Wireguard encryption can run at higher throughputs and greater concurrency than the existing implementation. Use of Wireguard in peering currently does NOT support use of UDP Multicast in the topology (including the use of Cohesive Routing Agent)
  • OPTIMIZATION: Preventive mitigation for CVE-2019-20372
    While VNS3 was not at risk from the specific NGINX vulnerability in CVE-2019-20372, the recommended mitigation to NGINX configuration was incorporated.
  • BUGFIX: Some dockerfile builds would fail due to buffer space limits
    The type of internal system call used to build plugins via Dockerfiles or Docker directories could run out of output buffer and permanently hang the build process. While VNS3 plugin system should run pre-built container images, the “build” use case is supported and is now more robust.
  • BUGFIX: API compatibility break broke Cohesive Routing Agent
    Cohesive Routing Agent runs on Linux and Windows hosts allowing them to receive dynamic virtual network route updates. The updates are gotten via a connected-client-only API call which is allowed to get the current controller route table. That API call was broken due to an incompatible change introduced in VNS3 4.5 and is now fixed.

4.8

4.8.4 – 12/2/29019

  • BUGFIX: Change plugin network did not work via UI
    Container network changes can now be made via UI as well as API
  • BUGFIX: Save container as image did not work via UI
    Running containers can now be saved to an image via UI as well as API.
  • BUGFIX: Snapshot Import Issue
    Updated fix from 4.8.3 where occasional snapshot imports would fail to the completely eliminate the potential issue.
  • LIMITATION RESOLVED: MACRO_CUST “copy-to” rule gave an error in the firewall display box
    The error was a false error, and now does not occur.

4.8.3 – 9/26/2019

  • BUGFIX: Snapshot Import Issue. Occasional snapshot imports would result in a hung
    VNS3 controller due to an interface background process running during the import.

4.8.2 – 9/18/2019

  • ENHANCEMENT: Custom Webhooks
    VNS3 controllers can now be configured to send “push” alerts to VNS3:ms, PagerDuty, Slack, AWS SNS, and Webex Teams. Additional pre-defined services will be added in future. Alternatively customers can define their own webhook destinations using a flexible template found via the “Alerts” page.

    The initial alerts notifications are for IPsec tunnel up/tunnel down events. Additional events will be added in future.

  • ENHANCEMENT: New packet monitoring capabilities
    New API calls to create packet filters that run for specific durations, designated via simple text descriptions like “one day”, “10 minutes” or “forever”. “Forever” monitors are captured in snapshots and begin running when migrated into a new instance or after a reboot of existing instances. The calls are create_packet_monitor, start_packet_monitor, stop_packet_monitor, delete_packet_monitor. There are 3 filter types; PCAP, Netflow, and Conntrack. There are two output types “file” and “destination”. The file destination allows PCAP captures to be downloaded for later analysis, the “host” designation allows setting an IP address and optional port for delivery of netflow data to a host for analysis. See the 4.8.x documentation for more details. Connection tracking (“conntrack”) type is sent to /mnt/logs/conntrack.

  • ENHANCEMENT: Use of cloud meta-data for improved default passwords
    The default username / password for VNS3 at AWS is vnscubed/instanceid.

    This was done via meta-data on AWS but meta-data was NOT used at Azure and Google (as well as clouds lacking meta-data), with then a default password of “vnscubed”. Meta-data is now used for Azure and Google as well. The default password for Google VNS3 instances is now instance id as well, with the instance id easily copy/pastable via the Google portal. Unfortunately Azure does not make the virtual instance id easily visible anywhere in the Azure portal. As a result the default password for Azure instances is derived from two easily accessible, semi-unique items from the Azure portal; instance name and instance VNET private ip. The specific form is “-”. For example if the Azure instance name is “my-vns3” and the private VNET IP is “10.0.0.9”, the password is “my-vns3-10.0.0.9”. (Note port 8000 for the web ui and API should never be open to “world” 0.0.0.0/0 and please change from the default password upon first access or via DevOps automation and the VNS3 API.)

  • ENHANCEMENT: Use of cloud meta-data for secondary adapter/address discovery
    VNS3 “Interfaces” page is still in Beta, but in this release we have made secondary interfaces, which previously were “auto-discovered” and left in “down” state, make use of meta-data (AWS, Azure, Google) for both private IP and public IP discovery.

  • ENHANCEMENT: Ability to reset Border Gateway Protocol (BGP) subsystem via API and Web UI
    In very rare and non-reproducible instances the BGP subsystem may need to be restarted. To date this required a reboot, or a remote support action by Cohesive support. Although quite rare in need, we have made it visible via a link on the bottom of the IPsec page and the API. NOTE: We recommend NOT using this option unless instructed by Cohesive Support.

  • OPTIMIZATION: Plugin deployments can now have environment variables passed in via the Web UI
    Previously plugins when “allocated” (instance of the plugin image started up and running at an internal VNS3 ip address) could have their environment set via the API, but there was no Web UI facility. This makes it much easier to use generalized plugins that are customized via launch variables passed into the environment.

  • OPTIMIZATION: Filesystem “inodes” now displayed on status page and returned via API status call
    VNS3 uses a hardened Ubuntu Linux base operating system. Linux filesystems have an element known as an “inode” of which there is a very large, but limited number in the filesystem. Although inode exhaustion is an unlikely event for a VNS3 controller, it is now returned as part of the status information.

  • OPTIMIZATION: Removed older encryption and hmac settings from SSH configuration
    VNS3 is a sealed appliance. The only time shell access is utilized is during remote support by Cohesive Networks, and then only if cloud security groups and acls allow access from Cohesive’s well known support public ip, and only if the “Remote Support” enabled is toggled “on” via Web UI/API, and only if there is a unique, short lived, passphrase protected, key installed. That said, Cohesive has removed older ciphers, key exchanges, and hmacs.

  • BUGFIX: Snapshot Import default password issue (affecting 4.6.1 only)
    When importing a configuration snapshot from any prior release of VNS3 into 4.6.1, there was a mistake in the workflow for the case where you did NOT change the password of the new instance. When importing a snapshot into a new instance that has the default initial password, the password embedded in the snapshot should be established in the new instance as the required password. This was not being done, the default password was left in place. This has been corrected.

  • BUGFIX: Exported plugin images were not being gzipped
    When exporting a plugin container as a new image, the export (tar filesystem of the running container) was previously gzipped in background as system resources were available. The kernel patches previously deployed to mitigate against the Meltdown and Spectre attacks had an unanticipated impact on the library used to background the gzip task, preventing it from running with proper permissions. This has been corrected.

4.6

Initial GA 4.0 – 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.6.1 – 6/11/2019

  • ENHANCEMENT: Restructured API system. VNS3 4.5.0+ come with a redesigned API system.
    The purpose of the redesign is to support improved authentication and federated support capabilities. It lays the groundwork for versioned APIs in future.

  • ENHANCEMENT: Revokable and extensible API tokens (including management integration with VNS3:ms).
    VNS3 4.5.0+ has API calls and user interface support for the Admin user to generate timed API tokens. The api tokens can have a description, be searched, expired, deleted and can also auto-expire based on time, as well as refresh before expiration based on time and usage. API tokens can also be managed on the controller via the VNS3:ms management system.

    Using curl with a URL a desc_config call looks like this:

    curl -k -X GET -u api:myAPIpassword https://controller_ip_address:8000/api/config

    It now supports using an API token, “-H api-token:the_token”, replacing the -u argument:

    curl -k -X GET -H api-token:n5v5nf4uc74upteo1v1 https://controller_ip_address:8000/api/config

    Using the VNS3 command line tool (Ruby-based) a desc_config call previously looked like this: vnscubed.rb -H controller_ip_address -K api -S myAPIpassword -T desc_config

    It now supports using the -T parameter, replacing the -K and -S: vnscubed.rb -H localhost -T n5v5nf4uc74upteo1v1 desc_config

  • ENHANCEMENT: Timed Access URLs for Web User Interface (including management integration with VNS3:ms).
    VNS3 4.5.0+ now includes timed access URLs for providing federated (and “communicable”) access to the VNS3 controllers administrative user interface. The access URLs can have a description, be searched, expired, deleted and also auto-expire based on time. Unlike API tokens (for machines or processes), the access urls (for people) cannot have their lifetimes extended. Access URLs can also be managed on the controller via the VNS3:ms management system.

  • ENHANCEMENT: Push Alerts to popular collaborative services, Push Alerts to VNS3:ms.
    VNS3 controllers can now be configured to send “push” alerts to VNS3:ms, PagerDuty, Slack, and Webex Teams. Additional services will be added in future. The initial alerts which can be configured are IPsec tunnel up/tunnel down events. Additional events will be added in future. A generic “webhook” capability will be added in future.

  • OPTIMIZATION: VTI interfaces for route-based VPN using BGP peering can use /31 (2 address subnets).
    Previously Cohesive had documented a requirement for the connected interfaces to be the interior two addresses of a /30 subnet. The two addresses of a /31 can be used, with one address used for each side of the connection.

  • OPTIMIZATION: Firewall rules now support common “MARK” rule patterns.
    The VNS3 firewall is a simplifying wrapper around Linux IPtables. Previously CONNMARK patterns were supported, but not “MARK” patterns, which are now supported.

  • OPTIMIZATION: BETA support for terminating IPsec connections on multiple interfaces.
    VNS3 supports multiple external interfaces via adding/confugring another cloud interface with a public IP mapping (like AWS EIP). Using a “compat” keyword in the Extra Config params allows using these interfaces for IPsec edge connections. In Extra Configs enter “compat:left=the_private_ip_of_the_additional_interface_on_vns3”. You will then also need to add a “local-peer-id” entry into Extra Configs as well, “local-peer-id=the_public_ip_of_the_additional_interface_on_vns3”. Cohesive has tested a number of use cases for multiple interface support - but we assume Cohesive and Cohesive customers will discover some which are not fully supported.

  • BUGFIX: VNS3 4.5.0+ has been “trailing” behind the 4.4.x releases and has all bug fixes from that release path incorporated.

4.4

4.4.3 – 4/14/2019

  • BUGFIX: clientpack import problems where snapshot that was created in 3.x, imported into 4.x then imported into 4.4.1/4.4.2.

4.4.2 – 3/19/2019

  • BUGFIX: edge_gre connections, currently created by UI only, were being reaped too aggressively by the system autonomics, causing flapping behavior. This has been corrected.
  • BUGFIX: “Reset Client” for overlay clients was failing due to a change in an underlying library between releases. This has been corrected.
  • BUGFIX: Backward compatibility problem with create_ipsec_endpoint call. The “no op” use of “gre”:”false” incorrectly threw an error. This has been corrected.
  • BUGFIX: When using the POST /api/ipsec/endpoint/:id API call to reset all Security Associations for a specific Endpoint (Phase1 SA and all tunnel Phase2 SAs) IF the endpoint is configured to IKEv2, the reset would switch the IKE version to IKEv1. This has been corrected.ENHANCEMENT : Clientpacks page now displays most recent connect/disconnect time for clientpack hosts.

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 is 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 toggle-able field. 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 defaults to a masked form.
  • OPTIMIZATION: 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 easier to recover from failed plugin 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/Lite Editions with default encrypted overlay 100.127.255.192 failed to launch if that CIDR overlapped 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: “Overlay Engine” plugin failed to receive route updates. Overlay engines could NOT receive some broadcast routes from the topology, this has been corrected.
  • API CHANGE: Support for route-based vpn was integrated to the existing “create ipsec endpoint” API. In future VNS3 will have API versioning post 4.5.0 release to make these transition easier. Support for route-based vpn was integrated to the existing “create ipsec endpoint” API call via internal parameter conversion.

Old syntax, the data section of a URL call might be: Policy Based Syntax: ‘{“name”:”policy_ep_1″, “ipaddress”:”54.54.54.54″, “secret”:”testy”}’

Policy Based Syntax with ‘no-op’ “gre”:”false”: ‘{“name”:”policy_ep_2″, “ipaddress”:”55.55.55.55″, “secret”:”testy”, “gre”:”false”}’

Route Based using GRE encapsulation: ‘{“name”:”gre_ep_1″, “ipaddress”:”56.56.56.56″, “secret”:”testy”, “gre”:”true”, “gre_interface_address”:”192.168.105.1/30″}’

In 4.4.0+ the change to create_ipsec_endpoint API these calls are internally converted to:

Policy Based Syntax: ‘{“name”:”policy_ep_1_new”, “ipaddress”:”54.54.54.54″, “secret”:”testy”, “vpn_type”:”policy”}’

Policy Based Syntax with ‘no-op’ “gre”:”false”: ‘{“name”:”policy_ep_2_new”, “ipaddress”:”55.55.55.55″, “secret”:”testy”, “gre”:”false”, “vpn_type”:”policy”}’

Route Based using GRE encapsulation: ‘{“name”:”gre_ep_1_new”, “ipaddress”:”56.56.56.56″, “secret”:”testy”, “vpn_type”:”gre” “route_based_int_address”:”192.168.105.1/30″}’

Prior to 4.4.0 and 4.4.1 – the policy_ep_2 example worked. In 4.4.0 and 4.4.1 it gives an invalid parameter error because it was incorrectly converted to new syntax in the form of example policy_ep_2_new, which is incorrect. It should be converted to: ‘{“name”:”policy_ep_2_new”, “ipaddress”:”55.55.55.55″, “secret”:”testy”, “vpn_type”:”policy”}’

Note also: 4.4.0+ now support defining route-based vpn via VTI like this: “{“name”:”vti_ep_1_new”, “ipaddress”:”57.57.57.57″, “secret”:”testy”, “vpn_type”:”vti”, “route_based_int_address”:”192.168.108.1/30″, “route_based_local”:”0.0.0.0/0″, “route_based_remote”:”0.0.0.0/0″}’

4.3

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: Allow nat-t/native autodiscovery in site-to-site IPsec connections. When VNS3 4.x was released we decided to allow devices to auto-negotiate for NAT-T (UDP 4500 encapsulted 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: Able to delete failed plugin imports. 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. Some arguments were being parsed differently breaking compatibility. This has been corrected.
  • BUGFIX: Bad Native IPsec setting via snapshot import from version 3.x or 3.5.x A Native IPsec (Protocol 50) site-to-site IPsec connection would be configured to use NAT-T upon import. 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: Encrypted overlay network on VNS3 CAN now 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: Improved IKEv2 support. VNS3 is best as the “rekey responder” by having phase1 and phase2 lifetimes on the connecting side less than the lifetimes on VNS3, thus driving the rekeys of the connection. BROADLY industry interoperability for IKEv2 is very poor. With each release Cohesive expands its support for interoperable IPsec connections with IKEv2. Cohesive is committed to broad IKEv2 support.

4.3.9 – 4/23/2018

  • OPTIMIZATION: Reverted “tunnel bounce” timer to longer setting. 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: Plugins allowed to write to /mnt/logs. 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. Example:

    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 attmepted 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:” 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

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.

3.5 GA

GA - 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.
  • BUGFIX: The reset_defaults defaults feature was incorrectly reverting the API password to the original default.
  • BUGFIX: 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:
  1. Download current snapshot from existing VNS3 instance.
  2. Launch replacement instance in same cloud VPC/VLAN and Security Groups/Port Filtering mechanisms.
  3. Re-map public IP from existing instance to the new instance.
  4. Reboot the new instance and access it’s web UI via the new address to ensure mapping has completed.
  5. 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 categories 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.

3.5.0.2 – 4/30/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.

Table of Contents