Cohesive Blog

Due to popular demand, we’re updating a classic 2014 blog by Sam Mitchell.

About Multicast in Cloud

In networking, multicast is the delivery of a message or information to a group of computers simultaneously in a single transmission from the source.

Multicast: one to many. Image via Wikimedia commons

Multicast: one to many

IP multicast is a technique for one-to-many communication over IP infrastructure in a network.  Multicast uses network infrastructure efficiently by requiring the source to send a packet only once, even if it needs to be delivered to a large number of receivers.

The most common transport layer protocol to use multicast addressing is User Datagram Protocol (UDP).  UDP multicast is widely deployed in enterprises, commercial stock exchanges, and multimedia content delivery networks.

Multicast has been used in data centers and private networks service discovery. Enterprise applications or clustering stacks use multicast to do things like service election and discovery. With more than 70% of workloads moving to cloud, multicast is a key feature for cloud enablement and hybrid cloud networks.

Why is multicast disabled in cloud?  

Sending one source pack to every host in the network it very “chatty.” Multicast scales to a larger receiver population by not requiring prior knowledge of who or how many receivers there are.   If you think about public cloud networks, you’re usually on a shared VLAN or LAN in a multi tenant environment.  

AWS and other cloud providers block multicast and broadcast in the hypervisor (layer 2 network traffic). Cloud provider also use similar types of protocols to provide the cloud to you, the customer. Allowing a “chatty” protocol to span over the cloud network could have a serious impact on the performance of the cloud as a whole.

Rather than re-architect, use VNS3 to enable multicast in public cloud

Cloud users come to Cohesive Networks to help enable multicast applications in the cloud. You too can use a VNS3 Overlay Networks to create a completely encapsulated over-the-top network in the cloud.

VNS3 Overlay Network allows users to redistribute the normally blocked layer 2 network traffic through encapsulated tunnels managed by your VNS3 network appliance. This patented technique is similar to many of the “roll your own” solutions covered in the Internet KB. The main differences are that VNS3 increases performance through dynamic compression/LAN optimization. Plus, VNS3 adds more network features like encrypted router, switch, firewall, vpn concentrator, ADC, and UTM all in one software device.

VNS3 Overlay Network traffic moves through the cloud on UDP 1194. All traffic in the Overlay Networks is encrypted (don’t worry dynamic compression means most enterprise traffic gets the encryption benefit at zero performance cost) and encapsulated. As a result the cloud provider doesn’t block the traffic and VNS3 redistributes as appropriate.

3 Steps to enable multicast with VNS3 overlay:

Step 1 – Launch and Deploy VNS3 Controller

Your VNS3 controller acts as an encrypted switch for all Overlay Network traffic in the cloud, and acts as an encrypted router to address spaces available outside the Overlay Network via tunnels (GRE), VPNs (IPsec or SSL/TLS), routes (VPC/VNET peering, Direct Connect/ExpressRoute), and so on. VNS3 is available in the major cloud catalogs (try it now in AWS or Azure) .

Step 2 – Generate the VNS3 Overlay Network Clientpacks
To deploy the VNS3 Overlay Network, you will use VNS3 to create unique cryptographic X.509 credentials (called clientpacks). Your clientpacks are associated with a specific IP address inside the VNS3 Overlay Network space. This operation is as simple as selecting an Overlay Network address space and click Generate.  VNS3 will do the heavy lifting (like key generation, address burn in, and configuration file creation).  Next, you’ll distribute clientpacks to your cloud-based servers to build the overlay.

Step 3 – Connect cloud Servers to the Overlay Network
You can next distribute your clientpacks to your cloud-based servers, along with a SSL/TLS client (like OpenVPN).  These clientpacks will allow the Overlay Network to pass/receive the multicast or broadcast packets.  The SSL/TLS client process uses the clientpack to make an encrypted connection to the VNS3 Controller.

This process is similar to how a physical server connects to a switch using a CAT cable. VNS3 instead makes the connection via software (aka, it’s virtual) instead of in hardware.  Overlay Network traffic then passes through the VNS3 encrypted switch.

Finally, you can use your VNS3 Controller to build site-to-site connections to complete a hybrid cloud deployment that leverages multicast and broadcast. Check out the diagram below for a hypothetical multicast deployment in AWS.

multicast with vns3



Bonuses from VNS3:

Testing – You can use your own application for testing but we can provide some simple python scripts for sending and receiving multicast messages.

Network Sniffer – You can use the VNS3 Network Sniffer from the Controller UI as a troubleshooting tool. You can monitor both the public IP network interface and the tun0 Overlay Network interface. See the FAQ on Network Sniffer

Sealed Overlay Network – You can choose to route all server traffic through the Overlay Network per the requirements of your use-case.  To route all all client traffic through the VNS3 overlay, see this FAQ guide.

See our complete Setup and Configuration (PDF documentation) for more details on clientpacks , peering  and configuring.

Posted by:

- - - -

By Bob Smetana

