OnLinux.ro

ROEN
, ,

WireGuard Site-to-Site VPN on Linux: Complete Routing Guide

👁 0 vizualizări

A site-to-site WireGuard VPN connects two private networks so that systems on each side can communicate through an encrypted routed link. Unlike a single remote-access client, both WireGuard peers act as gateways for networks behind them.

This guide builds a Linux-to-Linux site-to-site VPN and focuses on the details that most often cause problems: non-overlapping networks, AllowedIPs, forwarding, firewall rules, NAT and return routes.

Example topology

Site A
LAN: 192.168.10.0/24

PC-A 192.168.10.50
        |
WG-A / Router
LAN: 192.168.10.1
WG:  10.44.0.1
        |
        | WireGuard
        |
WG-B / Router
WG:  10.44.0.2
LAN: 192.168.20.1
        |
Server-B 192.168.20.20

Site B
LAN: 192.168.20.0/24

The LANs must not overlap. If both sites use the same subnet, normal routing cannot determine which side owns a destination without additional translation or redesign.

Install WireGuard on both gateways

apt update
apt install wireguard

On AlmaLinux or Rocky Linux, install the WireGuard packages appropriate for the exact distribution release.

Generate one key pair per site

Site A:

install -d -m 700 /etc/wireguard
cd /etc/wireguard
umask 077
wg genkey | tee site-a.key | wg pubkey > site-a.pub

Site B:

install -d -m 700 /etc/wireguard
cd /etc/wireguard
umask 077
wg genkey | tee site-b.key | wg pubkey > site-b.pub

Enable IP forwarding on both gateways

cat > /etc/sysctl.d/99-wireguard-routing.conf <<'EOF'
net.ipv4.ip_forward = 1
EOF

sysctl --system
sysctl net.ipv4.ip_forward

Site A configuration

[Interface]
Address = 10.44.0.1/30
ListenPort = 51820
PrivateKey = SITE_A_PRIVATE_KEY

[Peer]
PublicKey = SITE_B_PUBLIC_KEY
Endpoint = site-b.example.com:51820
AllowedIPs = 10.44.0.2/32, 192.168.20.0/24
PersistentKeepalive = 25

Site B configuration

[Interface]
Address = 10.44.0.2/30
ListenPort = 51820
PrivateKey = SITE_B_PRIVATE_KEY

[Peer]
PublicKey = SITE_A_PUBLIC_KEY
Endpoint = site-a.example.com:51820
AllowedIPs = 10.44.0.1/32, 192.168.10.0/24
PersistentKeepalive = 25

If one site has a stable public endpoint and the other is behind NAT, only the NATed side usually needs PersistentKeepalive. It is shown symmetrically here for clarity, not as a universal requirement.

Why AllowedIPs matters

WireGuard uses AllowedIPs not only as a peer policy but also for outbound peer selection. At Site A, the route to 192.168.20.0/24 belongs to the Site B peer. At Site B, the route to 192.168.10.0/24 belongs to Site A.

Start the tunnel

chmod 600 /etc/wireguard/wg0.conf
systemctl enable --now wg-quick@wg0

wg show
ip addr show wg0
ip route

Test tunnel IPs before testing LANs

From Site A:

ping 10.44.0.2

From Site B:

ping 10.44.0.1

Do not troubleshoot LAN routing until the two tunnel addresses can communicate and wg show reports a recent handshake.

Add LAN routes

Every LAN host must have a path to the remote network. The cleanest design is usually to configure static routes on each site’s primary router.

Site A router

Destination: 192.168.20.0/24
Next hop:    192.168.10.1

Site B router

Destination: 192.168.10.0/24
Next hop:    192.168.20.1

If the WireGuard gateway is already the default router for the LAN, those extra static routes may not be necessary.

Avoid NAT between the sites when possible

A routed site-to-site VPN normally preserves the original source address. A host on Site B should be able to see that traffic originated from 192.168.10.x. This improves logging, firewall policy and troubleshooting.

