Monday, September 15, 2014

To NAT or not to NAT: that is the question...or is there a better way?

By Senior Cloud Solutions Architect Sam Mitchell

In our journey though public cloud vendors and in our mission to give public cloud users back attest-able control and security of public cloud networks we have more or less worked with them all - from the very big to the more “boutique”.  When it comes to publicly addressable hosts we have noticed 2 main approaches, with variants on both approaches depending on the cloud vendor.
Image credit: Yellowstone, US Department of the Interior

The first is to directly assign a public IP address to an interface of a VM.  The second is to use Network Address Translation (NAT); using NAT results in traffic routed to the Public IP translated via 1:1 NAT and forwarded onto the Private IP address of an VM.
Both approaches have their advantages and disadvantages.

Approach 1 - Assigning a public IP directly to an interface.
This has the advantage of your traffic not traveling through any NATing, which some protocols and applications can have trouble with.  SNMP jumps to mind. If you have lots of over lapping private IPs and you’re using NATing to make them all unique then it is often hard to understand the actual source host when you get trap or an notification as the private IP (non-NATed) address is listed as the source IP.

This approach has the disadvantage of limited elasticity, if you assign a public IP to a VM and then at later stage you need to move that IP to another VM then you usually need to shut that VM down in order move the IP address from the interface of that VM.

We’ve also seen some clouds that have the ability to only assign one interface to VM. So for example you assign a public IP address to that single interface on the VM, routing can become tricky if you want to pass inbound public IP traffic onwards to other VMs which are in a private IP space or private VLAN / subnet inside the same cloud.

Approach 2 - Use NAT.
This has the major advantage of being more “cloud friendly” and elastic with the ability to move the public IP from VM to VM without the need to shut down VM’s.

This does have the disadvantage of having some sort of NAT device “in-between”, sometimes not all ports and protocols are universally open; which can result in a limitation on what you can actually do with with your public IP. IPsec comes to mind… not all clouds allow native IPsec and or NAT-T IPsec though their NATing device.

NATing also comes with the usual caveats when NAT - SMNP does work so will when a layer of NAT is in-between (see example in Approach 1).

So both approaches have pros and cons.  But in general NATing seems to be the best approach, and if implemented well by the cloud vendor you shouldn't face any major issues. The old adage of “not all clouds are created equally” comes to mind...

Amazon Web Services (AWS) have done a pretty good job with their Elastic IPs (EIPs) using approach 2.

How does an Elastic IP address work?
Elastic IP addresses are public IP addresses designed for dynamic cloud computing. An Elastic IP address is associated with your AWS account, not a particular instance (VM). You control that address until you choose to release it.  Elastic IP addresses allow you to mask instance or availability zone failures by remapping your public IP addresses to any instance associated with your account. AWS EIPs enables you to engineer around problems with your instance or software by remapping your Elastic IP address to a replacement / another instance.

Did you know that EIPs can be used for VPN IPsec endpoint IPs?
Yup, this has the major advantage of the EIP address becoming the IPsec VPN endpoint IP.  EIPs are just IPs and its very rare if ever that they are taken down for maintenance.

For example - if you use AWS’s native VPN hardware gateway for VPN connectivity to your instances you have no choice but to use a shared endpoint IP on a shared device. The device is inside of Amazons control, meaning AWS decides:

  •  your pre shared keys, 
  • when to take this service down for maintenance, 
  • the level and type of encryption you use, 
  • the pre-shared keys
Ultimately you can't attest to the security of your data in AWS. 

Although the VPN connection is configured and consumed by you the customer its still partly controlled by AWS (a third party network).  When using an EIP as the endpoint IP address for your IPsec connection it’s not shared with any other AWS accounts or customers. The EIP endpoint belongs to your AWS account and is inside of your control.  VNS3 allows you to use both native IPsec and NAT-T IPsec.

Enter VNS3

We developed VNS3 back in the days before the AWS VPN gateway existed. We noticed that AWS users needed a way to securely talk to their applications in the cloud.

VNS3 is an virtual machine appliance which you can start in an AWS instance from an AMI.  Once started you assign an EIP to the VNS3 instance, this allows you (the user) to create IPsec tunnels from this instance to your data centre / firewall / IPsec concentrator without the need to use the AWS VPN gateway.

Once the IPsec tunnel is established you can easily integrate the VPN’s remote network to the rest of your AWS private instances by using the VNS3 secure overlay network clients which route traffic to your VPN remote network at the end of the VNS3 instance by switching traffic from your private instances to the VNS3 appliance via secure encrypted tunnels.

