Cohesive Blog

A week ago, CEO Patrick Kerpan and I headed to the UK for AWS Summit London. We meet up with UK Managing Director Chris Purrington and Solution Architect Sam Mitchell. The four of us staffed the Cohesive Networks booth for both days of the Summit – Enterprise day and the general summit day. The Summit was held at ExCeL and boasted an impressive lineup of AWS stars including Amazon.com CTO Dr. Werner Vogels and AWS experts and partners.

Our booth display featured a security message without any red-letter FUD screaming at attendees. We asked attendees “who is pulling your cloud strings?” with two puppet-master hands comparing “their security” to “your security.” If you choose VNS3, you can take back control of your network security.  The video in the photos is our latest VNS3:ms and VNS3:ha demo, showing high availability and instance-based failover in AWS.

Enterprise day – security first

Day 1 was the Enterprise Summit. While attendance was light – we estimate about 400 people came – the quality of interactions was high. We had several people stop by the Cohesive stand and immediately identify security as one of their top priorities. On the down side, most day 1 attendees were only starting to evaluate cloud and AWS. Good and bad news for us, since most of our customers use VNS3 after they get set up in AWS or launch a few cloud projects but it’s a very promising sign for “security maturity.”

The day 1 crowd had excellent questions and discussion with us. On average, most people were evaluating cloud and AWS. I took it as a great sign that people still just dipping their toes in cloud and AWS already know that security is a top priority. When cloud newbies identify security as something they need before they even log on to the AWS Console, I have a great feeling about the direction of the cloud marketplace and cloud buyers in general.

Your apps connected and secureDeveloper day – security by priority 

Day 2, the AWS Summit was marketing more as a developer conference open to all. The crowds came out for this one! As soon as doors opened, we were flooded by attendees looking to learn more and grab a VNS3 sticker. Even during the 2 hour keynote, people kept coming by to chat.

A major difference I noticed was the change in AWS usage from day 1 to day 2 attendees. While day 1 attendees were looking to get started with AWS, day 2 folks seemed to be old pros at cloud. Everyone attended sessions on day 2, proving that the biggest draw to AWS events is still the desire to learn more.

After the VPC specific session I had a long conversation with 2 software developers about some limitations in VPC. They were surprised that VPC limits things like the number of VPCs you can peer, endpoints, and protocols in their cloud. Of course, AWS doesn’t list off the ways their products don’t work. Over the years, we’ve developed VNS3 to enhance Amazon VPC because of our own needs, and customers needs that developed over time.

Cohesive Networks at AWS London 2016Once you begin building more complex, important, and larger cloud networks in AWS, things like IPsec interoperability, traffic in motion encryption, and IP address conflict resolution can make or break a cloud project.

Currently, traffic in AWS EC2 and VPC travels across untrusted, third party networks in plain text. With VNS3, you can encrypt all data to, from, and within the cloud using unique keys only you control. As those networks grow, you can add IPsec interoperability and flexibility by using a wide range of encryption algorithms to accommodate industry regulations like HIPAA, PCI, FIPS, etc.

VNS3 can also help you span subnets across Availability Zones, Regions and even into other clouds, beyond what VPC offers. Likewise, VNS3 lets you easily manage network address overlap and eliminate Public IP address conflict so you can better connect to any IPsec endpoints so you don’t get locked out of mission-critical connections. VNS3 also enables IPsec with NAT-Traversal encapsulation or GRE over IPsec (AWS only allows native IPsec), and UDP multicast. Want to learn more about VNS3 in AWS?

Get help with VNS3 in AWS:

Posted by:

- - - -

Today we’re announcing the arrival of the latest VNS3 version 4.0.

The new version includes a hardened underlying Operating System (OS) so you can get more insight into your network security and better protect your cloud-based resources. Version 4.0 includes security focused updates for VNS3:net, VNS3:ms, and VNS3:ha software products. The release is GA today, but will take a while to roll through the Marketplace approvals in Amazon AWS, Azure, and our other cloud provider partners.

Here’s the quick and dirty rundown of what’s new in 4.0:

  • Enhanced VPN monitor for both cloud overlay and underlay networks
  • Pioneering LAN optimization for increased performance for hybrid cloud networks
  • Ability to enable/disable individual IPsec tunnel connection policies
  • Improved Network Security Container plugin system with latest Docker technologies
  • Strengthened security to include 2040 bit keys
  • Optimized source of entropy for cryptographic operations
  • Support for users to upload custom SSL certificates for secure UI and API connections
  • Upgraded interaction with VNS3:ms and VNS3:ha add-ons
  • Restructured certificate revocation management process for Overlay Network credentials
  • Redesigned clientpack and IPsec connection management
  • Advanced next hop support for attached interfaces

Find out more about the tech behind VNS3 4.0 at Cohesive.net/support/release-notes

VNS3 Sticker

