Thursday, August 21, 2014

Ask a Cloud Netwoking Expert: What is cloud VPN?

Virtual private networks (VPNs) use the public internet to connect remote sites, offices, or users together. VPNs use "virtual" connections routed through the Internet but the security settings of a VPN ensure data security because all traffic inside the VPN is encrypted. 

From a user’s point of view, a VPN connection is the same as a connection within a private network. For example, a remote worker can access a VPN from the road and have the same experience as she would while working in the office. Similarly, large enterprises with data centers, offices, and partner networks spread across the globe can use VPNs to connect their resources into one logical network.

Why use VPNs in enterprise - security guarantee 
VPNs help companies prove that they are complying to security standards and that they “own” all the data inside their network. In cloud computing, there is a hurdle for enterprises who want to use the public internet to connect to a cloud-based customer or cloud-based storage but they just cannot let their private data be outside of their own network. 
Image credit: Wikimedia Commons


VPNs are more secure because they use tunneling protocols and data encryption. Tunnels help enterprises ensure sender authentication so unauthorized users cannot access their VPN. VPNs can also guarantee the message was not tampered with during transmission.

The data traveling through the VPN tunnel is also encrypted. Even if network traffic is sniffed at the packet level, attackers would only see encrypted data. See Wikipedia for more on network sniffer.

