Connect multiple nodes

This tutorial will demonstrate how VpnCloud can be used to connect multiple nodes, so that each node can reach all other nodes even when one or both nodes are behind a NAT gateway.

You can use this setup if you have multiple computers where some of them are behind NAT gateways and some have dynamic IP addresses and you want those computers to be able to communicate nonetheless.

You can also use this setup if you have a set of servers at different locations (e.g. different hosting providers) and you want to create a secure overlay network spanning those different network locations in order to connect those servers.

Initial peer addresses

Whenever a node starts up, it needs to find out the addresses of the other nodes. VpnCloud uses a peer exchange, so that nodes tell each other the addresses of the other nodes. That means that a node only needs to know the address of a single other node in oder to join the VPN network (however, the more known peer on startup, the better). There are several ways to achieve this:

Static node addresses

The easiest way, is a node with a well-known static address that is not behind a NAT router. This is often the case when you have a server running at a hosting provider but is very rare for consumer Internet providers.

Dynamic DNS

Another option, is to register a dynamic DNS name for your node (most DSL routers support this) and make sure, that the VpnCloud software is reachable (e.g. by registering a static port forwarding in your DSL router). Of course, this node can only be used as an entry point to the network if it is online. If you do not have a computer on the network, that is online 24/7, you can register DNS names and setup port forwardings for all of your nodes, so that all of them can be contacted.

To use DynDNS, you need to find a DynDNS provider (there are free ones), register an account with it and setup a dynamic DNS name. Finally, your router needs to be configured to update the DNS entry each time the dynamic IP changes. Most consumer routers support this feature and the bigger DynDNS providers have good documentation on how to setup the most popular routers.

Beacons

The final option that VpnCloud offers, is the beacon feature. This feature allows your nodes to exchange their addresses via public storage locations like Dropbox, Github Gists or even Twitter. This option is not as reliable as the other options as the address information can be outdated. This tutorial does not cover this option, please read the article about it for more information.

Configuration options

Since this tutorial aims for simplicity, it will mostly work with the defaults for configuration options. The following minimal options are necessary.

You need a common IP range for all of your nodes. The most important thing about this IP range, is that it should be free, i.e. unused outside of the VPN. The most common choices for this IP range are the private IP ranges 10.X.Y.Z and 192.168.X.Y. However, NAT gateways and virtualization software commonly use parts of 192.168.X.Y so that an arbitrary part of 10.X.Y.Z like 10.67.89.X might be the best choice.

Your network needs a common password. This password should obviously be secure as it is the key to your VPN. You can use any string as password. If you want to create a random password, you can call vpncloud --genkey (this actually creates key pairs but the keys also make good passwords as they are random). There is also an advanced encryption mode, that uses key pairs and trusted keys instead of a common password, but this tutorials keeps it simple.

Setting up VpnCloud on the nodes

Create a new network config with the interactive wizard using the following command:

$> sudo vpncloud config

The wizard will ask some basic questions that you have to answer:

First you have to select the option New network in order to create a new network.
Next, give your network a name. Use a simple name with lower case letters and without spaces.
Select Simple (minimal options) as configuration mode.
As Peer addresses enter a list of the public addresses of all peers with static addresses or DynDNS names here. You can add IP addresses as well as DynDNS hostnames. Put commas , between different addresses.
Enter and confirm a secure password.
As Virtual IP address enter an IP from your chosen IP range. Make sure that each node gets is own unique address, e.g. by counting up the number in the last place (10.67.89.1, 10.67.89.2, ...).
If all is correct, finish ans save the configuration.

Next, you need to start the VpnCloud network and enable it to automatically start:

$> sudo service vpncloud@mynet start
$> sudo systemctl enable vpncloud@mynet

The mynet in those commands needs to be the same as the network name you chose in the first step.

Here is an example:

Using the VPN

Once all nodes have been configured and started as described you can use your VPN. You should be able to ping other nodes by their IP:

$> ping 10.67.89.1

and connect to them via SSH (assuming an SSH server is installed and enabled at the destination):

$> ssh 10.67.89.1

Depending on the software installed on the destination, you should be able to do the following:

Start graphical applications using ssh -X (X-Forwarding).
Access your files on the remote computer by entering sftp://10.67.89.1 as location in your file manager (most of them support sftp://).
Access other computers on that network by using the peer as a jump host, i.e. log on to your peer and there run another ssh to connect to the other computer.
Access services on the remote network via SSH port forwarding, e.g. ssh -L 80:fritz.box:80 10.67.89.1

Naming hosts

Tired of remembering which peer is 10.67.89.1 and which one is 10.67.89.2? You can give them names.

Just edit /etc/hosts

$> sudo nano /etc/hosts

and add lines for all peers like this:

10.67.89.1 mynode1.mynet
10.67.89.2 mynode2.mynet

Make sure to not mess up the other entries in that file, they are important.

Debugging problems with the VPN

Here are some commands and things to check in order to debug your setup.

This will tell you whether VpnCloud is running and will show some log entries that might contain an error message:
```
$> service vpncloud@mynet status
```
Check the log file at /var/log/vpncloud.mynet.log. If you see repeated errors or warnings this might be the reason for your problems. Also this file will contain a history of peers coming and going.
Check your interface configuration to see if the vpncloudN interface exists and has a correct address and prefix configuration (e.g. inet addr 10.67.89.1/24):
```
$> ip addr show
```
Check your routing table to check that your chosen private address region (e.g. 10.67.89.0/24) is routed via your vpncloud device (dev vpncloud0):
```
$> ip route show
```
Ping peers to see if you have a working connection to them:
```
$> ping 10.67.89.1
```
Look at the VpnCloud statistics at /var/log/vpncloud.mynet.stats.
- The peers: list will contain all current connections.
- The claims: list in forwarding_table: will contain all known VPN addresses and to which node they belong.
- Under peer_traffic: and payload_traffic: you can see how much traffic is flowing to the peers and the addresses within the VPN.
- The values under invalid_protocol_traffic and dropped_payload_traffic might indicate problems, however even nodes that work normally can have some packets listed here.