We are proud to say that VNS3 is the first software-only, virtual network technology that lets you encrypt networks end-to-end at the application layer. We’re also proud of the positive attention we’ve been getting lately – winning 2016 Network Computing Awards Network Project of the Year – Private Sector Award and some great speaking events around the globe.

“Years of experience in enterprise networking and security have taught us to look further into the future, beyond predictions or fears,” said Patrick Kerpan, CEO of Cohesive Networks. “5-star sentiment in the AWS Marketplace validates that VNS3 offers the end-to-end control cloud users need to flexibly connect and secure their applications.”

Availability:

VNS3 4.0 is available immediately, and will soon be available on the AWS Marketplace, Microsoft Azure Marketplace, and ElasticHosts. Contact Cohesive Networks to get started today: sales@cohesive.net

VNS3 is available in over 20 public, private, and hybrid clouds. Cloud and virtual environments that feature VNS3 products include: Amazon EC2 and VPC, Microsoft Azure, CenturyLink Cloud, VMware vCloud, IBM Softlayer, Google Compute Platform, ElasticHosts, and Rackspace.

Posted by:

- - - -

To continue the network routing theme – check out our blog post Using IPsec site-to-site VPN connections in the cloud – today we’ll walk though how to link VNS3 controllers as IPsec VPN connections. 

If you have a network setup that requires you to connect 2 topologies, one simple way to do it is to connect VNS3 devices side by side over IPsec. If you have 2 or more VNS3 controller instances, an IPsec tunnel between the 2 devices will quickly bridge your networks over an encrypted connection.A site-to-site IPsec VPN can act as a secure tunnel between your devices. You can ensure all traffic between the source and destination is encrypted, reducing threats of interception, packet sniffing, and unauthorized access.

Requirements

  • You have two or more VNS3 controller instances
  • VNS3 controllers are running in non-overlapping VLANs (e.g. what AWS calls VPC Subnets, Google calls Networks, Azure calls VNETs, etc.)
  • VNS3 instances are running in non-overlapping VNS3 Overlay Subnets
  • Allow port access from your network settings or security groups from the cloud provider side:
    • Native IPsec – UDP 500 and Protocol 50 (ESP) access between the 2 VNS3 Controllers
    • NAT-Traversal IPsec – UDP 500 and 4500 access between the 2 VNS3 Controllers
  • Connecting underlying unencrypted VLANs is restricted to cloud environments that provide both packet forwarding features and route table controls. You need these settings to enable VNS3 controller instances to act as your router/switch.

Set up

In this example the IPsec tunnel connection will be made between VNS3 Controller Instance A (VNS3-A) and VNS3 Controller Instance B (VNS3-B). In the VNS3 controller UI, we’ve named each controller for clarity.

VNS3-A
Overlay Subnet: 172.31.10.0/24
VLAN: 192.168.200.0/24

VNS3-B
Overlay Subnet: 172.31.11.0/24
VLAN: 192.168.201.0/24

VNS3 side by side set up

Option 1 – Using NAT-Traversal Encapsulation

Step 1: Change VNS3 Local Private IP

When we connect 2 VNS3 topologies using NAT-Traversal IPsec, the local private IP address is required in the Endpoint definitions. The default value must be changed on one of the VNS3 controller instances. Overlapping IP addresses will preview the tunnel from fully negotiating. Also remember that each VNS3 controller’s local private IP address should be unique in that topology and must not be inside the topology’s data subnet.

Change the Local private IP address on VNS3-B to 192.0.2.253.

  1. Click IPsec and eBGP under the Connections left menu.
  2. Click Change next the the Local private IP address.
  3. On the resulting page enter 192.0.2.253 in the New local IP address field.
  4. Click Save changes.

VNS3 side by side - NAT T step 1

Step 2: VNS3-A: Create a New Endpoint

  1. On VNS3-A click Define new remote endpoint. Enter a name for the connection to VNS3-B.
  2. Enter the VNS3-B controller instance’s Public IP address in the Enter Internet IP address for this endpoint field.
  3. Enter a PSK in the Preshared Key fields. Enter the VNS3-B controller instance’s Local private IP (see previous page) in the NAT IP field.
  4. Click the Enable PFS checkbox (optional but recommended).
  5. Enter any IPsec parameters needed in the Extra configuration parameters field. This can be left blank to allow VNS3 to auto negotiate. These parameters need to match both sides to allow the tunnel to negotiate.
  6. Click Save.

VNS3 side by side - NAT T step 2

Step 3: VNS3-A: Create a New Tunnel

  1. On VNS3-A, click New tunnel next to the newly created endpoint definition.
  2. Enter the VNS3-A Overlay Subnet in the Local subnet field.
  3. Enter the VNS3-B Overlay Subnet in the Remote subnet field.
  4. Enter a descriptive name in the Name field.
  5. Click Create.