Some secure VPN protocols include:



  • Internet Protocol Security (IPsec) 
  • Transport Layer Security (SSL/TLS)
  • Secure Shell (SSH) VPN

  • Also, check out some of our similar Ask a Cloud Networking Expert posts. We’ve covered more technical and specific topics, like encryptionIPsec security and how UDP multicast can work in the cloud. 

    Cloud VPNs
    Cloud VPNs (sometimes called virtual private clouds or VPCs) can be the answer to security and compliance concerns in public clouds. Cloud VPNs work just like a local network VPN, but instead of creating a private network on top of wifi or the public internet, a cloud VPN is a private network over top of a cloud providers’ network infrastructure that can bridge data centers and cloud geographies. 

    Where does CohesiveFT's VNS3 fit in?
    Using VPN technology, VNS3 creates an overlay network over top of any hardware or cloud computing resource. VNS3 connects the VPN with your IPsec tunnels to any customer or partner networks.  VNS3 lets you launch and configure a secure network with either REST APIs or through a web-based interface.

    VNS3 allows you to separate control from the hardware level. Because control is separated from hardware, you have more control over your network security. So, essentially VNS3 lets you free your application from a cloud provider, hardware, or risky network sniffers.

    Expert Profile 

    Source: this guy
    Name: Ryan Koop
    Title: Director of Products and Marketing
    Favorite Snack: Cashews
    Credentials in the "Expert's" words
    Do I have a bunch of certifications?  Nope.  Sadly my Smart Cloud Advisor and Architect certs just expired.  My primary job function is marketing, let's see if I can self promote.

    I have a over six years of experience designing our cloud network product.  I also moonlight as a member of our support team (does that make me a masochist?) and services team.  In those roles I have helped our customers design, deploy and tune hundreds of cloud networks and troubleshoot thousands of IPsec tunnel negotiations.  In many cases, I end up configuring both sides of the connection and have become familiar with a number of network security and routing hardware appliances from all corners of the market: Cisco, Juniper, Watchguard, Dell SONICWALL, Netgear, Fortinet, Barracuda Networks, Check Point, Zyxel USA, McAfee Retail, Citrix Systems, Hewlett Packard, D-Link, WatchGuard, and Palo Alto Networks.

    Friday, August 15, 2014

    Cloud & networking weekly news roundup: Aug 11 - 15

    Cloud and Networking news for the week of Aug 11
    • From ODCA president Correy Voo: Why cloud spells the end of the IT department…as we know it on iCIO 
    • Network World:  Confused by SDN & NFV? These may be complementary options for the network of tomorrow >> "The goal with both SDN and NFV is to control the network logically, with software and minimize hands-on work with those network devices."
    • Wired: The Internet Has Grown Too Big for Its Aging Infrastructure
    • From GigaOm Is Docker a threat to the Cloud ecosystem? 
    • InfoSec Institute: The Cloud is Both More and Less Secure than you Think
    • Datacenter Knowledge: IBM Opens SoftLayer Data Center in Toronto, Canada 
    From Gigaom Research - Stack-inception: Containers and how they relate to systems software with VMs.


    CohesiveFT in the news:

    Catch up with the CohesiveFT team:

    Wednesday, August 13, 2014

    Connecting Docker Container Networks Over the Internet with VNS3

    A few posts back our CTO Chris Swan blogged about "Connecting Docker containers between VMs with VXLAN".  While I applaud his bravado in tackling this, I wanted to up the ante by showing how easily one can connect networks of Docker containers over the Internet.

    The easiest way I know how to do this is to use VNS3 which has had a Docker subsystem embedded since our release 3.5 in April of this year.
    Historically VNS3 has been mostly a Layer 3 overlay network connecting customers to, through and across the clouds acting as a switch, router, firewall, VPN, and protocol re-distributor all dynamically scriptable via a RESTful API.


    Increasingly customers see us as a network provider as much as a device provider, and as such are looking for us to be a generalized networking solution yet also customizable platform for connectivity, integration and security for their cloud-deployed applications.

    Instead of VNS3 just providing L3 transport to connected applications, VNS3 networks now have Docker networks attached to them - with a network inside each VNS3 Manager instance in an overlay mesh.


    Using the Docker system embedded in VNS3 our customers can deliver open source, commercial source and proprietary source functions into their cloud-based networks.  Some examples are using an NGINX container for proxy functions or Suricata for NIDS.  These can be applied to your overlay network and available to your applications in minutes.

    It is a snap to create and configure your Docker networks inside VNS3.



    Then just add a few routes....


    Set a few firewall rules...



    Upload your Dockerfiles or LXC Images, and Allocate Containers!


    You are ready to communicate between the Docker container networks in each VNS3 Manager, securely over the Internet.

    To see this in more detail, check out our video demo HERE

    Friday, August 8, 2014

    Cloud & networking weekly news roundup: Aug 4 - 9

    Cloud and Networking news for the week of Aug 4
    • From Computer World: HP trims its cloud offer for lighter use >> the new HP Helion Managed Virtual Private Cloud Lean will be contract-based rather than credit card based, and can only be accessed through a customer portal. 
    • TechCrunch: Google Compute Engine Adds New Zones In US And Asia
    • From InfoWorld: Try again, cloud contenders: Amazon, Google, and Microsoft have won >> Writer / analyst David Linthicum writes that the mid-level IaaS and PaaS players need to specialize in a new niche or sell out.
    • Research firm MarketsandMarkets predicts the data center networking market’s value will hit $21.85 billion by 2018 and have a compound annual growth rate of 11.8 percent over the next four years.
    • From Inc: How the Cloud Will Transform Business by 2020 




    CohesiveFT in the news:

    Catch up with the CohesiveFT team:

    Wednesday, August 6, 2014

    Ask a Networking Expert: What is an overlay network?

    A visual guide to virtual networking across public clouds


    From the top: topology overview 
    To demo the concept, we'll create a simple topology with a data center in Chicago and a remote office in London.  Both locations connect to public cloud services via the internet.

    The cloud data center  has “virtual instances” (or virtual machines “VMs”) and each VM runs in a physical host/hypervisor connected to a switch. Each switch is connected to a firewall, then to a router, and this edge router provides the cloud’s connectivity to the internet.

    All 3 sites have hosts connected to the internet by switches, firewalls and routers.  All 3 topologies are made up of a combination of physical and virtual devices, multiple layers, and different types of virtualization. Note that the three sites are all in different subnets.

    We call these three sites the “native” layer.
    The native layer. Image under Creative Commons from CohesiveFT

    Native topology within the cloud and a VNS3 manager
    The VNS3 manager is a software-only virtual appliance running within a host/hypervisor.   VNS3 creates an overlay network, separating network identity from physical network location. 
    VNS3 acts as a virtual switch - providing the overlay connectivity to each of the compute hosts and switches traffic between hosts.  The compute hosts are configured to talk to the VNS3 managers as “client servers” and they see the VNS3 manager as the next logical hop their topology.

    The VNS3 manager is configured with a subnet, giving it a range of IP address available for static allocation to the client servers, this will allow them to join overlay network. (The overlay network in this example operates within a 172.x.x.x address space configured by the user with the IP subnet of their choice.)

    The two red lines in the diagram below are IPsec tunnels from the VNS3 manager to a remote firewall.  Both London and Chicago are 2 different endpoints. Behind each endpoint is a “remote” subnet.  (Note in this example the remote subnets are in 192.168.x.x ranges which is a different range to the overlay network, however it is possible to configure VNS3 to distribute IP address from the same subnet and to use the next available IP address in that range.)

    In is example is the traffic still travels on the native network, on the same native devices. Logically VNS3 is layered over these devices to provide an overlay network function.  The user can select the IP address for each client server in the public cloud, and these overlay IPs are addressable from both London and Chicago.  

    When you configure a cloud instance in the VNS3 topology, a secondary interface is created on the server called “tun0” which is layered over the existing native interface and all overlay network traffic goes via tun0.  This is in addition to the existing primary interface usually labeled “eth0”.   Usually eth0 can be shut off to all traffic other than traffic via tun0 and this creates a sealed network.
    VNS3 creates an network over top of the public cloud network. Image under Creative Commons from CohesiveFT

    Note that the native devices are still present in the topology and still provide the native physical and virtual connections, the overlay network is layered over the native and is still dependent on the native (depicted by the reduced opacity of the native devices).

    Native topology plus VNS3 high availability overlay network
    When 2 or more VNS3 managers are peered they start exchanging a given topology's routing information and sharing client server credentials / connectivity details.  Any connected client servers can connect to either manager, in turn both managers will still be able to access the client(s), no matter which manager the client server is connected to at that time.  Similarly, all IPsec tunnels connected to either manager are accessible via both managers and all client servers.  Sometimes it helps to think of 2 VNS3 mangers like a pair of high availability switches running or a pair of routers running HSRP (Hot Standby Routing Protocol).

    VNS3 high availability (HA) solutions have automatic failover features and no user intervention is required.

    Peered managers provide overlay network failover/high availability but not IPsec failover. The endpoint IPsec device should have its own high availability features, eg. Cisco ASA’s offers a multi ‘Peerlist’ feature so the ASA can drive the IPsec failover - if it detects the tunnel is down, it will try to reconnect to another.

    The next diagram shows IPsec active tunnels from each remote site (endpoint) in continuous red lines.  The dashed red lines are the passive tunnels which are “up” and ready to take the active function much like “hot standby”.

    Using Peerlist from one ASA to two VNS3 managers, with an active tunnel and a passive tunnel to each manager, this counts as two tunnel's within the VNS3 licensing parameters.

    The 2 VNS3 Managers act as peers to create a highly available network. Image under Creative Commons from CohesiveFT



    What if a VNS3 Manager fails?
    In the event the primary manager (manager #1 below) is unavailable the client servers automatically attempt to connect to other managers in the topology.

    Peered managers provide overlay network failover/high availability but not IPsec failover, the IPsec device at the endpoint (London and Chicago) should have its own high availability features.  In the diagram above the remote sites or endpoints have Cisco ASA’s using the ‘Peerlist’ feature and so the ASA’s drive the IPsec failover - if it detects the tunnel is down, it will try to reconnect to another.

    If manager 1 fails, manager 2 takes over the primary role and identity. Image under Creative Commons from CohesiveFT
    In this example, and most VNS3 networks, all cloud servers communicate through the VNS3 manager, and all data in motion between these servers uses is encrypted. The obvious benefit is added security and the ability to "own" your own cloud network control.

    Want to build your own cloud network with VNS3? Get in touch. 

    Source: this guy

    Expert Profile


    Name:  Sam Mitchell
    Title:  Senior Solution Architect
    Favorite Snack Edamame
    Credentials: As Senior Cloud Solutions Architect, Sam leads all technical elements of the sales cycle in the UK and internationally.  Sam runs demos, technical qualification, technical account management of proof of concepts, technical and competitive positioning, RFI/RFP responses and proposals.

    Before CohesiveFT, Sam was a Cloud Solution Architect at  IBM Platform Computing. He was also a Lead Architect at SITA, where he headed up OSS BSS Architecture, Design and Deployment activities on SITA's cloud offerings.

    Share this Post

    Related Posts Plugin for WordPress, Blogger...