WireGuard AllowedIPs and routing — the most consequential line in the configuration

WireGuard’s AllowedIPs is the single most consequential line in a peer configuration. It serves two functions simultaneously: authorisation (which inner source IPs the peer is allowed to claim) and routing (which destinations the firewall will send to that peer). A peer with the wrong AllowedIPs either cannot send the traffic it should send, can send traffic it should not send, or both. The two functions are inseparable; the operator who configures one without understanding the other produces a broken or insecure deployment.

This lesson covers how AllowedIPs works at the protocol level, how it interacts with the kernel routing table, and the operational discipline for managing it on OPNsense at scale.

The dual role of AllowedIPs

Every WireGuard peer has an AllowedIPs list. The list is interpreted in two ways depending on the direction of traffic:

Inbound (peer → firewall). AllowedIPs is the set of inner source IPs that the peer is allowed to use. A packet arriving from the peer whose inner source IP is in the peer’s AllowedIPs is accepted; a packet with an inner source IP not in the list is dropped at the WireGuard layer before it reaches the firewall rules.

Outbound (firewall → peer). AllowedIPs is the set of inner destination IPs that the firewall will route through this peer. The routing table is constructed from the union of every peer’s AllowedIPs: for each AllowedIPs entry, a route is installed pointing to that peer through the WireGuard interface.

The same list, two interpretations. A peer with AllowedIPs = 10.1.0.0/24 is allowed to send traffic from any address in 10.1.0.0/24 (the authorisation function), and the firewall will route traffic destined for any address in 10.1.0.0/24 through that peer (the routing function). The two functions are consistent — the peer is authorised for what it can be reached as.

Site-to-site AllowedIPs

For a site-to-site peer, AllowedIPs is typically a single subnet — the remote site’s inside subnet. The firewall routes traffic for that subnet through the peer; the peer is authorised for that subnet.

Each peer’s AllowedIPs is unique. The routing table has three entries, one per peer, pointing to the corresponding tunnel interface. Traffic to 10.1.0.0/24 goes to Site A; traffic to 10.2.0.0/24 goes to Site B; traffic to 10.3.0.0/24 goes to Site C.

$ wg show wg0 allowed-ips

peer: clientpubkeySiteA==
allowed ips: 10.1.0.0/24
peer: clientpubkeySiteB==
allowed ips: 10.2.0.0/24
peer: clientpubkeySiteC==
allowed ips: 10.3.0.0/24

The trap with site-to-site AllowedIPs: the operator adds a peer and leaves AllowedIPs at the default 0.0.0.0/0. The peer is now authorised for every source IP — meaning the peer could (with manual effort) claim any inner source IP. Even if the peer’s actual traffic is restricted to its site subnet, the configuration is wrong: the peer has more authorisation than intended.

Remote-access AllowedIPs

For a remote-access peer, AllowedIPs is typically a /32 — the peer’s individual tunnel address. Each user gets a unique tunnel IP; the routing table has one entry per user pointing to that user’s tunnel IP through the WireGuard interface.

Every peer has a unique /32. The routing table has hundreds of /32 routes. Traffic to 10.99.0.5 goes to User 1; traffic to 10.99.0.6 goes to User 2; and so on. The remote-access pool (10.99.0.0/24) is the corporate subnet that users reach when they connect.

For full-tunnel remote access, every peer’s AllowedIPs is 0.0.0.0/0 — the peer is authorised for all source IPs, and the routing table has one default route pointing to that peer. This is the correct setting when the operator wants all client traffic routed through the firewall; it is a footgun when the operator intended only corporate traffic.

The overlap problem

Overlapping AllowedIPs are the most common production routing failure for WireGuard. Two peers with the same AllowedIPs create ambiguous routing; the kernel picks one route, the other peer’s traffic is silently dropped.

The diagnostic is the routing table:

$ netstat -rn | grep wg0

Destination        Gateway            Flags     Netif
10.1.0.0/24        10.99.0.2          UGS       wg0
10.2.0.0/24        10.99.1.2          UGS       wg0
10.1.0.0/24        10.99.2.2          UGS       wg0

The fix is to make every peer’s AllowedIPs unique. Site-to-site peers use unique subnets; remote-access peers use unique /32 addresses; full-tunnel peers are the only peer with 0.0.0.0/0.

Split-tunnel and full-tunnel with AllowedIPs

For remote access, the choice between split-tunnel and full-tunnel is encoded in AllowedIPs:

• Split-tunnel. The peer’s AllowedIPs lists the corporate subnets the user should reach. Traffic to those subnets routes through the WireGuard interface; all other traffic uses the client’s default route. Example: a peer with AllowedIPs = 10.0.0.0/16, 172.16.0.0/12 reaches only the corporate subnets via the tunnel.

• Full-tunnel. The peer’s AllowedIPs is 0.0.0.0/0 (IPv4) and ::/0 (IPv6). All traffic routes through the WireGuard interface; the client’s default route is overridden by the more-specific tunnel route.

The same peer configuration can support both modes depending on AllowedIPs. The operator chooses per peer: a senior admin might have full-tunnel for DLP coverage; a contractor might have split-tunnel to limit VPN bandwidth.

Diagnosing AllowedIPs failures

Three failure modes recur:

1. Peer can send but firewall cannot route. The peer’s AllowedIPs is 10.1.0.0/24 but the firewall’s routing table has no route for 10.1.0.0/24. The peer is authorised, but the firewall does not know to send return traffic through the tunnel. The fix: verify the route exists (netstat -rn | grep 10.1.0).

2. Peer cannot send but firewall routes. The firewall routes traffic for 10.1.0.0/24 to the peer, but the peer’s AllowedIPs is 10.2.0.0/24. The firewall sends a packet through the tunnel, but WireGuard at the peer end drops it because the inner source is not in AllowedIPs. The fix: align the firewall route (which is derived from AllowedIPs) with the peer’s authorisation.

3. Traffic reaches wrong peer. Two peers have overlapping AllowedIPs. Traffic to the overlapping subnet goes to one peer; the other peer’s traffic is dropped. The fix: assign unique AllowedIPs to each peer.

Summary

• AllowedIPs serves as both authorisation (which inner source IPs the peer can claim) and routing (which destinations route through the peer).
• Site-to-site peers should have a single subnet in AllowedIPs. Remote-access peers should have a unique /32.
• The default 0.0.0.0/0 is correct for full-tunnel remote access but a footgun for site-to-site peers.
• Overlapping AllowedIPs produce ambiguous routing; the kernel picks one route and silently drops the other’s traffic.
• The same AllowedIPs list that authorises the peer also routes the firewall’s traffic to the peer; the two functions are inseparable.