VNS3 side by side - NAT T step 3

Step 4: VNS3-B: Create a New Endpoint

  1. On VNS3-B, click Define new remote endpoint. Enter a name for the connection to VNS3-A.
  2. Enter the VNS3-A controller instance’s Public IP address in the Enter Internet IP address for this endpoint field.
  3. Enter a PSK in the Preshared Key fields. Enter the VNS3-A controller instance’s Local private IP in the NAT IP field.
  4. Click the Enable PFS checkbox (optional but recommended).
  5. Enter any IPsec parameters needed in the Extra configuration parameters field. This can be left blank to allow VNS3 to auto negotiate. These parameters need to match both sides to allow the tunnel to negotiate.
  6. Click Save.

VNS3 side by side - NAT T step 4

Step 5: VNS3-B: Create a New Tunnel

  1. On VNS3-B, click New tunnel next to the newly created endpoint definition.
  2. Enter the VNS3-B Overlay Subnet in the Local subnet field.
  3. Enter the VNS3-A Overlay Subnet in the Remote subnet field.
  4. Enter a descriptive name in the Name field.
  5. Click Create.

VNS3 side by side - NAT T step 5

Step 6: Check connection

Once you create the tunnels, you will see the information update on the IPsec page. Click on the highlighted tunnel address (172.31.10.0/24 – 172.31. 11.0/24 for example) to see the tunnel details. Both VNS3 controllers should list Status: connected above the Tunnel Parameters. From the Runtime Status page, you can also see if your connection is up and running.

VNS3 side by side - NAT T step 6

 

Option 2 – Using Native IPsec

The other option is to use Native IPsec to connect your 2 VNS3 Controllers. To use Native IPsec, you will have to disable NAT-Traversal on both VNS3 A and VNS3 B. NAT-T / Native IPsec is a device-wide setting. After that, you’ll follow the same steps from the NAT-T example above, just without entering a NAT-T address when you create a remote endpoint.

Again, you can’t use overlapping IP addresses and each VNS3 controller’s IP address should be unique in the topology.

 

Step 1: Change VNS3 Local Private IP

Disable NAT-Traversal on both VNS3-A and VNS3-B.

  1. Click IPsec and eBGP under Connections in the left menu.
  2. Click Toggle next to NAT-Traversal to disable.

VNS3 side by side - Native IPsec step 1

Step 2: VNS3-A: Create a New Endpoint

  1. On VNS3-A click Define new remote endpoint. Enter a name for the connection to VNS3-B.
  2. Enter the VNS3-B controller instance’s Public IP address
  3. Enter a PSK
  4. Leave the NAT IP field blank.
  5. Click the Enable PFS checkbox (optional but recommended).
  6. Enter any IPsec parameters needed in the Extra configuration parameters field. This can be left blank to allow VNS3 to auto negotiate. These parameters need to match both sides to allow the tunnel to negotiate.
  7. Click Save.

VNS3 side by side - Native IPsec step 2

Step 3: VNS3-A: Create a New Tunnel

  1. On VNS3-A, click New tunnel next to the newly created endpoint definition.
  2. Enter the VNS3-A Overlay Subnet in the Local subnet field.
  3. Enter the VNS3-B Overlay Subnet in the Remote subnet field.
  4. Enter a descriptive name in the Name field.
  5. Click Create.

VNS3 side by side - Native IPsec step 3

Step 4: VNS3-B: Create a New Endpoint

  1. On VNS3-B click Define new remote endpoint. Enter a name for the connection to VNS3-A.
  2. Enter the VNS3-A controller instance’s Public IP address
  3. Enter a PSK
  4. Leave the NAT IP field blank.
  5. Click the Enable PFS checkbox (optional but recommended).
  6. Enter any IPsec parameters needed in the Extra configuration parameters field. This can be left blank to allow VNS3 to auto negotiate. These parameters need to match both sides to allow the tunnel to negotiate.
  7. Click Save.

VNS3 side by side - Native IPsec step 4

Step 5: VNS3-B: Create a New Tunnel

  1. On VNS3-B, click New tunnel next to the newly created endpoint definition.
  2. Enter the VNS3-B Overlay Subnet in the Local subnet field.
  3. Enter the VNS3-A Overlay Subnet in the Remote subnet field.
  4. Enter a descriptive name in the Name field.
  5. Click Create.

VNS3 side by side - Native IPsec step 5

Step 6: Check connection

Once you create the tunnels, you will see the information update on the IPsec page. Click on the highlighted tunnel address (172.31.10.0/24 – 172.31. 11.0/24 for example) to see the tunnel details. Both VNS3 controllers should list Status: connected above the Tunnel Parameters. From the Runtime Status page, you can also see if your connection is up and running.

VNS3 side by side - Native IPsec step 6

 

Need more help?

Posted by:

- - - -

Blog Resources