# Review both directions of a WireGuard AllowedIPs change

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

- Canonical URL: https://update.dsesecurity.com/updates/wireguard-allowedips-send-receive-review/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-15T00:43:27+00:00
- Modified: 2026-10-15T00:44:33+00:00
- Last reviewed by DSE: 2026-10-14
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

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

## Potentially affected

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.

## Article

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](https://www.wireguard.com/).

## 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](https://www.wireguard.com/). Reviewed October 14, 2026.

## Primary reference

- Name: WireGuard — Conceptual Overview and Cryptokey Routing
- Authority: www.wireguard.com
- URL: https://www.wireguard.com/
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Review both directions of a WireGuard AllowedIPs change,” DSE Security, https://update.dsesecurity.com/updates/wireguard-allowedips-send-receive-review/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.