VPNCloud: Building Your Private Network in the Cloud
Published on June 25, 2025
VPNCloud: Building Your Private Network in the Cloud
In a world where more and more services are moving to the cloud and remote work has become the norm, secure and private access to your resources is more important than ever. Traditional VPN services, while solving some problems, are often centralized and may not be the most flexible solution for creating your own secure network between multiple servers, devices, or even offices.
This is where VPNCloud comes in — a lightweight, decentralized, and flexible tool for creating private mesh networks (full-mesh VPN). It allows you to connect different servers, computers, Raspberry Pis, and other devices into a single encrypted virtual network, which can be deployed anywhere — from your home router to cloud servers.
What is VPNCloud and why use it?
VPNCloud is an open-source project written in Go that enables you to create virtual private networks (VPNs) in a “full mesh” topology. This means each device in your VPNCloud network can communicate directly with any other device in the same network without passing through a central server.
Why is this useful?
- Secure access to home/office resources: You can access file servers, IP cameras, or smart home systems from anywhere in the world as if you were on the local network.
- Connecting cloud servers: If you have servers across different cloud providers (e.g. DigitalOcean, AWS, Google Cloud) or regions, VPNCloud allows them to communicate using private IP addresses — improving security and simplifying interaction.
- Service isolation: You can segment parts of your infrastructure into a private, unreachable network and communicate with it only through VPNCloud.
- Traffic concealment: All traffic within VPNCloud is encrypted, protecting it from eavesdropping.
- Flexibility: There’s no need for a dedicated IP address or port forwarding for every node. VPNCloud nodes can be behind NAT.
How does VPNCloud work?
VPNCloud operates over the UDP protocol. Each node in the VPNCloud network has a unique identifier and establishes an encrypted connection with other nodes. For initial connection, nodes need to know an “entry point” (a seed node) to help them discover peers. Once connected, traffic is routed directly between nodes, ensuring low latency.
VPNCloud creates a virtual network interface (a TAP interface) on each device, through which encrypted traffic flows. This interface is assigned an IP address from your VPNCloud private subnet.
Installing VPNCloud
VPNCloud is a single binary that’s easy to install.
Linux (example for Debian/Ubuntu):
Download the latest version: VPNCloud is available as ready-to-use binaries on the project’s GitHub releases page or via the official repository. For Debian/Ubuntu:
echo "deb https://repo.ddswd.de/deb stable main" | sudo tee /etc/apt/sources.list.d/vpncloud.list wget https://repo.ddswd.de/deb/public.key -qO - | sudo apt-key add - sudo apt update sudo apt install vpncloud
For other systems or architectures (ARM, macOS, Windows), download the corresponding binary and place it in your PATH (e.g.
/usr/local/bin
).Verify installation:
vpncloud --version
Configuration examples
VPNCloud is configured using a YAML file. Let’s look at several common scenarios.
Key parameters:
network
: Unique name of your VPN network. All nodes must use the same name.password
: Password for your network. Required for encryption.ip
: IP address this node will have in the VPNCloud network. Must be unique per node.peers
: List of other nodes (public IPs/domain names and ports) this node will try to connect to. These are called seed peers. It’s enough for each node to know at least one reachable seed node.listen
: Address and port where VPNCloud listens for incoming connections.0.0.0.0:port
means all interfaces.mode
: Mode of the virtual interface:switch
(default): Works like an Ethernet switch (Layer 2). Good for entire subnets or DHCP. Uses TAP.router
: Works like an IP router (Layer 3). Routes IP packets. Uses TUN. Lighter than switch if you don’t need L2 features.hub
: Simple hub. Broadcasts all traffic to all peers (less efficient).
crypto
: Encryption type. Default isaes256
. Recommended.
Scenario 1: Two cloud servers (basic setup)
Let’s say we have two cloud servers, Server A and Server B, and want to connect them in a private 10.10.10.0/24
network.
Server A (Public IP: 203.0.113.1):
config-a.yaml
:
network: mycloudvpn
password: "MySecurePassword123"
ip: 10.10.10.1/24
listen: 0.0.0.0:1194
peers:
- 203.0.113.2:1194
Server B (Public IP: 203.0.113.2):
config-b.yaml
:
network: mycloudvpn
password: "MySecurePassword123"
ip: 10.10.10.2/24
listen: 0.0.0.0:1194
peers:
- 203.0.113.1:1194
Start VPNCloud:
sudo vpncloud -c config-a.yaml # On Server A
sudo vpncloud -c config-b.yaml # On Server B
Check:
After launching on both servers, you should see a new network interface (e.g. vpncloud0
). Run ip a
or ifconfig
to verify it exists and has the correct IP. Then try:
ping 10.10.10.2 # From Server A
ping 10.10.10.1 # From Server B
If it works — your private network is up!
Scenario 2: Three nodes with NAT traversal (home, office, cloud)
You have:
- Home PC (behind NAT): Internal IP 192.168.1.100, changing external IP.
- Office server (behind NAT): Internal IP 192.168.2.10, changing external IP.
- Cloud VPS (public IP): 203.0.113.10.
VPNCloud supports NAT traversal via hole punching. You need at least one public-facing seed node.
Cloud VPS (seed node):
network: mysecuremesh
password: "AnotherVerySecurePassword456"
ip: 10.10.10.10/24
listen: 0.0.0.0:1194
Home PC:
network: mysecuremesh
password: "AnotherVerySecurePassword456"
ip: 10.10.10.100/24
listen: 0.0.0.0:1194
peers:
- 203.0.113.10:1194
Office Server:
network: mysecuremesh
password: "AnotherVerySecurePassword456"
ip: 10.10.10.200/24
listen: 0.0.0.0:1194
peers:
- 203.0.113.10:1194
Launch order:
Start VPNCloud on Cloud VPS first. Then start Home PC and Office Server. They’ll discover each other and establish direct connections through NAT.
Test:
Try pinging the other nodes by VPNCloud IP:
ping 10.10.10.10
, ping 10.10.10.100
, ping 10.10.10.200
Scenario 3: Routing to a real network (router
mode)
Server C has public IP 203.0.113.30 and an internal subnet 192.168.50.0/24. You want your Home PC to access that subnet through VPNCloud.
Server C acts as a router using mode: router
.
Server C:
network: myroutedvpn
password: "RouterVPNPasswordXYZ"
ip: 10.10.10.30/24
listen: 0.0.0.0:1195
peers: []
mode: router
forward:
- 192.168.50.0/24
Important for Server C:
Enable IP forwarding:
sudo sysctl -w net.ipv4.ip_forward=1 # To persist: # net.ipv4.ip_forward = 1
Setup iptables rules:
sudo iptables -A FORWARD -i vpncloud0 -o eth0 -j ACCEPT sudo iptables -A FORWARD -i eth0 -o vpncloud0 -j ACCEPT sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Home PC:
network: myroutedvpn
password: "RouterVPNPasswordXYZ"
ip: 10.10.10.100/24
listen: 0.0.0.0:1195
peers:
- 203.0.113.30:1195
mode: router
Add route on Home PC:
sudo ip r add 192.168.50.0/24 dev vpncloud0
Now the Home PC can access the 192.168.50.0/24 subnet via VPNCloud.
Important Notes & Best Practices
Passwords: Always use strong, unique passwords for your VPNCloud networks — they are your main security mechanism.
Ports: Ensure VPNCloud listen ports are open on all firewalls.
IP planning: Avoid conflicts with existing local networks.
DNS: For advanced setups, configure internal DNS or use
/etc/hosts
.Run as a service: Use systemd or similar to auto-start VPNCloud. Example:
Create
/etc/systemd/system/vpncloud@.service
:[Unit] Description=VPNCloud instance %i After=network-online.target [Service] ExecStart=/usr/local/bin/vpncloud -c /etc/vpncloud/%i.yaml Restart=on-failure LimitNOFILE=65536 [Install] WantedBy=multi-user.target
Then run:
sudo systemctl enable vpncloud@config-a sudo systemctl start vpncloud@config-a sudo systemctl status vpncloud@config-a
Seed node reliability: Each node only needs one working peer. If no static IP — use DDNS or multiple seed nodes.
Performance: Encryption and network capacity can affect performance. For high throughput, use stronger hardware.
VPNCloud is a powerful, flexible tool for building your own private networks. With a little setup, you get secure, decentralized access to your distributed infrastructure!
Related Posts
055 | Why Do We Need Centralized Logging? Making Sense of Log Chaos
July 17, 2025
049 | UniFi: Where Style, Simplicity, and Centralized Network Management Meet
July 11, 2025
048 | Mikrotik: What Is It and Why Is It Ideal for Small Business?
July 10, 2025
045 | FastPanel: A Powerful and User-Friendly Control Panel for Efficient Server Management
July 7, 2025