Home > Cloud Computing, Cloud Security, Virtualization > CohesiveFT VPN-Cubed: Not Your Daddy’s Encrypted Tunnel

CohesiveFT VPN-Cubed: Not Your Daddy’s Encrypted Tunnel

November 14th, 2008 Leave a comment Go to comments

I had a  briefing with Patrick Kerpan and Craig Heimark of CohesiveFT last week in response to some comments that Craig had left on my blog post regarding PCI compliance in the Cloud, here

I was intrigued, albeit skeptically, with how CohesiveFT was positioning the use of VPNs within the cloud and differentiating their solution from the very well established IPSec and SSL VPN capabilities we all know and love.  What's so special about tunnels across the Intertubes?  Been there, done that, bought the T-Shirt, right?

So I asked the questions…

I have to say that unlike many other companies rushing to associate their brand by rubber cementing the word "cloud" and "security" onto their product names and marketing materials, CohesiveFT spent considerable time upfront describing what they do not do so as to effectively establish what they are and what they do.  I'll let one of their slides do the talking:


Okay, so they're not a cloud, but they provide cloud and virtualization services…and VPN-Cubed provides some layer of security along with their products and services…check. But…

Digging a little deeper, I still sought to understand why I couldn't just stand up an IPSec tunnel from my corporate datacenter to one or more cloud providers where my assets and data were hosted.  I asked for two things: (1) A couple of sentences summarizing their elevator pitch for VPN-Cubed and (2) a visual representation of what this might look like.

Here's what I got as an answer to question (1):

"VPN-Cubed is a novel implementation of VPN concepts which provides a customer controlled security perimeter within a third-party controlled (cloud, utility infra, hosting provider) computing facility, across multiple third-party controlled computing facilities, or for use in private infrastructure.  It enables customer control of their infrastructure topology by allowing control of the network addressing scheme, encrypted communications, and the use of what might normally be unrouteable protocols such as UDP Multicast."

Here are two great visuals to address question (2):



So the differences between a typical VPN and VPN-Cubed comes down to being able to securely extend your "internal clouds infrastructure" in your datacenters (gasp! I said it) in a highly-available manner to include your externally hosted assets which in turn run on infrastructure you don't own.  You can't stand up an ASA or Neoteris box on a network you can't get to.  The VPN-Cubed Managers are VM's/VA's that run as a complement to your virtual servers/machines hosted by your choice of one or multiple cloud providers.

They become the highly-available, multiprotocol aribters of access via standardized IPSec protocols but do so in a way that addresses the dynamic capabilities of the cloud which includes service governance, load, and "cloudbursting" failover between clouds — in a transparent manner.

Essentially you get secure access to your critical assets utilizing an infrastructure independent solution, extending the VLAN segmentation, isolation and security capabilities your providers may put in place while also controlling your address spaces within the cloudspaces encompassing your VM's "behind" the VPN Managers.

VPN-Cubed is really a prime example of the collision space of dynamic application/service delivery, virtualization, security and cloud capacity governance.
  It speaks a lot to re-perimeterization that I've been yapping about for quite some time and hints at Greg Ness' Infrastructure 2.0 meme.

Currently VPN-Cubed is bundled as a package which includes both product and services and supports the majority of market-leading virtualization formats, operating systems and cloud providers such as Amazon EC2, Flexiscale, GoGrid, Mosso, etc.

It's a very slick offering.


  1. windexh8er
    November 16th, 2008 at 07:52 | #1

    In the end, it's nothing a company can't do with an IPsec implementation (yes, it is IPsec – as of the 4xxx series RFCs, not IPSec). That's all they're doing, it may be "beautified", but in the end I would trust FOSS IKE/IPsec implementations than theirs. Who says they're not just reimplementing it? What if they're using an "Aggressive" type phase 1? What if it's just lame L4 SSL socket transport? It's cloud security through obscurity… Give me some real technical details to challenge the implementation or wise-minded security professionals will just scoff at the idea of trusting, yet, another company who promises "security" but obscures the technology.
    UDP multicast? Big f'in deal — I can do that with IPsec. In fact, if all of the facets and differing implementation configurations of IPsec in general don't have what you need to do to secure your own cloud — then you probably should look at rethinking your architecture to begin with.
    Because, in the end, in my "cloud" — if I can't implement secure transport, then I'm not going to use that vendor anyway.
    Just my $0.02.

  2. November 17th, 2008 at 03:49 | #2

    A couple of things:
    (1) This is a managed solution, not simply a product. I can make a 1974 Ford Pinto fly by strapping a JATO unit to it, but that doesn't make it a 747.
    Many folks, especially small companies that don't have the time, desire or skills to bundle their own FOSS solutions together, manage them, or purchase high dollar VPN software products, will look at solutions like this as very viable, especially as they look for solutions to some of the newly-obvious security concerns.
    (2) Where did all this "security by obscurity" conspiracy theory come from? This is a software security product, much like any VPN or firewall product, that layers on top of infrastructure. I have a list of all the components they use and will dredge it up from the briefing for you. I *never* said it wasn't IPSec and I didn't say it was proprietary encryption.
    (3) Your last sentence was the most telling — there's a disconnect here. You said "Because, in the end, in my "cloud" — if I can't implement secure transport, then I'm not going to use that vendor anyway."
    Herein lies the problem, you don't control the infrastructure. You're given one or more IP addresses, a VLAN and perhaps some basic firewalling/ACLs. Your ability to secure the transport is exactly the problem this solution solves without the need to try and cobble together an OVF VM that is certified to run across multiple cloud providers.
    Could you do it yourself? Probably. I could also build a firewall infrastructure based on IPtables, but in many cases there are better tools for the job that provide equal "security" with easier management and extensibility.
    This is a VPN solution adapted for multi-cloud tenancy.
    In all, I don't disagree that you couldn't build something like this yourself, which is why I was skeptical in the first place, but making it scale, easy to manage, infrastructure-independent and reliable are pretty big issues. These are the problems this solutions solves.

  3. November 18th, 2008 at 10:18 | #3

    Is this sort of the VPN-like equivalent of GoToMyPC?
    Yeah, I'm probably comparing two different things, but thought I'd stab at it.

  4. November 18th, 2008 at 11:47 | #4

    @LV: If I take your analogy to it's logical conclusion, not exactly. In the case of G2MPC, you're installing SW on a PC you wish to gain access to from elsewhere.
    In the case of CohesiveFT, you're installing a software instantiation of a VPN "appliance" as a virtual appliance that front ends a collection of VM's in your "cluster." It performs the encryption functionality as described above, but also applies some intelligence as to connectivity and the cloud platforms it supports to allow for things like Cloud Bursting.
    Did that make any sense?
    It's a little more involved than G2MPC, but I suppose I see how you got there…sort of 😉

  1. August 26th, 2009 at 01:15 | #1