Cohesive Blog

UPDATE 3/28 We now have a video too. Watch it on our YouTube channel.

This is a quick guide for a basic VNS3 Controller setup and connecting a single EC2 based client instance. We’ll start from an AWS Marketplace VNS3:vpn Free Edition Controller step through basic configurations, then launch and connect to an Ubuntu 16.04 LTS client server.

This is the minimum needed to establish an overlay network, but a core use case for our long-term VNS3 users. Assuming you’ll need a quick and easy solution, we’ll demo VNS3 on an AWS EC2 t2.medium instance and a free-tier t2.small Ubuntu 16.04. You can always scale up to more VNS3 Controllers, add storage or upgrade instance sizes as needs grow.

This is a step by step guide to illustrate how to get going with VNS3. Make sure to check our documentation page and see the Knowledge Base for any updates after this post.

Launch VNS3 from the AWS Marketplace

Go to the VNS3 page on AWS Marketplace and hit the Continue button:
AWS marketplace vns3 version 4
Click on the Manual Launch tab and click the “launch in EC2 Console” button for your region. I know, it’s less convenient, but go though this because the “1-click” option doesn’t give you the right security settings needed. It’ll be quick, promise.
AWS marketplace VNS3 manual launch
The smallest (and cheapest) size for VNS3 Controllers is currently the t2.medium. You can always upgrade later if needed.
launch-step2
If you’ve got a VPC configured, make sure your VNS3 launches there. Otherwise, you can set up a new VPC and security groups.  If you’re just setting up, follow the steps in the AWS guides on cohesive.net/docs or watch our quick video on YouTube.
launch-step3
You can leave defaults for storage.
launch-step-4
Add a name (Value).
launch-step-5
Next, you’ll either assign the security group from your VPC setup or create a new group. Remember to allow port 8000 access from your IP so you can get to the VNS3 UI:
launch-step-6
Click Review and Launch. You’ll probably see 2 scary pop-ups but you’ll click through: first you do not want port 22 access (SSH) to VNS3 and second, you do not need to assign a keypair at launch since we’ll handle access from the VNS3 UI.
launch-step-7
Now, as your new VNS3 instance spins up there are 2 AWS items. Add an Elastic IP address for your new instance – it’ll help with availability later on – and click “disable source/destination check” to allow VNs3 to direct traffic. Again, more details are in our AWS guides on cohesive.net/docs or our quick video on YouTube.
launch-eiplaunch-source-dest

VNS3 Configuration

Grab your new Public DNS name, and open a new tab to https://address:8000 (in my case https://ec2-52-14-8-98.us-east-2.compute.amazonaws.com:8000). You’ll see the VNS3 Controller interface. The browser will complain about the SSL certificate used[1], but persist.
Your first time login is vnscubed and the password is the instance ID.[2] Log in, then change your passwords immediately.

config-login

Since this is the free edition, the easiest and most obvious way to get a license is to click the Free Edition License button. Enter your name and email (there’s a limit of 2 free editions per email, FYI). You’ll get an email right away with the license and instructions.

config-free-license

Click Upload License in the upper left menu and paste the license in.

config-license-upload

You have the option to specify a custom network address here. For simplicity you can just use the preconfigured default and hit ‘Submit and reboot’.config-address-settings
After the reboot, you’ll create unique X509 creds – clientpacks – by clicking Generate New from the left side menu. Enter a name for your topo and create a security token (password).

config-key

Last step for config! After the reboot with keys, click on Controller Peering. With Free Edition you’ve got 1 choice: set Controller #1 to this instance. Voilà!

config-peering

clientpack-info

 

Set up an OpenVPN client on Ubuntu 16.04 LTS

Back in AWS, we’ll go through a similar launch with Ubuntu 16.04 LTS. This time, we can use a t2.mico to get free tier savings.

server-1

As you click through the steps, make sure it’s in your same VPC as VNS3. This time you can use different security groups – like the vns3-client option in our AWS guides on cohesive.net/docs – but make sure you have SSH access and a keypair.