For the less security intense users out there, you can also configure an AWS VPC to route traffic to the VPN remote network via the VNS3 appliance without the need to use the VNS3 secure overlay network on your private IP instances.  But using the VNS3 secure overlay network in conjunction with the VNS3 IPsec VPN gateway means that all your data in motion into the cloud and inside of the cloud and back out again is encrypted. Plus, you can attest to your data’s security from end to end, including inside the AWS network.

VNS3 also supports a much higher level of encryption such as AES 256 bit compared to AWS who provide only 128 bit with AES encryption.  ASE 256 bit is required for most PCI and HIPAA compliant solutions, many people don't know that the AWS VPN gateway is not PCI or HIPAA compliant due to its max of 128 bit encryption.
More on what VNS3 is and how it works with AWS VPC and EC2.


As Senior Cloud Solutions Architect, Sam Mitchell leads all technical elements of the global sales cycle. Mitchell runs demos, technical qualification, technical account management, proof of concepts, technical and competitive positioning, RFI/RFP responses and proposals.
Before CohesiveFT, Mitchell was a Cloud Solution Architect at Platform Computing, which was recently acquired by IBM. He was also a Lead Architect at SITA, where he headed up OSS BSS Architecture, Design and Deployment activities on SITA's cloud offerings.
Mr. Mitchell recently presented at CloudCamp London "It's All About the App!” in January 2014 and the IASA UK Application Defined Network (ADN) Summit in October 2013, and AWS UG UK #7: Let's talk Security in October 2013.  is a regular blog contributor, and hosts the CohesiveFT webinars (available here:  He has contributed to several technical white papers at CohesiveFT, Platform, and SITA.

Friday, September 12, 2014

Weekly news roundup for Cloud and Networking: September 8 - 12

Cloud and Networking news for the week of Aug 18

  • Gigaom: HP buys Eucalyptus as cloud consolidation commences for real >> a good immediate response to the news from @cloud_opinion on Medium 
  • VentureBeat: CloudBees ditches its cloud, will help devs send code elsewhere
  • beatnews: Gartner's Joe Skroupa 4 new "disruptive technologies that can spark changes to the business model [in data center markets are] software-defined networking (SDN) and software-defined storage, network function virtualization; extreme low-energy processors."
  • More in OpenStack-related speculations: Former Red Hat CTO moves on to Google Cloud via Gigaom
  • From CFT alum Dimitry Samovskiy "A Path to DevOps Through Platform/Product Alignment"

CohesiveFT in the news:

Catch up with the CohesiveFT team:

Wednesday, September 10, 2014

Secure container provisioning and the VNS3 API - part 2

This is the first of the Java-specific posts combining how to use the VNS3 API with secure container provisioning. It will make use of the setup discussed in the previous post. (For purists please excuse the quality of the code — it’s been a few years since I’ve worked with Java so I’m a little rusty. The goal is for the code to be clear enough to follow even with shortcuts taken for brevity and simplicity.)
Image credit: Clickatell blog 

Get on with it

To start with we’re going to make a connection to the API server and pull back the status of a VNS3 Manager.

We’ll start with a basic API connection class. VNS3’s API accepts basic authentication so we’ll set that up immediately.

public class Vns3ApiConnection {
    private String host, basicAuth;

