Choose one-peer or shared pfSense WireGuard tunnels around route ownership

A routing protocol cannot replace cryptokey peer selection inside a shared multi-peer tunnel.

Source facts

Netgate explains that a WireGuard instance with several peers needs each peer’s routed networks defined for cryptokey routing. With one peer per interface, a broad Allowed IPs entry can identify that sole peer while an operating-system routing protocol manages which traffic reaches the interface. Endpoint definition also affects which side can initiate and supports roaming peers.

Source: Netgate — Design Considerations.

Applicability

This concerns the pfSense WireGuard topology decision.

DSE recommendation

DSE recommends identifying who owns remote-prefix changes before choosing a shared or per-peer layout. If dynamic routing is required, keep operating-system route selection distinct from cryptographic peer selection. Record endpoint initiation and roaming expectations for each connection. Prefer a diagram that shows tunnel interfaces, peers, Allowed IPs, and advertised routes together so later subnet additions do not create an unexplained black hole. Review a proposed new remote subnet as part of the topology choice. Ask who will update peer ownership and who will advertise the operating-system route, and show both entries in the design. Keep one-peer and shared-tunnel examples separate so their maintenance obligations remain visible.

Verification

In a lab, add an approved remote prefix and verify both the operating-system route and the peer selected for encryption. Test return traffic and a prefix that should not be reachable. Confirm the chosen layout handles the intended prefix-change workflow without broadening firewall permissions unintentionally.

Official reference

Netgate — Design Considerations. Reviewed October 20, 2026.