Could Continuing AWS Outages Give Rise to Distributed Cloud Deployments? Widespread disruption of high-use internet...
Announcing the Release of VNS3 5.2.1
We are happy to announce that VNS3 version 5.2.1 has been released and is available for deployment in all cloud platforms. Below are some of feature highlights of this release.
AWS Private AMI: users with private AMI access to UL versions will see the 5.2.1 AMI already shared into their account. Filter for Private Images in the appropriate region and search for vnscubed521-20211111-ul-ebs-5LFW.
AWS and Azure Marketplace: all VNS3 Marketplace SKUs are updated with the latest 5.2.1 listings.
GCP and OCI: contact firstname.lastname@example.org for image access.
This release focuses on making our Distributed Cloud (site-to-site VPN and Overlay Mesh) and Plugin user experience easier from implementation to operation. Don’t forget, release notes are always available at https://docs.cohesive.net/docs/vns3/release-notes/.
Over the last few years the world of site-to-site VPN has been moving away from Policy-based IPsec VPN in favor of Route-based. Route-based VPNs, from the POV of the device, have simpler configurations (generally a single tunnel) and as a result can have increased long term stability. Simple and stable is good but Route-based VPNs without associated policies/ACLs can be thought of as ‘IPsec without the sec’ and let any traffic move between the two sites. Traffic pairs simplify the 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.
Many of you have leveraged the VNS3 Plugin System (Container System) to add critical network services in-path to allow full customization of your network edge. Previously container images had to be sourced in from outside storage buckets or uploaded from local storage. VNS3 now provides in-place installation of plugins via Plugin Catalog. The updated 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. To see all our available plugins, please visit the plugins page on our support site.
Additionally the plugin Dashboard is available to provide simplified management of plugins.
You also note that we’ve replaced the “Container” menu items with “Plugins” but don’t worry you can still access the Container submenu items 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.
VNS3 Overlay Mesh Hyperdrive
We’ve seen Distributed Cloud deployments and use cases increase dramatically over the last few years. As a result the need for speed has become increasingly important in both intra-region as well as inter-cloud deployments. In response we’ve workd to dramatically increased the speed of the peering mesh 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. The Wireguard-based mesh can achieve peering throughput very close to the underlying virtual instance NICs. (Hats off to Jason Donenfeld and the WireGuard team for an amazing system.). Contact Cohesive support (email@example.com) for a license which enables this feature BEFORE any deployment configuration.
- 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.
- BGP event logs available for external BGP peers and VNS3 Mesh peers now available via Logging Plugin in /mnt/logs/vns3_connection_logs/bgpd.log
- BGP session up/down alerts available for BGP session up and BGP session down for BGP peers.
- Additional IPsec Parameters – “re-allowed” DH22 for customers who refuse to believe it should not be used and support elliptical curve DH 31.
Any user regardless of subscription SKU or support contract is eligible for upgrade assistance including live upgrade chaperoning by a member of our excellent support team. To schedule your assisted upgrade, open a ticket on our support system (firstname.lastname@example.org) and we’ll ensure a smooth transition.
NOTE: Peering between major versions (e.g. 4.x peered with 5x) can be done but we don’t recommend due to potential stability issues.
Please don’t hesitate to reach out with any comments, questions, or feature requests (email@example.com).