server-2server-3

Launch that little server and SSH into it. We’ll first add OpenVPN

sudo apt-get install -y openvpn

server-login

Add a clientpack to the server

Now is the fun part! On your VNS3 Controller, click on Clientpacks on the left menu.

clientpack-address

Click the Linux link under the Config Files column to view it.[3]

clientpack-url

From your terminal, you can create a new file and paste the full text of the config file. Name the clientpack as you create the file. I went with the very original cp1.conf

vi cp1.conf

Insert the full text of the conf page, then write and quit. Next, we’ll move the clientpack file to the directory where OpenVPN is stored:

mv cp1.conf /etc/openvpn

And finally, we’ll start OpenVPN to make sure the Overlay Network is working:

systemctl start openvpn@cp1.service

The tun0 connection should now be visible in ifconfig, and a client connection can be seen on the Runtime Status page:

clientpack-go

overlay-complete

Conclusions/Reminders

Next steps: Get more out of the Overlay Network by adding more clients (and clients outside of AWS) to see how they join the network together.

Don’t leave the lights on:  AWS Free Tier gives 750hrs per month for a Linux t2.micro instance. That’s more than enough to leave the Ubuntu server running full time, but if you also leave the client running it will start to incur charges outside of free tier.Notes

[1] There is nothing that can be done to prevent this warning. SSL was designed for certificates to be issued to a given named site, but it’s impossible to provide a certificate (from a trusted CA) that will correspond to the EC2 name (or any DNS name you might choose to give it).

[2] We use the instance ID as the initial password as this should only be known to the person that just launched the instance (or others within an administrative circle of trust).

[3] For more nuance, see the full process in the VNS3 Config guide

 

 

New: watch the guide as a video:

Posted by:

- - - -

Mesh networks are networks where each unit is connect to each other in the network, unlike other network topologies like a hub-and-spoke. Mesh networks connect these “nodes” together directly, which gives mesh networks the benefits of resilience and fault tolerance. If one node or access point in a mesh network goes down, the network can re-route traffic through many other nodes.

In cloud computing, mesh networks can add benefits of flexibility, cost savings, and scalability. Cloud users can set up a mesh network on an ad-hoc basis by deploying network nodes as needed then scaling the network back down to match demand.

Developers can build meshed networks on top of a cloud providers’ global network to extend traditional networks to the cloud.

Cohesive Networks - basic network topologies

Meshed in the cloud: WAN for all

A global wide-area network (WAN) is a prime example of networking projects that were previously cost-prohibitive. A WAN is simply a network built to transmit data over long distances, between different networks, or different types of networks.

Traditionally, WANs were limited to large organizations that could afford the investments in equipment and long-term telecom service contracts. The process for setting up a WAN required either investing in new data center locations or signing long-term contracts with telecommunication carriers. To add more points of presences, new facilities or new contracts with providers.

Now, cloud providers have made the investment to provide state-of-the-art facilities, experienced staff, and fantastic equipment distributed across the globe. Essentially, anyone with a credit card can create a global mesh network on a project by project basis. Want to add a point of presence? Just configure and launch your resources in a new cloud region.

Cohesive Networks - public cloud locations worldwide

Traditional WANs required hardware vendors, installation, server racks, equipment, staff, and miles of networking cables. Leased lines are a less capital-intensive option, but it still requires teleco carrier vendors, long sales cycles and long-term locked-in contracts.

Federated resources between cloud deployments is only a few clicks away. By building a meshed network from cloud providers’ networks, IT teams of any size can use cloud points of presence (POPs) to build a globally distributed WAN.

With Cloud WANs, developers can build on top of cloud-providers’ networking to extend traditional networks to the cloud. Plus using cloud networks lets you add security such as encryption, IPsec connections, VPNs into the public cloud networks.

Build vs. Buy: Control your network destiny 