NAT may still be useful when existing routers cannot accept return routes, when subnets overlap, or when translation is an explicit design requirement. It should not be the default workaround for missing routes.

Firewall forwarding policy

The WireGuard gateways must allow forwarding between the LAN interface and wg0. Implement the rule in the firewall framework you already operate: nftables, UFW, firewalld or another policy engine.

Site A LAN -> wg0 -> Site B LAN
Site B LAN -> wg0 -> Site A LAN

Do not automatically grant full trust between sites. Allow only the networks and services that actually need to cross the tunnel.

Endpoint and NAT considerations

At least one configured endpoint must be reachable over UDP. If a site is behind NAT, forward the WireGuard port to the gateway when that site must accept unsolicited tunnel initiation. Dynamic DNS can be used when the public IP changes.

Test end-to-end connectivity

From a real host at Site A:

ping 192.168.20.20
traceroute 192.168.20.20

Repeat in the reverse direction. A VPN is not fully validated until hosts behind both gateways can communicate according to policy.

The return path is essential

If Site A can send a packet toward Site B but the reply goes to another default gateway, the connection fails even though the WireGuard tunnel is healthy. Site-to-site routing always requires a valid forward and return path.

Troubleshooting workflow

  1. Confirm UDP traffic reaches the WireGuard port.
  2. Confirm a recent WireGuard handshake.
  3. Ping the remote WireGuard address.
  4. Inspect routes to the remote LAN.
  5. Verify IP forwarding.
  6. Inspect firewall forwarding rules.
  7. Verify return routes on both LAN routers.
  8. Only then troubleshoot application-level filtering.
wg show
ip addr show wg0
ip route
ip rule
sysctl net.ipv4.ip_forward
ss -lunp
tcpdump -ni wg0
tcpdump -ni any udp port 51820

DNS between sites

Once IP routing is correct, internal DNS can make the VPN easier to use. Each site can forward queries for the other site’s internal zone or both sites can use a shared resolver. Always prove connectivity by IP before treating DNS as the primary problem.

Restrict inter-site access

  • allow administrators to reach only management systems;
  • allow backup traffic only to backup services;
  • keep user VLANs away from infrastructure networks;
  • allow monitoring without allowing unrestricted lateral movement.

Monitoring

wg show wg0 latest-handshakes
wg show wg0 transfer

Monitor the age of the latest handshake, data transfer counters, remote gateway reachability and at least one service behind the remote site. This distinguishes a live tunnel from a useful tunnel.

Security recommendations

  • use unique keys for each site;
  • protect private keys with restrictive permissions;
  • advertise only required prefixes;
  • filter forwarded traffic;
  • remove obsolete peers quickly;
  • keep both gateways patched;
  • back up configuration securely.

High availability

A single WireGuard gateway is a single point of failure. More demanding environments can add redundant routers, dynamic routing or controlled failover, but redundancy changes the routing design and should be tested under real failure conditions.

Checklist

  1. Use different LAN subnets at each site.
  2. Use a dedicated transit subnet for WireGuard.
  3. Generate unique keys for each gateway.
  4. Enable forwarding on both gateways.
  5. Put the remote LAN in each peer’s AllowedIPs.
  6. Open the required UDP port.
  7. Verify the handshake.
  8. Verify tunnel-IP connectivity.
  9. Add return routes to the LAN routers.
  10. Allow only required forwarded traffic.
  11. Avoid unnecessary NAT.
  12. Test from LAN endpoints in both directions.
  13. Monitor handshake age and service reachability.

Final thoughts

WireGuard makes the encrypted link straightforward, but site-to-site VPNs are fundamentally routing projects. Most failures after a successful handshake come from missing return routes, disabled forwarding, firewall policy or overlapping address space.

If the WireGuard handshake works but the LANs cannot communicate, debug routing before cryptography.