It’s time to update an oldie-but-goodie!
The goal of the post, both then and now, is to dive into the technical part of VNS3. We’ll go into more features requirements for VNS3 beyond the typical features and use cases. As always, you can see the VNS3 page for product info and availability and read all of our use cases here.
In a nutshell, what is VNS3?
VNS3 is a software-only virtual network appliance that allows cloud users to add data in motion encryption, application layer firewalls, multicast protocol support, and region peering on top of network infrastructures.
VNS3 builds on core VPN concepts but allows more customer control with an “overlay network.” An overlay network is a computer network built on top of another network. Nodes in an overlay can be virtual or logical links. VNS3 adds control over topologies, network addressing, encrypted communications, and network protocols.
What is VNS3 made out of?
Software! But seriously…
VNS3 Controllers are virtual machines (VMs) that act as a VPN gateway for the other virtual machines in the same cloud infrastructure. VNS3 synchronize between each other using RabbitMQ. VNS3 has a web-based UI and traditional Linux system command line interface (CLI). The VNS3 API uses a Ruby script and Ruby language binding.
Everything else is a patented secret. In 2010 Dmitriy and the other VNS3 developers earned a patent on the underlying networking and cloud technologies.
If it’s more than a VPN, why *did* you call it VPN-Cubed?
We originally named it VPN-Cubed because it’s like a VPN, but 3x the features.
VNS3 is different from standard VPN software and hardware-based networking devices. Typically, VPNs are used to connect 2 LANs together, or to connect desktop clients to a LAN over the Internet. VNS3 acts like a traditional VPN gateway plus a virtual router, switch, firewall, VPN concentrator, protocol redistributor, and NFV container.
The cloud computing market has evolved, and cloud users are more sophisticated so we moved away from boxing ourselves into a VPN-only product. In 2012 we renamed it to VNS3. 451 Research analyst William Fellows wrote “VNS3 is not only for VPNs – hence the name change – since overlays can be within a cloud, between clouds, between a private datacenter and a cloud (or clouds), or between multiple data centers.” [the full report has a paywall.]
What cloud providers, server operating systems, devices, etc does VNS3 support?
Because VNS3 was created to support server infrastructure in a cloud, across clouds, or connected from private infrastructure to the clouds, VNS3 can support multiple OSes and networking devices.
VNS3 integrates with existing network equipment and can be delivered as part of the application deployment in most virtualized infrastructures. VNS3 is available in AWS, Azure, IBM Softlayer / Bluemix, Google Cloud, and more. It works with Cisco ASAs, Juniper Watchguard, Fortinet, and more IPsec devices in data centers. For more on specifications, check out cohesive.net/specs
Does VNS3 require large port ranges for firewalls?
Nope. For security best practices and ease of use, VNS3 doesn’t require large ranges of ports to open and accepts clients from behind NAT. VNS3 Controllers accept client connections on a single TCP or UDP port and seamlessly support clients behind NAT.
Can I scale beyond typical VPNs?
Yes! Typical VPNs do not scale beyond two active-active gateways. VNS3 supports synchronized “N-active” VNS3 Controllers. This means each VNS3 Controller has the same view of the topology as all of its peers, allowing it to support any of the servers in a cloud infrastructure.
For better failover options, configure VNS3 Controllers to manually failover via re-mapping the public IP of the primary VNS3 to the secondary VNS3. It also means the servers in theVNS3 Controllers can keep their same network address, regardless of the Controller they communicate through.
Unlike other VPNs, VNS3 also acts like a virtual router, switch, firewall, VPN concentrator, protocol redistributor, and NFV container. VNS3 allows many, many networking use cases including:
- application layer firewall with custom rules and hashings
- connecting both NAT-T and Native IPsec endpoints on the same endpoint
- Layer 2 Bridging over GRE as well as GRE tunneling over IPsec
- customizable, flexible networks with Docker containerized network services
- Trend Micro Deep Security central management agent
Can I manage static IP addresses in the cloud?
Yes! VNS3 connecting “clients” (usually cloud-based servers) get the same IP address no matter which VNS3 Controller they are connected to. Customers can assign Elastic IPs in AWS or static IPs in Azure to ease any network reconfiguration.
Do VNS3 clients require communication via different gateways?
Nope. VNS3 uses routing tables to pass traffic between servers connected to different VNS3 controllers. A device only needs to know itsVNS3 Controller and it can communicate with any device in the topology, regardless of its actual location.
Does VNS3 allow multiple clouds or a hybrid infrastructure between co-location sites, clouds and your data center?
Yes! VNS3 Controllers are software, so the virtual servers can work in any virtualized environment or cloud.
VNS3 Controllers can form an N-active, multi-directional overlay network between computing centers, cloud regions, and/or data centers. A network can run over the top of networks in Amazon AWS, Microsoft Azure, as well as in a co-location site or data center.
VNS3 Controllers can be located anywhere, including all over the Internet, inside a single cloud, or across multiple clouds. VNS3 Controllers maintain a synchronized and encrypted channel of communications between each manager in a specific VNS3 topology. The diagram – we call it the “sexy diagram” – shows just how powerful this cross-cloud, cross-region overlay network can be.
By: Margaret Valtierra