An overlay network is layered over the native networking layers, but can be independent from all underlying hardware and software. The overlay is dependent on the native networking layers.

VNS3 Overlay Networking

VNS3 uses software to create an overlay network (it’s defined in software, or SDN). VNS3 acts as an extension of your LAN network to your virtual machines in the cloud. The VNS3 Controller 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 Controller as “client servers” and they see the VNS3 Controller as the next logical hop in their topology.

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 travels 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.

The VNS3 Controller is configured with a subnet, giving it a range of IP addresses available for static allocation to the client servers; this will allow them to join the 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.)

Overlays vs. Cloud Provider Overlay

The difference between traditional networking and overlay networking is control. Software-defined networks control the entire network, rather than each device. In an overlay, you can have external access to switches and routers that formerly were closed and proprietary.

Overlay networks add layers of security and isolation when you're working in public cloud or shared environments.

In VNS3 network, all cloud servers communicate through the VNS3 Controller, and all data in motion between these servers is encrypted. The obvious benefits are added security and the ability to “own” your own cloud network control.

Why use an Overlay?

The Overlay Network is an essential component to the shared responsibility/trust model when running workloads in a 3rd party controlled environment like public cloud. Our customers use the Overlay Network to meet and exceed industry regulations like HIPAA, PCI, and NIST Cybersecurity Framework or internal IT requirement when migrating to cloud. See the FAQ article on 10 reasons to use the Overlay.

How do I use an Overlay?

To deploy the Overlay Network, unique cryptographic X.509 keys (generated on the VNS3 controller) and tied to a specific IP address in the Overlay Network subnet are distributed to the cloud or remote servers. These IP credentials are then used with a TLS client (like OpenVPN) to make an encrypted connection back to the VNS3 controller or VNS3 controller mesh. All communication between devices in the Overlay is passed through the VNS3 encrypted switch and depending on the use-case, communication to remote networks or the public Internet can routed through VNS3 as well.

Peering VNS3 Controllers for High Availability

When 2 or more VNS3 Controllers are peered, they exchange a given topology’s routing information and share client server credentials and connectivity details. Any connected client servers can connect to any of the VNS3 Controllers in the topology, and in turn any Controller will still be able to access the client(s), no matter which Controller the client server is connected to at the time.

Similarly, all IPsec tunnels connected to any Controller are accessible via the other Controllers and all client servers. Sometimes it helps to think of 2 VNS3 Controllers as a pair of high-availability switches or a pair of routers running HSRP (Hot Standby Routing Protocol).

Peered Controllers provide overlay network failover and high availability. In the event the primary Controller is unavailable, a client server will step in and the others will automatically attempt to connect the new Controller in order to restore the topology.

For IPsec failover, the IPsec device at the endpoint should have its own high availability features to detect if the tunnel is down and should attempt to reconnect.