    public Vns3ApiConnection(String host, String user, String password) { = host;
        String auth = user + ":" + password;
        this.basicAuth = "Basic " + new String(DatatypeConverter.printBase64Binary(auth.getBytes()));
        try {
        } catch (Exception e) {

VNS3 uses a self-signed SSL certificate. Dealing with validation of self-signed certs can be tricky, so we’ll skip it and, instead, run a function called self_signed_trust_manager(). Note: you should never, ever do this in a production environment.
void self_signed_trust_manager() throws Exception {
    try {
        // ------------------------------------------------------------------------------------------
        // Create trust manager that does not validate self-signed certificates
        // ------------------------------
        // ------------------------------
        TrustManager[] trustAllCerts = new TrustManager[]{
            new X509TrustManager() {
                public[] getAcceptedIssuers() { return null; }
                public void checkClientTrusted(X509Certificate[] certs, String authType) {}
                public void checkServerTrusted(X509Certificate[] certs, String authType) {}

        // Install all-trusting trust manager
        SSLContext sc = SSLContext.getInstance("SSL");
        sc.init(null, trustAllCerts, new;

        // Create all-trusting host name verifier
        HostnameVerifier allHostsValid = new HostnameVerifier() {
            public boolean verify(String hostname, SSLSession session) {
                return true;

        // Install the all-trusting host verifier
    } catch (KeyManagementException e) {
    } catch (NoSuchAlgorithmException e) {

Just to reiterate the point: you should never, ever, ever fake out the trust management code.

For this first part we’ll write two more pieces of code. The first is a function to get the status of a VNS3 manager. Due to a lack of creativity I’m going to call it “get_status()”.

void get_status() throws Exception {
    HttpsURLConnection httpsConnection = null;
    URL url = new URL(host + "/api/status");
    try {
        httpsConnection = (HttpsURLConnection) url.openConnection();
        httpsConnection.setRequestProperty("Authorization", basicAuth);
        httpsConnection.setRequestProperty("Accept", "application/json");
        httpsConnection.setRequestProperty("Content-Type", "application/json");
    } catch (MalformedURLException e) {
    } catch (IOException e) {
    BufferedReader responseBuffer = new BufferedReader(new InputStreamReader(

    System.out.println("Output from Server:  \n");
    String output;
    while ((output = responseBuffer.readLine()) != null) {

The second part is the main function in a separate class that’s going to actually call the above code. The host, user and password are from a test copy of VNS3 manager I have running locally.

public class TestAPI {
    private static final String host = "";
    private static final String user = "api";
    private static final String password = "password";

    public static void main(String[] args) throws Exception {
        try {
            Vns3ApiConnection api = new Vns3ApiConnection(host, user, password);
        } catch (Exception e) {

And when we put this all together we get something that looks a little like:

Output from Server: 


So, in a bit less than a hundred lines of code we have a straightforward connection to the VNS3 API server. (The sudden shift of the Earth in its orbit, is due to Ruby, Python, Perl and PHP coders all hitting their heads against brick walls — I’ve not bothered using any libraries apart from the built-in Java libraries to do this. Imagine writing your code without requiring gems, eggs and so forth.)

You can download the code from here. It even includes an old-school Bash script that will create a Jar and run the code for you. You’ll need to change the password and the IP address to match your setup before compiling and running the executable.

In the next post we'll wrap things up by using our newly-minted Java utility to install our Docker base image and then customise it.

Tuesday, September 9, 2014

More from the Cat in the Hat: Weave

Congratulations to Alexis Richardson (CohesiveFT Alumn) and Matthias Radestock (Former LShift CTO and CohesiveFT partner) on the launch of Weave.

Weave, an open source project distributed under the Apache 2 license, is a network overlay solution for Docker containers.  I expect Weave to receive a lot of attention; the red hot Docker space continues to expand in level of adoption and complexity of container use-cases.

The prospective success of this venture is certainly high as Alexis and Matthias have experience creating fast, clean and valuable open source projects like RabbitMQ (a CohesiveFT and LShift joint venture spun out into a separate company sold to VMware in 2010).

The Cat in the Hat: building on top of great things

It is quite exciting to see the ongoing "Cat in the Hat" effect in the world of cloud, DevOps, Docker and Network Virtualization where a steady stream of abstractions drive customer utility and capability onward and upward.

Once you believe the network is virtual, you have pretty much gone through the looking glass and can make them do extraordinary things not easily done (organizationally or technically) in the physical networking layer.

The CohesiveFT VNS3 solution provides a logical virtual machine network overlay using the underlying virtual infrastructure as bulk transport. Now we have a logical Docker container overlay using either VNS3 or the underlying virtual infrastructure as bulk transport.

It makes for another whole raft of customer-controlled use-cases in the cloud where at one moment you are performing the role of overlay and the next you are an "underlay".  We have and will continue to share our experiences in the "top of cloud" Networking space with the Zettio team and look forward to the use-case discovery adventure that lies ahead.


Friday, September 5, 2014

Weekly news roundup for Cloud and Networking: September 1 - 5

Cloud and Networking news for the week of Aug 18
  • DataCenter Knowledge: Peak 10 Opens Third Atlanta Metro Data Center >> "Peak 10 continues to expand across its footprint, recently adding space in Cincinnati as well as breaking ground on a 60,000-square-foot data center in Tampa, Florida."
  • ZDnet: Microsoft takes aim at AWS and VMware with Migration Accelerator
  • CloudWedge: Netflix will be 100% Cloud by 2015
  • Computing UK: Bristol City Council to migrate IT infrastructure to the cloud in £1.5m deal >> Bristol will migrate IT infrastructure to the cloud through the government's G-Cloud in a deal worth £1.5m over two years.
  • Computer World: Using Amazon’s cloud services, NASA is moving legacy apps, saving money, gaining efficiency
Image credit: Cisco Global Cloud Index: Forecast and Methodology, 2012–2017

CohesiveFT in the news:
Catch up with the CohesiveFT team:

Share this Post

Related Posts Plugin for WordPress, Blogger...