How to guide: Set up a Windows Server Failover Clustering (WSFC) with SQL server AlwaysOn using VNS3 Overlay Networks

Windows Server Failover Clusters (WSFCs) are often an essential piece of critical systems. WSFCs provide a suite of tools to make systems faster and more reliable. Configuring WSFCs  with VNS3 allows you to cluster physical and virtual servers regardless of physical location and network configuration.

While you can set up a WSFC in any environment,  it is still up to you to protect your data in motion between nodes.

Suppose you have a node that is required to be off site. In order to remain secure, you must use additional hardware to provide connectivity from one location to the other.

VNS3 solves the security and connectivity issues elegantly.  Each node can be connected to the VNS3 overlay network via a clientpack – each machine would then have an encrypted connection to a secure virtual network you control.  All that is required for each node is an internet connection and open security groups to your VNS3 controller’s IP address.

In this example, VNS3 lets you use any cloud environment with an additional a layer of security and control over top.

This configuration frees you from the bounds of hardware and unfamiliar software without compromising security or flexibility.  You can even cluster virtual machines in any major cloud with on-site machines, allowing your users to enjoy security, high availability, and low latency.

In Windows, connections to VNS3 appear as ethernet adapters. From the perspective of each node, this configuration appears identical to a fully local configuration, with all nodes on the same network and subnet.  This simplifies Failover Cluster implementations and helps administrators conceptualize complex network ecosystems.

WSFC dns

In Windows, connections to VNS3 appear as ethernet adapters.

VNS3 can also provide a modular approach to Failover Clustering.  If you already have a WSFC implementation, VNS3 can connect to your cluster’s local network via IPsec, allowing your existing nodes to communicate with additional nodes anywhere in the world.

WSFC final

Availability group and listener communicating via the VNS3 overlay network.

Watch Bob Smetana’s full demo on YouTube:

Note – This guide uses the WSFC CloudFormation template and Windows server 2012 R2 and SQL server 2014 Enterprise. Other editions will work, but won’t match the video guide exactly.

See more VNS3 setup and troubleshooting guides on our Product Resources page: and on our YouTube channel:

Posted by:

- - - -

In July, we announced the release of our latest version of VNS3, 4.0. The features and functions are obviously the big reasons for updated the software-only virtual appliance, but I wanted to take a moment to point out some of the huge ways VNS3 has changed from the visual side.

VNS3 4.0 has had a major facelift.

4.0 new status page

Watch a walk through of the new VNS3 4.0 updates



Change your password, now!
If you’re launching a brand new VNS3 4.0 from AWS or Azure Marketplaces, the very first thing you’ll notice is the bright red warnings to update passwords at your first login. We are a security company, so it’s pretty important to us to help our customers stay secure. Even though passwords and logins seem like a small deal, weak passwords have brought down some of the biggest and best.

VNS3 4.0 reset password page

Want some high availability with that Controller? 
After you log in and change that password, the next screen you’ll see is the Getting Started page. Here are your usual 3 options for adding a license and configuring your VNS3 Controller.

At the bottom of those options you’ll see a new section : Configure HA Backup server. If you’ve got VNS3:ms, you can add this VNS3 Controller to your configuration and add high availability with VNS3:ha. This string of numbers and letters is the UUID you’d use to enable HA.

VNS3 4.0 getting started page

Easier Clientpack organization and page view

VNS3 4.0 clientpacks page


Customers with complex networks and several clientpacks will enjoy this update. One of the UI redesign requests we got was to add  paginated, sortable and searchable tables for Clientpacks. These types of organizational tables will also be in the sections for Peered connections, Overlay Network devices, and IPsec tunnels.

Dig the new colors
We hope you dig the new colors. Whether you upgraded an existing VNS3 Controller to 4.0 or went through the launch steps, we hope you like the new UI.

Easier navigation
We’ve updated the main menu categories. Don’t worry, it’s nothing Windows Vista drastic. 

Up at the top are still the Runtime, Overlay, and Connections sections. This is where you’ll spend most of your time configuring and editing VNS3.

We scooted Containers up between Connections and Maintenance, since it’s pretty important for customers who use the VNS3 plugin system.  In the Container section are still controls and links to container networks, container images and the list of all your configured containers. Need a quick refresher on VNS3 Containers? Here’s a video on our WAF plugin.

We’ve booted the Admin section down to the bottom of the list. Hopefully you won’t visit this section as often as the other UI menu items. But, just in case anything goes wrong the last 2 sections are here to help. Snapshots, licensing, remote support, and admin settings live here.

2 new menu items in the Admin section
The new 4.0 version lets you install your own SSL certificates. In the HTTPS Certs page you can upload either SSL Certificates or SSL keys. Easy enough.

In earlier versions, we squirreled away the “factory reset” page. Instead of looking for the paper clip hole in the back of your device, we made this handy menu item. Fear not, we added a step to make sure you’re really certain you want to reset the VNS3 Controller.

VNS3 4.0 reboot warning


Posted by:

- - - -

Blog Resources