defguard icon indicating copy to clipboard operation
defguard copied to clipboard

[VPN] Per-peer AllowedIPs configuration missing in Defguard 1.5.0 (breaks site-to-site routing)

Open kaners80 opened this issue 1 month ago • 1 comments

Environment:

  • Defguard Core v1.5.0+97aca62 (docker, network_mode: host)
  • Gateways connected to Core via gRPC
  • Clients with WireGuard overlay 100.64.0.0/24

Problem: At the moment Defguard allows configuring Allowed IPs only at the Location/Network level (global scope). There is no way to configure per-peer AllowedIPs on the server side. As a result:

  • Server does not forward traffic from peer A (100.64.0.5) to subnet behind peer B (172.16.0.0/12 via 100.64.0.7).

  • wg show inside gateway container shows only 100.64.x.x/32 entries, without additional site subnets.

  • Manually running:

    ip route add 172.16.0.0/12 via 100.64.0.7 dev WG02
    wg set WG02 peer <pubkey-of-client1> allowed-ips 100.64.0.7/32,172.16.0.0/12
    

    fixes routing instantly — traffic flows correctly between peers and remote LAN.

  • But this configuration is lost on gateway/container restart, since Defguard regenerates config from DB without these AllowedIPs.

Why it matters:

  • For site-to-site or hub-and-spoke topologies it is essential to be able to define routes/networks behind each peer (classic WireGuard AllowedIPs semantics).
  • Without per-peer AllowedIPs, Defguard can only handle “roadwarrior”/client VPNs, but not scenarios where clients need to reach each other’s LANs via hub server.

Workarounds:

  • Manually wg set … allowed-ips … after each restart.
  • Custom host-side scripts (see attached snippet).
  • Not sustainable in production.

Expected behavior:

  • Admin UI / API should allow specifying per-device/per-peer AllowedIPs (e.g. 100.64.0.7/32, 172.16.0.0/12).
  • Core should propagate these into gateway config and persist them.
  • This would enable Defguard to support site-to-site routing natively.

Steps to reproduce:

  1. Deploy Defguard 1.5.0 with a location WG02.

  2. Create 2 clients:

    • Client1 (100.64.0.7), which also has local subnet 172.16.0.0/12.
    • Client2 (100.64.0.5).
  3. Try to ping 172.20.1.5 (inside 172.16/12 behind Client1) from Client2.

  4. Traffic not delivered until manual wg set on gateway.

Proposal:

  • Add per-peer AllowedIPs field in wireguard_network_device (DB schema) and in UI/API.
  • Allow mapping local subnets behind devices.
  • Sync them to gateways on config push.

kaners80 avatar Sep 29 '25 12:09 kaners80