База на знаења

A site-to-site VPN creates a persistent, secure tunnel between two servers (or entire networks), letting them communicate as if on the same private network — useful for connecting servers across different data centers or providers securely.

Use Cases

• Database replication between servers in different regions/providers over a private, encrypted link
• Connecting an application server to a database server hosted with a different provider
• Linking office/branch networks to cloud infrastructure

Using WireGuard for Site-to-Site (Recommended Approach)

Unlike the typical client-server VPN setup, a site-to-site configuration has both ends acting as peers routing entire subnets to each other, not just individual client IPs.

Prerequisites

• Two VPS servers, each with WireGuard installed (see How to Set Up a VPN Server with WireGuard)

Step 1 — Generate Keys on Both Servers

wg genkey | tee private.key | wg pubkey > public.key

Step 2 — Configure Server A

sudo nano /etc/wireguard/wg0.conf

[Interface]
PrivateKey = SERVER_A_PRIVATE_KEY
Address = 10.100.0.1/24
ListenPort = 51820

[Peer]
PublicKey = SERVER_B_PUBLIC_KEY
Endpoint = SERVER_B_PUBLIC_IP:51820
AllowedIPs = 10.100.0.2/32, 192.168.2.0/24
PersistentKeepalive = 25

AllowedIPs includes both Server B's tunnel IP and its local subnet (if you need to reach resources behind Server B, not just Server B itself).

Step 3 — Configure Server B (Mirror Configuration)

[Interface]
PrivateKey = SERVER_B_PRIVATE_KEY
Address = 10.100.0.2/24
ListenPort = 51820

[Peer]
PublicKey = SERVER_A_PUBLIC_KEY
Endpoint = SERVER_A_PUBLIC_IP:51820
AllowedIPs = 10.100.0.1/32, 192.168.1.0/24
PersistentKeepalive = 25

Step 4 — Start WireGuard on Both Servers

sudo systemctl enable --now wg-quick@wg0

Step 5 — Allow the WireGuard Port on Both Firewalls

sudo ufw allow 51820/udp

Step 6 — Test Connectivity

# From Server A
ping 10.100.0.2

Step 7 — Enable IP Forwarding if Routing Full Subnets

echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Required on both ends if either server needs to route traffic through to other machines on its local subnet, not just communicate directly with the other VPN endpoint itself.

Using the Tunnel

Applications on each server can now communicate using the tunnel IPs (10.100.0.1, 10.100.0.2) as if on the same private network — for example, configuring database replication to connect via the tunnel IP rather than a public IP, keeping that traffic encrypted and off the public internet.

Restricting Services to the Tunnel Only

sudo ufw allow from 10.100.0.0/24 to any port 3306

Bind sensitive services (like a database) to only accept connections via the VPN tunnel, never directly over the public internet.

Common Errors

Tunnel connects but subnet routing doesn't work — verify IP forwarding is enabled on the server that needs to route traffic through to its local subnet.

Handshake never completes — verify both firewalls allow the WireGuard UDP port, and public IPs/endpoints are correctly configured on both sides.

Best Practices

• Bind sensitive services to the tunnel IP only, never expose them directly on the public interface
• Use PersistentKeepalive to maintain the connection through NAT if either server is behind one
• Document which subnets are routed through the tunnel for future reference

Continue Reading

• How to Set Up a VPN Server with WireGuard
• How to Configure Static Routes on a Linux VPS
• How to Configure UFW (Uncomplicated Firewall) on Ubuntu & Debian

Browse more articles in Advanced Networking & VPN.