Cloud Setup VNS3 VNS3 Management System VNS3 LNKe VNS3 NATe VNS3 PeopleVPN Network Edge Plugins Upgrading IPsec Troubleshooting Guide

VNS3 LNKe

Introduction

VNS3 LNKe allows users the ability to more easily extend their network edge by connecting VNS3 LNKe to another VNS3 transit controller via a fully encrypted VPN connection. This new connection can now accept traffic between the transit pair.

Why?

LNKe provides the ability to connect to other VNS3 edge controllers via a secure VPN connection, making extending your network edge to new environments even easier.

VNS3 allows users the ability to build and manage highly sophisticated networks that are ever changing. These networks frequently span multiple clouds, datacenters, even IOT deployments. With VNS3 you can enable secure transit via the following methods:

1. IPsec connections between VNS3 and IPsec compatible devices (including other VNS3’s).
2. Peering VNS3 controllers via TLS connections, with BGP for route distribution.
3. Connecting VPN clients (humans & machines) to the VNS3 overlay network.
4. Connecting via Generic Route Encapsulation (GRE).

These allow the building of networks with complex connectivity and security requirements while still maintaining a system that is easy to reason about.

Previously, the VNS3 to VNS3 connections indicated above were made by connection methods #1 or #2. Now, LNKe provides the ability to connect to other VNS3 edge controllers via VPN connection, method #3. This is a simpler way of securely extending your network edge.

Creating a Link

Creating a link requires uploading a VPN configuration file. Currently, we only support OpenVPN conf files.

1. Download or Copy conf from your VNS3 Transit Controller. (1)
2. Click New Link on the VNS3 LNKe Links page.
3. Enter a name and interface number for your Link. Then Upload or Paste your conf file. (2)
4. Click Create Link.

The conf file will be uploaded and a new VPN process will be started. It may take a few seconds for the link to connect, during which the interface will not exist.

(0) Setup peering on LNKe controller if it is not already set up.

(1) Grab a clientpack from the clientpacks page on the Transit VNS3 Controller

(2) Create a new link

Connecting

It might take a few seconds to connect depending on your link’s failover settings. That is, if a connection can’t be made with the primary address, it will failover to the second, third, etc. See the section on failover for more information on tuning this failover time.

Link Actions

Links support the following management actions via the UI or the API:

1. Disconnect - stop the link VPN connection.
2. Reconnect - restart the link VPN connection.
3. Edit Link Policy - Edit the policy contained in the VPN conf file (this will restart the connection).
4. Create Link tags - Create management tags for this link.
5. View Link logs - View the logs associated with the VPN connection.

You can access the Link actions via the Action dropdown in the UI.

Link Specific Policies

These are policies that are written to this link’s VPN conf file and therefore only apply to this link. See global policies for managing link VPN policies that apply to all links.

Tags

Tags are currently only used for management purposes. In the near future, you will be able to create firewall rules associated with tags for easier policy management.

Global Link Policies

Global link policies are applied to a new link when it is created. Stated another way, editing the global link policies will not affect already created links.

To edit the global link policies, click the Edit Global Policies link in the top right corner of the Links page.

Adding Routing

Once you have a new LNKe up and running, your VNS3 LNKe controller will recieve any routes advertised by the VNS3 Transit Controller. For example, lets say the VNS3 Transit controller can route to the CIDR 10.0.1.0/24 and that the VNS3 LNKe controller provides access to a new CIDR range, 10.0.2.0/24. So in short, the connectivity paths we would like to set up are the following:

1. Allow traffic from the LNKe subnet to the VNS3 Transit Controller’s routable and advertised subnets. In this case, allow traffic from 10.0.2.0/24 -> 10.0.1.0/24.
2. Allow traffic from the Transit controller to the VNS3 LNKe’s subnet. In this case, allow traffic from 10.0.1.0/24 -> 10.0.2.0/24.

To accomplish this we will need 2 routes. Both of these routes will be placed on the VNS3 Transit Controller:

1. Route advertisement for 10.0.1.0/24
2. A static route that sends 10.0.2.0/24 traffic to the LNKe gateway:

Here the gateway provided is the overlay IP address of the VNS3 LNKe Controller. In this case, that is 172.31.1.11. This traffic is sent to the tun0 interface on the VNS3 Transit Controller which forwards that traffic to 172.31.1.11, which is the LNK controller in the overlay network.

The routes on the VNS3 Transit Controller would look like this:

Link Failover

Link failover can be configured using multiple remotes in the Link VPN conf file. By default, the VNS3 Transit Controller clientpack will place 2 remotes at the end of the conf file, 1 remote for the primary private IP address and one for the public IP address if it exists.

Adding a Secondary Transit Controller to the Conf

The remotes are defined at the bottom of the clientpack conf file. To add a secondary controller for failover, you’d simply add a new remote line with the IP address or DNS of your secondary controller:

remote 10.0.1.165 1994

This can be done by editing the Link Policy from the Links page:

With this configuration, the Link will attempt to connect to the primary VNS3 Transit controller at 10.0.1.169 first before failing over to the secondary at 10.0.1.165.

Adjusting failover time Failover time can be adjusted with the following OpenVPN options:

ping [number]
ping-restart [number]
hand-window [number]

Please refer to this answer for our recommended best practices on configuring client failover times.

API

The API specification is currently being written for the LNKe API and will be posted here shortly.