After moving 50 engineers onto a WireGuard gateway, two laptops both complete handshakes but only one passes traffic; what in cryptokey routing explains it?
answer
- the handshake ignores allowed IPs
- one address, one owner
- a copied peer entry
- dropped after decryption, silently
- read the gateway's table first
basics
~20 sThe two laptops' gateway entries share one tunnel address. Handshakes check only keys, so both succeed, but each address maps to one peer. Replies go to that owner, and the other laptop's packets fail the inbound source check.
solid answer
~50 sIn WireGuard the handshake and cryptokey routing are separate checks. A handshake proves that each side holds the private key for a configured public key; allowed IPs are never consulted, so a successful handshake says nothing about whether packets will pass. On the gateway, the table maps each tunnel address to exactly one peer. If a copied entry gave laptop B the same `10.66.0.23/32` as laptop A, only one key owns that address. Replies to `10.66.0.23` are encrypted to the owner. Every packet the other laptop sends from `10.66.0.23` decrypts correctly and is then dropped, because its source maps to the other key. Nobody is told; WireGuard simply drops it. Read the gateway's peer table, look for overlapping prefixes and for laptops whose source address differs from their entry, and fix the table rather than the keys.
go deeper
Remember that in WireGuard a working handshake proves the keys, not the address entries, so traffic can still fail after it.
Trace a packet from a laptop through decryption and the source lookup, and say where a duplicated or missing allowed-IPs entry drops it.
Diagnose from the gateway's table first, separate outer-path faults from post-decryption drops, and treat a wide prefix on a laptop as a spoofing grant.
Make the allowed-IPs table a generated artefact of one address inventory with overlap checks, because a hand-edited table is a fleet-wide access-control list.
## Two checks that are easy to confuse A WireGuard tunnel has two independent gates, and "the handshake works" only proves the first: | Check | When it runs | What it consults | What failure looks like | |---|---|---|---| | Handshake | at session setup, then about every two minutes | the static public keys configured for each peer | no session at all, and initiations are retried | | Cryptokey routing, outbound | every packet sent into the interface | the destination address against the allowed IPs | the packet is dropped, or goes to the wrong peer | | Cryptokey routing, inbound | every packet after decryption | the inner source address against the allowed IPs | the packet is dropped after decrypting | The handshake never looks at allowed IPs. So two laptops whose keys are configured correctly will both show fresh handshakes even if their address entries are wrong. ## The duplicate-address fault, traced The company moved 50 engineers from IPsec remote access to one WireGuard gateway. Each laptop is meant to get its own `/32` in `10.66.0.0/24`. Laptop B's gateway entry was copied from laptop A's and kept A's address, `10.66.0.23/32`. Laptop B is also configured locally with `10.66.0.23`. A table that maps an address to a peer can give each address only one owner. The paper describes the mapping as one-to-one. Say laptop A ends up owning it. Then: 1. Laptop B sends a packet from `10.66.0.23` to an office server. The gateway authenticates and decrypts it under **B's** session. 2. The gateway looks up the inner source `10.66.0.23` and gets **A's** peer. 3. A's peer is not the sender, so the packet is **dropped**. WireGuard does not notify laptop B. 4. Any reply to `10.66.0.23` is encrypted to **laptop A**, which receives traffic for connections it never opened. Laptop B sees handshakes complete and nothing else. Laptop A works, apart from some stray replies. ## Other faults with the same symptom The same rule produces several other faults where the handshake succeeds and the traffic does not pass: - **The laptop's gateway row misses the office networks.** If the gateway row allows only `10.66.0.1/32`, a packet to `10.10.4.20` matches no peer and is dropped at the laptop. Replies sourced from `10.10.4.20` would also fail the laptop's own inbound check. - **The laptop forwards for something else.** A virtual machine or home network behind the laptop sends from an address outside the laptop's `/32`. The gateway drops those packets on the source check. - **A wide prefix on one laptop.** If one laptop's gateway row is `10.66.0.0/24` while the others have `/32`s, the most specific entry still wins, as in any routing table. So that laptop owns **every tunnel address no `/32` claims**. Replies to unassigned addresses go to it, and it may send packets from any of them. The last fault is a **security** problem, not just a routing one. Firewall rules on the gateway's tunnel interface trust inner source addresses, because cryptokey routing normally makes them authentic. A wide prefix grants one key the right to use addresses that were never assigned to it. ## Diagnosing it from the operator's side 1. **Read the gateway's table before touching keys.** List every peer's allowed IPs and look for duplicate or overlapping prefixes. 2. **Compare against the laptop.** The laptop's configured tunnel address must fall inside its own gateway row. 3. **Separate the layers.** If encrypted UDP from the laptop arrives at the gateway's outer interface and handshake responses go back, the outer path and the keys are fine. Inner packets that never appear on the tunnel interface were dropped after decryption, which points at cryptokey routing. 4. **Use the per-peer state that implementations expose**, such as last-handshake time and transfer counters. Bytes received from a peer while nothing reaches the network behind the gateway also points at the source check. ## Preventing it across 50 laptops - Generate the gateway's table from **one address inventory**: one row per laptop, one `/32` each, and no hand-copied entries. - Reject any change that introduces an overlapping prefix. - Keep wide prefixes for **site peers** that genuinely route a network, and never give one to a laptop. - Never reuse a key pair between devices. That is a different fault, but it comes from the same copying habit.
- Why is giving one laptop's WireGuard gateway entry 10.66.0.0/24 a security problem and not just a routing one?With the other laptops on `/32`s, that laptop's key owns every tunnel address no `/32` claims. The gateway accepts packets from it with any of those source addresses. Firewall rules on the tunnel interface treat inner sources as authentic, so its traffic can pass as addresses never assigned to it, and replies to unassigned addresses reach it. Give every laptop a `/32`.
- How do you tell a WireGuard cryptokey-routing drop apart from a path problem that blocks the tunnel?Look at the outer layer first. If encrypted UDP from the laptop reaches the gateway and handshake responses return, the path and the keys work, and that is consistent with a successful handshake. If the decrypted inner packets then never appear on the tunnel interface, they were dropped by the source check. A path problem shows up earlier: the outer UDP never arrives, or no handshake completes.
saying these in an interview costs you the question
- If the WireGuard handshake completes, the allowed IPs must be correct.
- WireGuard sends an error back to the peer when it drops a packet for a bad source.
- Two WireGuard peers can share a tunnel address; the one with the newest handshake gets it.
- A wider allowed-IPs prefix on a laptop's gateway entry is harmless extra reach.
- The fix for a handshaking WireGuard laptop that passes no traffic is to regenerate its keys.