VPNCloud: Building Your Private Network in the Cloud

Project status as of September 2026. VPNCloud is written in Rust. The last release is 2.3.0 from December 23, 2021, the most recent changes in the repository are from March 2024. The project is not archived, but is effectively unmaintained. For a new network it’s wiser to choose actively maintained solutions from the “Mesh VPN” series: what is a mesh network on WireGuard, Tailscale, ZeroTier and NetBird, Headscale or WireGuard manually. This article is useful for those who already run VPNCloud.

VPNCloud is a peer-to-peer mesh VPN over UDP with encryption and NAT traversal. Each node in the network can exchange data with any other directly, without a central server that would carry all traffic. Nodes can combine servers in different clouds, home and office computers, single-board computers like Raspberry Pi.

Suitable use cases

• Access to home and office resources — file server, cameras, internal services — as if you were on the local network.
• Connecting servers at different providers via private addresses.
• Service isolation: part of infrastructure is available only inside the VPN.
• Nodes behind NAT: not every node needs a public address, one accessible node is enough for others to find each other.

How it works

VPNCloud transmits data over UDP. For the initial connection, a node needs the address of at least one other node (peers). Learning about the network via that node, nodes establish direct connections between each other, including through NAT. A virtual interface is created on each node:

• tun (default) carries IP packets — layer 3 network;
• tap carries Ethernet frames — layer 2 network; ARP and DHCP pass through it.

The operation mode (mode) determines how a node selects the recipient: hub broadcasts everything to everyone, switch remembers MAC addresses, router forwards packets according to the subnets announced by nodes. The default value normal means switch for tap and router for tun.

Installation

Prebuilt .deb and .rpm packages (amd64, arm64, armhf, armel, i386) and static binaries are available on the releases page on GitHub. Example for Debian or Ubuntu on amd64:

wget https://github.com/dswd/vpncloud/releases/download/v2.3.0/vpncloud_2.3.0_amd64.deb
sudo apt install ./vpncloud_2.3.0_amd64.deb
vpncloud --version

The package installs a systemd service template vpncloud@.service: the network configuration is stored in /etc/vpncloud/NAME.net, the service is started as vpncloud@NAME.

Configuration format

The configuration is a YAML file. Below are the main parameters based on the example from the project repository (assets/example.net.disabled):

Parameters network and crypto: aes256, which appear in older instructions, are not present in the 2.x format: the network is separated by a password or keys.

Scenario 1: two servers

Two servers with public addresses 203.0.113.1 and 203.0.113.2 are joined into the network 10.10.10.0/24.

Server A, file /etc/vpncloud/mesh.net:

listen: 3210
peers:
  - 203.0.113.2:3210
crypto:
  password: "long-random-password"
ip: 10.10.10.1/24

Server B differs only by the peer address and its own IP:

listen: 3210
peers:
  - 203.0.113.1:3210
crypto:
  password: "long-random-password"
ip: 10.10.10.2/24

Start and enable autostart on each server:

sudo systemctl enable --now vpncloud@mesh
ip addr show vpncloud0
ping 10.10.10.2   # from server A

Port 3210/UDP must be open in the firewall on both servers.

Scenario 2: nodes behind NAT

A home computer and an office server are behind NAT, the cloud server 203.0.113.10 has a public address. The cloud server becomes the initial connection point:

# cloud server
listen: 3210
peers: []
crypto:
  password: "long-random-password"
ip: 10.10.10.10/24

# home computer (the office server has its own ip, e.g. 10.10.10.200/24)
listen: 3210
peers:
  - 203.0.113.10:3210
crypto:
  password: "long-random-password"
ip: 10.10.10.100/24

Nodes behind NAT connect to the cloud server, learn about each other and attempt to establish direct connections. If the address of the connection point changes, use a DNS name or the beacon mechanism.

Scenario 3: access to a subnet behind a node

The cloud server serves the internal subnet 192.168.50.0/24, the home computer needs access to it. In tun mode the node announces the subnet via claims, and the interface address is set with a broader mask so that all VPN subnets are reachable via it (as recommended by the VPNCloud manual):

# cloud server
listen: 3210
peers: []
crypto:
  password: "long-random-password"
ip: 10.10.10.30/16
claims:
  - 192.168.50.0/24

On the cloud server you need to enable packet forwarding and allow it in the firewall:

echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpncloud.conf
sudo sysctl --system
sudo iptables -A FORWARD -i vpncloud0 -o eth0 -d 192.168.50.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o vpncloud0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

On the home computer — a route to the subnet via the VPN interface:

sudo ip route add 192.168.50.0/24 dev vpncloud0

If devices in the 192.168.50.0/24 subnet do not know the return route to the VPN, add it on their gateway or enable masquerading on the cloud server for traffic from the VPN (iptables -t nat -A POSTROUTING -s 10.10.0.0/16 -d 192.168.50.0/24 -j MASQUERADE).

Recommendations

• Network password — long and random; for strict requirements use keys instead of a password.
• VPN subnet should not overlap with the local networks of nodes.
• Multiple connection points in peers increase fault tolerance if one of them becomes unavailable.
• rp_filter. When routing subnets, strict reverse-path filtering can drop packets; VPNCloud has the device.fix-rp-filter parameter, more about the mechanism in the article about rp_filter.
• Choice for the future. Since the project is not actively developed, do not expect vulnerability fixes. For new networks, use maintained solutions from the Mesh VPN series.