VPS for WireGuard: Hub-and-Spoke VPN for IoT and Remote Access

Why WireGuard needs a VPS

WireGuard creates encrypted peer-to-peer tunnels, but at least one peer in each tunnel needs a stable, publicly reachable IP address and an open UDP port. A VPS provides exactly this: a fixed public IP, a single open UDP port (default 51820), and guaranteed uptime.

Devices behind home broadband, cellular connections or office NAT all make outbound connections to the VPS hub. From the VPS, you can reach every connected device’s local subnet as if it were on your own network. This is the hub-and-spoke pattern.

WireGuard vs OpenVPN on a VPS

WireGuard is the right choice for IoT and industrial remote access. It is faster, simpler to configure, and natively supported by the leading cellular router brands.

VPS sizing for WireGuard

WireGuard’s resource usage is dominated by the volume of traffic passing through it, not the number of connected peers. A hub serving 100 remote sites with moderate telemetry traffic (each site sending a few kilobytes per minute) runs comfortably on a 2 vCPU / 2GB RAM VPS.

Setting up WireGuard on a VPS

# Install WireGuard (Ubuntu 22.04 / 24.04)
sudo apt install wireguard

# Generate server keys
wg genkey | tee /etc/wireguard/server_private.key | wg pubkey > /etc/wireguard/server_public.key

# Create the interface config
cat > /etc/wireguard/wg0.conf << 'EOF'
[Interface]
PrivateKey = YOUR_SERVER_PRIVATE_KEY
Address = 10.0.0.1/24
ListenPort = 51820
PostUp   = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# Site 1 router
PublicKey = PEER_PUBLIC_KEY
AllowedIPs = 10.0.0.2/32, 192.168.1.0/24
EOF

# Start and enable
sudo systemctl enable wg-quick@wg0 --now

Each peer (router, gateway or device) gets its own [Peer] block with its public key and an assigned tunnel IP. The AllowedIPs line tells WireGuard which networks are reachable via that peer - typically the tunnel IP plus the site's local subnet.

CGNAT: why WireGuard outperforms fixed-IP SIMs

Most cellular routers sit behind carrier-grade NAT (CGNAT). The router has no fixed public IP, and incoming connections are blocked. WireGuard works around this: the router initiates the connection outbound to the VPS hub, which has a fixed public IP. Once established, traffic flows in both directions.

This makes WireGuard on a VPS a cost-effective alternative to fixed-IP SIM cards. A fixed-IP SIM typically costs £5-15/month per device. A VPS hub costs the same flat fee regardless of how many routers connect to it.

Router brands that support WireGuard natively

• Teltonika (RUTX, RUT, TRB series) - WireGuard via WebUI since firmware 7.x
• Milesight (UR series) - WireGuard in WebUI
• InHand Networks - WireGuard supported
• Robustel - WireGuard supported
• Raspberry Pi / Linux - native kernel module
• pfSense / OPNsense - WireGuard plugin

See the dedicated VPS for Teltonika guide for router-specific configuration.

WireGuard vs Tailscale on a VPS

Tailscale is built on WireGuard but adds a managed coordination layer: automatic NAT traversal, MagicDNS and centralised ACLs. The trade-off is a dependency on Tailscale's coordination service. Raw WireGuard on your own VPS has no external dependencies and gives full control over the network architecture.

For IoT fleet deployments where devices have known network locations (routers at fixed sites), raw WireGuard with a self-managed hub is usually the better choice. For mobile or laptop users who move between networks, Tailscale's automatic NAT traversal is a genuine convenience. See Tailscale vs WireGuard for the full comparison.

Monitoring WireGuard tunnel health

Use sudo wg show on the VPS to see every peer's last handshake time and received/sent byte counts. A peer with no recent handshake and zero bytes received has lost its tunnel. The most common causes: the site router rebooted and the WireGuard service did not restart automatically, or the cellular connection was down long enough for the keepalive to expire.

sudo wg show wg0
# interface: wg0
#   public key: (your key)
#   listening port: 51820
#
# peer: (site 1 public key)
#   endpoint: 203.0.113.10:40291
#   allowed ips: 10.0.0.2/32, 192.168.1.0/24
#   latest handshake: 14 seconds ago
#   transfer: 1.23 MiB received, 456 KiB sent

Automate this check with Uptime Kuma's push/heartbeat monitor: a script on the VPS that confirms all expected peers are active, calling the push URL if they are. See VPS Uptime Monitoring for the full setup.

Key rotation for WireGuard fleets

WireGuard keys do not expire automatically. For security, rotate keys annually or whenever a device is decommissioned. Generate a new key pair on the device, update the corresponding peer entry on the VPS, and reload the configuration with sudo wg syncconf wg0 /etc/wireguard/wg0.conf. The wg syncconf command applies changes without dropping existing tunnels, making zero-downtime key rotation possible.

Split tunnelling: route only specific subnets through the VPS

By default, setting AllowedIPs = 0.0.0.0/0 routes all internet traffic through the VPS. For IoT devices this is rarely what you want - you only need the site's local subnet accessible. Use specific AllowedIPs for each peer to ensure only relevant traffic transits the VPS, keeping the hub's bandwidth usage low and isolating sites from each other.

Frequently asked questions

What UDP port does WireGuard use?

WireGuard defaults to UDP port 51820. You can use any port above 1024. Only one port needs to be open on the VPS firewall for all peers. Open UDP port 51820 with: sudo ufw allow 51820/udp.

Does WireGuard work through firewalls and NAT?

WireGuard works through NAT when the peer initiates the outbound connection. The VPS hub needs a reachable public IP with UDP port 51820 open. Devices behind CGNAT, double-NAT or strict firewall can connect out to the VPS and the tunnel will work.

Can I run WireGuard on the same VPS as Mosquitto and Node-RED?

Yes. WireGuard, Mosquitto, Node-RED, Grafana and InfluxDB all run comfortably on the same VPS for moderate device counts. The full stack guide at VPS for Docker IoT shows how to manage them with Docker Compose.

What is the difference between WireGuard hub-and-spoke and mesh?

Hub-and-spoke: all peers connect to one central VPS. Traffic between two remote sites travels via the hub. Simple to configure, single point of management. Mesh: every peer connects directly to every other peer. More complex, better for high-bandwidth peer-to-peer traffic. Hub-and-spoke on a VPS is the right architecture for most IoT deployments.

How many WireGuard peers can one VPS handle?

Hundreds to thousands of peers, limited by bandwidth and the number of routing table entries. For IoT use cases with modest per-site traffic, a 2 vCPU / 2GB RAM VPS handles hundreds of connected sites. The constraint is usually bandwidth, not CPU or memory.

Is WireGuard secure enough for industrial and commercial deployments?

Yes. WireGuard uses ChaCha20 for encryption, Poly1305 for authentication, and Curve25519 for key exchange. Its codebase is around 4,000 lines - small enough to audit. It has been reviewed by independent security researchers and is used in production by companies worldwide including Cloudflare and Mullvad.