Why build a WAN when you can just peer 2 Azure VLANs or 2 Amazon VPCs together? Good question. Here are answers in the form of more questions:

  • What if you need to peer more than 2 VLANs/VPCs?
  • What if you need to connect VPN gateways to more than one network?
  • What if you need to connect public IPs to more than one remote endpoint?
  • What if you need to connect with partners and customers who want to use IPsec over NAT-T?
  • What if you need both native IPsec and NAT-T?
  • Can you monitor your network separate from the provider?
  • Can you add network reliability without performance sacrifices?

Hint: VNS3 and meshed overlay networks can help you do all these things

And to dredge up the recent past, the Amazon S3 problems last week caused connectivity and uptime issues for thousands. It turned out that VNS3 customers with overlay networks they built were not having issues with connectivity or uptime.

Real life cloud WAN: Sigma Móviles in AzureSigma Moviles logo

Sigma Móviles considered the costs of owning and managing Tier 1 infrastructure to connect to partners. They opted to use the Azure cloud and wanted software-only networking appliances to easily connect to partners with a variety of devices.

Sigma Móviles is a software development and tech services company that develops mobile applications for iOS and Android. They are also a premium
SMS provider for Claro telecommunications in Peru.

Sigma Móviles uses Microsoft Azure to host and connect their mobile application development services around the world. With help from VNS3, Sigma Móviles can connect virtual machines (VMs) to their partners over VPN using secure, encrypted IPsec tunnels. Sigma Móviles estimates they save 40% on infrastructure costs.

Read the full Sigma Móviles use case here [PDF].

Posted by:

- - - -

On 1 March, 2017 the New York State Department of Financial Services will being enforcing a new cybersecurity requirement for all financial services in the state. The changes include: strong encryption, data security measures, timely reporting, and access controls. 

The Department of Financial Services (DFS) Cybersecurity Requirements are aimed at all financial services companies operating in the state of New York. The law, NY DFS 23 NYCRR 500, aim to protect the financial service industry from hackers, and more importantly, prevent data breaches.

The new law requires both strong preventative measure and timely disclosures, designed to improve responses to online attacks. Included in the requirements are minimum standards for access controls and data protection as well as response plans and methods for investigations after a data breach.

What does Section 500.15 require for encryption?

In particular, Section 500.15 Encryption of Nonpublic Information stands out.

Section 500 demands a cybersecurity program that “is adequately funded and staffed, overseen by qualified management, and reported on periodically to the most senior governing body of the organization.”

It also stipulates accountability in organizations by requiring “identification and documentation of material deficiencies, remediation plans and annual certifications of regulatory compliance to the Department of Financial Services (DFS).”

Why encryption matters for data in transit

Your data is safe in your data center. Your data is safe inside the cloud. But what about as it travels over the internet?

Data is most at risk when it travels across the public internet. To guard your data as it travels, or “in transit”  encryption ensures no one else can transcribe (or “sniff”) the contents. Encryption ensures that even if third parties have access to your data, it will still be encoded and unreadable.

A recent DFS poll found only 30% mandate that banking partners notify institutions of any breaches. “Defeating cybercrime requires not only prosecuting it, but taking necessary actions to prevent it,” said Manhattan district attorney, Cyrus Vance.

How you can ensure encryption in transit.

Encryption in transit is one of the best ways to avoid a costly data breach. Financial services firms use VNS3 to guarantee data is encrypted as it travels over the internet and in shared environments.

VNS3 is a network security software appliance that can connect data center networks and cloud networks using AES 256-bit encryption. Ensure Section 500.15 compliance by transporting data over secure Internet Protocol Security (IPsec) tunnels to any cloud or data center environment.

VNS3 acts as a virtual switch – providing the overlay connectivity to each of the compute hosts and switches traffic between hosts. VNS3 lets you own, configure, and manage your network. It is different from other networking products because you have ultimate control over end to end IPsec encryption, encryption keys, IP addressing and network topology.

Learn more about VNS3 for financial services or get in touch with our sales teams.

Posted by:

- - - -

Blog Resources