Review both directions of a WireGuard AllowedIPs change

Treat AllowedIPs as both peer selection for outgoing traffic and source validation for incoming traffic.

Source facts

WireGuard’s conceptual overview explains that each peer’s public key is associated with allowed tunnel addresses. On transmission, the packet’s destination selects the peer. On reception, the decrypted packet’s source address must be permitted for the authenticated peer or it is dropped. WireGuard exposes a network interface whose addresses and operating-system routes are configured through the platform’s networking tools.

Source: WireGuard — Conceptual Overview and Cryptokey Routing.

Applicability

Use this guide when changing a peer’s AllowedIPs or diagnosing one-way tunnel traffic. Check the peer configuration and the operating-system route table as separate parts of the review.

DSE recommendation

DSE recommends documenting the intended destination networks and permitted incoming source networks for each peer before editing the list. Avoid widening prefixes merely to make a failed test pass. Compare the proposed entry on both ends with interface addressing, routes, forwarding, and application access policy. Keep private keys out of the change record; identify peers using approved public identifiers. Preserve the prior peer configuration so an unexpected route change can be reversed.

Verification

Test an authorized destination and inspect the source address seen after decryption. Include a controlled negative test for an unauthorized source in a lab where practical. Confirm the intended route and application access after reconnecting. Record both sending and receiving observations instead of using a recent handshake alone as completion evidence.

Official reference

WireGuard — Conceptual Overview and Cryptokey Routing. Reviewed October 14, 2026.