VPN-Cubed: Technical Overview

People sometimes ask us, “How is VPN-Cubed different from a regular VPN or tunnel?” It is not an easy question to answer because there are many variables to consider. This blog post will examine the different feature requirements for a VPN, and help to explain how our VPN-Cubed offering goes well beyond these typical features and use-cases to provide security and control of your infrastructure in the clouds. Please visit the VPN-Cubed web page for general information about our cloud VPN. If you have questions, leave them in the comments, or drop us an email at marketing(at)cohesiveft.com.

In a nutshell, what is VPN-Cubed?
VPN-Cubed is a customer-controlled solution for use within a cloud, across clouds or to connect private infrastructure to clouds. It is a novel implementation of VPN concepts but extended for use in cloud computing (and other 3rd party controlled computing environments). VPNs have the typical use cases of connecting 2 LANs together or desktop clients to a LAN over the Internet. VPN-Cubed builds on these core VPN concepts, but can be thought of as a customer controlled “overlay network.” An overlay network is “a computer network built on top of another network. Nodes in the overlay can be thought of as being connected by virtual or logical links, each of which corresponds to a path, perhaps through many physical links, in the underlying network.” VPN-Cubed provides this function, putting it in customer control across multiple locations, allowing the customer to control their topology, their network addressing, their encrypted communication, and their desired network protocols, all in a scalable, highly redundant form.

If it’s more than a VPN, why did you call it a VPN?
Virtualization and cloud computing are creating new junctures in how systems are assembled, deployed and managed. We call it VPN because it is like a VPN for the clouds, but extends the concepts to provide an overlay network that can be configured and run by IT staff who are familiar with configuration and management of a traditional VPN. We call it “-Cubed” because it is more than a VPN (as in raised to the 3rd power) and because we think of a Cube as the thing that holds your infrastructure, in your control, in the clouds. When we talk about putting a customer topology into a cloud computing center like EC2 or FlexiScale we say we are “putting it into a Cube.”

Does VPN-Cubed support multiple server operating systems?
When we set out to create the offering, we had to address the growing challenge of multiple server operating systems. It is increasingly the norm to find more than one operating system in any given IT environment. To that end, VPN-Cubed supports Windows Server 2008, Debian (Etch, Lenny), Ubuntu (8.04LTS), Fedora 9, CentOS 4, Red Hat Enterprise Linux 5, openSuse, Novell SLES, and others. Note: While “client” machines can be a part of a Cube, the focus of VPN-Cubed is to support the server infrastructure in a cloud, across clouds, or connected from private infrastructure to the clouds.

What about firewall and the NAT protocol?
In a cloud environment, VPNs need to play well with firewalls and protocols. That means, they should not require large ranges of ports to open and they should accept clients from behind NAT. VPN-Cubed Managers accept client connections on a single TCP or UDP port and seamlessly support clients behind NAT.

Is kernel modification a common requirement?
Whereas some solutions require clients to modify their kernel on Linux and Unix systems, VPN-Cubed is a user-space solution. That means kernel patching or modification is not typically required on most modern operating systems.

Do you require more than two active-active gateways?
Typical VPN solutions do not scale beyond two active-active gateways. We configured VPN-Cubed to address this need. VPN-Cubed supports synchronized “N-active” VPN-Cubed Managers. This means each VPN-Cubed manager has the same view of the topology as all of its peers, allowing it to support any of the servers in your cloud infrastructure, in the event of a failure of one of the managers. It also means the servers in the VPN-Cubed can keep their same network address, regardless of the manager they communicate through.

How are static IP addresses managed in the cloud?
VPN-Cubed “clients” (usually servers deployed to a cloud or virtual infrastructure) get the same IP address no matter which VPN-Cubed Manager they are connected to.

Do your clients require communication via different gateways?
VPN-Cubed Managers use routing tables to pass traffic between servers connected to different managers. A device only needs to know its VPN-Cubed Manager and it can communicate with any device in the VPN-Cubed topology, regardless of its actual location.

Does your solution allow multiple clouds or a hybrid infrastructure between co-location sites, clouds and your data center?
VPN-Cubed Managers are virtual servers that act like traditional VPN gateways *and* clients as well. They form an N-active, multi-directional overlay network between your various computing centers. This enables your servers in the VPN-Cubed to run in Amazon EC2, Flexiscale, Mosso, etc., as well as in your co-location site or data center.

Is your current VPN solution tethered to a single LAN/subnet?
VPN-Cubed Managers can be located anywhere, including all over the Internet, inside a single cloud, or across multiple clouds. VPN-Cubed Managers maintain a synchronized and encrypted channel of communications between each manager in a specific VPN-Cubed topology. The drawings below demonstrate this freedom.

By: Margaret Valtierra