Skip to content

Site to Site Routing

Jump to bottom
Stefano Bertelli edited this page Jun 26, 2026 · 1 revision

Site-to-Site Routing (Relay Devices)

In addition to acting as a single client, a device can be configured to route entire subnets through the VPN. This turns the device's host into a relay/gateway for a remote network, enabling site-to-site links — for example, connecting a branch office LAN to the VPN, or reaching a cloud VPC's private range through one peer.

This is configured via a device's Routed Subnets (the allowed_subnets field).

Admin-only. Declaring routed subnets is an administrator capability and is only available on the Device Administration page (/admin/devices). It is intentionally not exposed on the end-user device page, because routing a subnet on a user's behalf is a network-level decision (a user should not be able to claim arbitrary ranges such as 0.0.0.0/0 or another site's network).

How It Works

When a device has one or more routed subnets, WireGUI configures three things on the server automatically:

  1. Peer allowed-ips — each routed subnet is appended to the WireGuard peer's allowed-ips, so the server accepts and sends traffic for those ranges to/from this peer.
  2. Kernel routes — an ip route for each subnet is added via the WireGuard interface, so return traffic for the remote network is sent back through the tunnel.
  3. Firewall jumps — a forward-chain jump rule is added for each subnet, so traffic originating from the remote network is filtered by the owning user's firewall chain (the same per-user rules described in Firewall Rules).

Both IPv4 and IPv6 CIDRs are supported.

Configuring Routed Subnets

On the All Devices page, create or edit a device and fill in Routed Subnets (optional) with a comma-separated list of CIDRs, e.g.:

192.168.10.0/24, 10.50.0.0/16, fd00:abcd::/64

Each entry is validated as a proper CIDR and normalized (host bits are masked off, e.g. 192.168.10.5/24 becomes 192.168.10.0/24). Invalid input is rejected before any change is applied — a single bad entry can never be pushed to the firewall.

The remote site's gateway (the device's host) must, of course, actually forward traffic for those subnets and have a route back to the WireGuard interface.

Lifecycle & Reconciliation

Routes are kept in sync with the database (the source of truth):

  • Add — creating a device (or adding a subnet) installs the routes, allowed-ips, and firewall jumps.
  • Remove — deleting a device, or removing a subnet from a device, prunes the now-orphaned routes. Subnets still routed by another device are preserved.
  • Reconcile on startup — the reconciliation task makes the kernel routing table exactly match the database: it adds anything missing and removes orphans left behind (e.g. by changes made while the service was stopped). The WireGuard tunnel networks themselves are never touched.

Related

Clone this wiki locally