Cohesive VNS3 6.0 Beta3 is now available and free to use in AWS, Azure, and upon request. Get WireGuard(r) performance and encryption along with OIDC authentication, dynamic routing, global deployment capability, and integration to cloud and datacenter connectivity solutions today.
WireGuard® at its core is a lightweight, low code, VPN tunneling protocol that optimizes for speed, security and ease of configuration. However, extended business functions needed for enterprise usage are left out of its code base by design. This non-opinionated approach allows third parties to develop novel methods that best fit enterprise needs and styles.
Examples of Enterprise needs are:
- Key (re)generation and distribution for both human users and machine-to-machine networks
- RESTful API for integration to in-house systems and external services
- Uniform access to encrypted tunneling via regional or global clusters
- Dynamic routing so devices on the WireGuard network learn about network paths as they come and go
- Failover support allowing clients to migrate servers in the event of maintenance or outages
- Integration to security platforms (Firewalls, WAFs, IDS/IPS)
- Integration to other “tunneled” paths (IPsec, GRE, VXLAN, cloud direct connects, etc..)
- Integration to “legacy” monitoring tools like SNMP
- Integration to “modern” monitoring tools like Datadog and Sumologic
- Integration to legacy authentication (Active Directory)
- Integration to modern authentication (OAuth / OpenID, MFA, etc..)
- AND more!
Cohesive is working to make the WireGuard protocol a first order citizen in our VNS3 Network Platform with a focus on many of these extended capabilities.
Enterprises will need methods to securely store and distribute keys to human and machines. Authenticated REST APIs allow automation frameworks to tag and place keys where needed in a distributed computing environment. Self-service web portals give end users access to allocated keys for their various devices. Administrators and intrusion detection systems need the ability to revoke keys when compromise occurs.
Not all tunneling systems and their keys are the same. Many companies employ encrypted overlay networks, in cloud and between their compute nodes in order to satisfy regulatory requirements and gain network visibility. For automated machine-to-machine communications, public/private key pairs are all that is required, whereas with “people VPN” scenarios added authentication factors are needed.
In the dynamic world of cloud networking and remote work, private networks are now fluid, meaning that network address ranges are added and removed, as new networks and subnets come on line or are decommissioned. In order for systems to communicate they need dynamic route updates providing up-to-date paths through interconnected transit networks.
These encrypted tunneling systems are used to take the enterprise, its customer and partners to, through, and across clouds. This requires the WireGuard feature called “Allowed IPs” that acts as both ACL and route directives to be integrated. In Enterprise WireGuard use-cases, the “Allowed IPs” don’t come from a configuration file, they will be dynamically and seamlessly integrated to the broader systems routing and ACL policies. communications in the enterprise. Companies need the ability to filter and direct traffic at ingress and egress points in cloud networks.
WireGuard is fast becoming an essential operating system and developer tool, and Cohesive Networks believes it’s on its way to being an essential building block for creating robust, enterprise-ready network solutions.
“WireGuard” and the “WireGuard” logo are registered trademarks of Jason A. Donenfeld.
Internet Protocol Security (IPSec) is used to encrypt communications between two computers over the internet. Usually it is done between between security gateways to allow two networks to communicate securely. On the data center side this will be done for the most part on physical boxes manufactured by the likes of Cisco, Juniper, Fortinet and others. In the public cloud it is virtualized. Cohesive Networks VNS3 is one such device that allows you to easily configure these secure connections into your cloud private network. Whether you are running a hybrid cloud, are an ISV that needs to connect to customer sites or are implementing a multi cloud strategy VNS3 can provide a stable, secure and simple solution.
VNS3 can manage as many IPSec connections as you need, the only limit is the underlying instance resources. You can scale your VNS3 instance with the number of connections. It supports both policy and route based connections and supports a wide range of algorithms, hashes and Diffie-Hellman groups. In short, VNS3 can connect to just about anything out there. It’s highly configurable design lets you match exactly what it is communicating with. This all makes VNS3 a very stable solution.
Setting up VNS3 is a breeze. You can launch it out of your cloud vendor’s marketplace and pay by the hour, or contact Cohesive Networks for longer term billing. VNS3 should be placed into a public subnet. Once launched you will need to either in AWS, turn off source destination checking, or in Azure, enable IP Forwarding on its network interface. In AWS you should attach an Elastic IP (EIP) to it or in Azure a Public IP Address. Once it is up you can manage it via its web interface. You will need to open up TCP port 8000 in your security group. Then open a browser and go to:
The default admin username is: vnscubed
In AWS the default password is the instance id, in Azure the default password will be the virtual machine name followed by a hyphen then the private ip (ex. MyVNS3-10.0.0.1)
Once you have logged in you should change the admin and api passwords.
The IPSec configuration page can be found under the Connections section on the left hand side contextual menu. From there you will want to click on the “New Endpoint” button and will see the IPSec configuration form.
Now it is just a matter of filling in the parameters for the endpoint you will communicate with. Typically you and the other party will agree upon a set of algorithms, hashes and dh groups as well as NAT-T or native IPSec and IKEv1 or IKEV2. While VNS3 does a good job of auto discovery it is best to make sure that both sides are explicitly the same. We provide a simple syntax for VNS3. An example might look like:
phase1=aes256-sha2_256-dh14 phase2=aes256-sha2_256 pfsgroup=dh14 phase1-lifetime=3600s phase2-lifetime=28800s dpdaction=restart dpddelay=30s dpdtimeout=90s
VNS3 simplifies this process by putting all of your configuration on a single page.
If you are creating a policy based IPSec connection you will next need to create individual tunnels for your connection. This is done after the creation of the initial endpoint. After the endpoint is created you can create a “New tunnel” from the action drop down to the right of your endpoint. This will be your local subnet and then the subnet on the other side of the connection that you will be communicating with.
With route based IPSec we support both Virtual Tunnel Interface (VTI) and over GRE, useful for sending multicast packets. If you are utilizing a VTI route based IPSec VPN you next want to set up a “New eBGP Peer” from the action drop down.
Your IPSec configuration should now show as connected.
In the next parts in this blog series we will dive into the tools we provide to troubleshoot a faulty connection, interesting things you can do with our firewall to transform the tunnel traffic, and some plugins we use to solve common problems.
Whether you need to connect multiple cloud instances, communicate with the public internet from private resources, or directly connect to instances in local data centers, chances are you will be using Network Address Translation (NAT) to make that connection. All major cloud providers provide some product or service to provide NAT functionality, and some platforms even provide separate public and private variants. Because cloud instances running in private subnets are unable to access resources like time servers, webpages, or OS repositories without NAT functionality, most users find themselves relying on their cloud platform’s NAT offerings. By simply following their cloud providers’ recommended best practices, users are overpaying for an overcomplicated and inflexible service that a home cable modem does for free. So why pay so much for such a simple network function?
If You’re Using Cloud Platform NAT Gateway(s), You’re Overspending on Cloud Deployments.
Overspending of any kind in the wake of the economic disruption caused by the COVID-19 pandemic can be deadly for any business. Yes, some have fared better than others during this challenging time but all organizations have revisited projections and budgets in the face of uncertainty. According to Gartner, the pressure is on for budget holders to optimize costs.
Where to Start?
Look to the sky! Your cloud bill is likely full of opportunities for savings, especially if your application relies on NAT functionality. Using AWS NAT Gateway pricing as an example, let’s start with the comparative base subscription costs:
|AWS NAT Gateway||VNS3 NATe|
|Subscription||$0.045 / hour||$0.01 / hour*|
|Data Processing (TAX)||$0.045 / GB||$0.00 / GB|
As you can see from this example, the standalone subscription cost of an AWS NAT gateway is more than the cost of a single t3.medium instance. The already low VNS3 NATe subscription cost will provide you even more savings when you consider the fact that you don’t have to create as many individual NAT gateways, each of which would be accompanied by an additional AWS NAT Gateway subscription. The cost differential here makes NATe an obvious choice at any deployment scale and we even offer a free NATe license for smaller deployments.
VNS3 NATe is also incredibly scalable because we don’t increase our data processing rates as your bandwidth needs scale. Below is a pricing table that shows the total cost of running a single NAT Gateway vs a VNS3 NATe instance as the traffic throughput increases in a given month:
|GB / Month||AWS NAT Gateway||VNS3 NATe|
We also have customers who maintain 100s or 1000s of VPCs with NAT requirements of 1-100 GB per month. Those enterprise cloud customer at scale have typically seen costs drop to 1/5 of what they would pay for AWS NAT Gateways. To illustrate this savings, take the example from one of our customers has 1800 VPCs each with a NAT Gateway. The total data processed through these NAT Gateways is low and averages 10GB / month with much more potential savings for deployments that pass more traffic out the NAT device.
|AWS NAT Gateway||VNS3 NATe|
|Monthly Runtime||$58,320||Monthly Runtime||$12,960|
|Data Processing (TAX)||$810||Data Processing (TAX)||$0|
|TOTAL PER MONTH||$59,130||TOTAL PER MONTH||$12,960|
Total NATe saving per month in this case is $46K and $554K per annum.
Of course, costs savings are not limited to just NAT Gateway spend. Other opportunities for savings include right sizing instances (latest generation instance families are always less expensive), decommissioning unused services/resources (I’m looking at you load balancers), and reviewing storage strategies (such as EBS).
What is a NAT Gateway?
A NAT Gateway is a network service that performs a simple network function: Network Address Translation for cloud-based servers running in a private network (private VPC subnet). Here is the AWS documentation detailing the NAT Gateway functionality. NAT Gateways perform a specific type of NAT called IP Masquerading, where devices in a private IP network use a single public IP associated with the gateway for communication with the public Internet.
This is the same function that your home modem performs for free. You’re likely leveraging this NAT functionality as you read this post. Basically the NAT functionality on a NAT Gateway or your home modem allow devices on a private network (computers, phones, TVs, refrigerators, toothbrushes, etc. in the case of your home network) to access the Internet and receive responses but not allow devices on the public Internet to initiate connection into your private network. All traffic sent from the private network to the public Internet uses the modem’s public IP address.
NATe to the Rescue!
In response to direct requests by our customers, we created a low-cost, instance-based alternative to NAT Gateways – VNS3 NATe.
Available on AWS PM and Azure MP today:
What is a NATe?
NATe instances are drop-in replacements from Cohesive Networks for NAT Gateways. Simply launch in a VPC/VNET subnet with an Internet Gateway associated, Stop Src/Dst checking (enable IP forwarding), and update the Route Tables associated with the private Subnets to point 0.0.0.0/0 destinations at the NATe instance-id.
NATe provides all the functionality of a NAT Gateway plus enterprise grade security and controls at a fraction of the cost. Some of the functional highlights of NATe include:
- High Performance – run on the smallest instance sizes to maximize value or larger instance for greater total throughput
- Secure – access to a firewall to allow additional and orthogonal policy enforcement for traffic flows
- Control – access logs, network tools like tcpdump, status information
- Customize – leverage the Cohesive Networks Plugin system to add L4-L7 network services to the NATe instance like NIDs, WAF, Proxy, LB, etc.
- Automate – fully automate the deployment of VNS3 NATe instances as part of your existing deployment framework leveraging the RESTful API to reduce implementation costs.
- Failover – NATe can be configured in a number of HA architectures to provide the same level of insurance needed for critical infrastructure via instance auto recovery, auto scale groups, and Cohesive Networks’ own Peering and HA Container functionality
- Upgrade – NATe is fully upgradeable to fully licensed VNS3 controllers deployed as a single application security controller or part of secure network edge mesh
Still Not Convinced?
Cohesive’s NATe offers a dramatically more cost-efficient solution to often critical NAT requirements in cloud deployments of all shapes and sizes. NATe is more flexible, more scalable, and easier to manage than first-party cloud NAT gateways that are charging you a premium for the functionality of a standard consumer modem. If you don’t believe us, we launched a free version of our NATe offering in both the AWS and Azure marketplaces so you can launch and configure them and see for yourself!
Have questions about set-up or pricing? Please to contact us.
About the VNS3 Edge Plugin System
The recent release of VNS3 5.0 is the culmination of years of learning from our users what a modern, reliable, and secure network requires. This newest version of VNS3 provides a customizable platform for your cloud networking needs, including enterprise owned encryption, workforce VPN management, network segmentation, multi-cloud federation, and more. We at Cohesive never presumed to know exactly which web application firewall your organization uses, or which network intrusion detection system you wanted to use, so we started building our VNS3 plugin system back in 2014. Our goal is to provide our clients with the ability to fully customize their network edge for their unique use case on the solid foundation of VNS3. Our clients brought their Nginx WAF configurations, their Suricata rules, and their organizational expertise, and were able to plug it into VNS3, providing a uniform network edge for their enterprise.
VNS3 Plugin Manager Features
As we continue to build the plugin system with our clients, we’ve noticed there are two types of users that utilize it most: technical users who are comfortable creating network functions in containers and less technical users who simply want to install a plugin and perhaps edit said plugin’s configuration file. Here is where the Plugin Manager comes in:
The plugin manager provides a simple UI console for managing your plugin’s configuration. This includes creating your plugin’s firewall policy, directly editing plugin configuration files, viewing logs, and even the ability to run plugin commands. If the plugin provides a UI, you can access it directly from the plugin manager UI.
The plugin manager is the next step forward for VNS3 continuing to provide a fully customizable networking platform for your cloud edge. Now you can seamlessly manage your network edge plugins all in one place, allowing your organization to take full advantage of our combined expertise.
What’s Next for the Plugin Manager
As a little teaser of our product roadmap, the VNS3 Plugin platform will soon allow you to install your plugins directly on VNS3, including third party plugins vetted by Cohesive Networks. This will allow your organization to take advantage of our expertise and the lessons we’ve learned from other clients. Want to set up Datadog monitoring with VNS3? Install the Datadog plugin. Need intrusion detection? Grab the plugin provided by Zeek. Check out our currently available plugins and installation tutorials on our documentation site here.
Our claim: VNS3 will always be the most customizable network edge device for your cloud networking needs. Hold us to it.
As companies build out their Workforce Service Edge, new challenges are introduced. One of the forms these challenges can take is slow or unreliable ISPs causing interruptions for users.
For HelpDesk and technical employees, the ability to ask a user, customer, or partner to navigate to a site such as ‘speed.company.com’ in order to test their connection to YOUR network is incredibly valuable.
To that end, we’re proud to announce the release of the Speed Test container, based on the FOSS project Librespeed Speedtest. This container can be deployed on any current VNS3 controller, and can serve users on the overlay network, over the internet, across an IPsec tunnel, or anywhere else in your environment which can route connections to your VNS3 controller.
By providing latency and jitter information, as well as upload and download speed, the speed test container makes basic connectivity verification painless. The intuitive web interface means almost anyone can use the tool and report statistics quickly and accurately.
You can read the documentation and deployment guide here: https://docs.cohesive.net/docs/network-edge-plugins/speedtest/.
Source code is available under LGPL-v3: https://github.com/cohesive/vns3-container-speedtest.
To learn more about Cohesive’s Workforce Service Edge solution, check out our recent blog post.