Hi Norm, I'm moving this discussion over to the mailing list. Please be sure to keep wireguard@lists.zx2c4.com CC'd in your replies if you'd like a response. Our prior conversation follows below. Regards, Jason Forwarded conversation Subject: WireGuard cryptokey routing ------------------------ From: *Norman Shulman* Date: Tue, Jul 5, 2016 at 5:58 PM To: team@wireguard.io You state: " In the server configuration, when the network interface wants to send a packet to a peer (a client), it looks at that packet's destination IP and compares it to each peer's list of allowed IPs to see which peer to send it to. ... In other words, when sending packets, the list of allowed IPs behaves as a sort of routing table " But the allowed IPs can be non-routable addresses, so they are not necessarily unique. ---------- From: *Jason A. Donenfeld* Date: Tue, Jul 5, 2016 at 6:09 PM To: Norman Shulman Hi Norman, Can you expand what you mean a little bit by "not necessarily unique"? And why that matters? I'm not sure I understand the thrust of your point. Thanks, Jason ---------- From: *Norman Shulman* Date: Tue, Jul 5, 2016 at 6:14 PM To: "Jason A. Donenfeld" Hi Jason, Many clients use the non-routable 192.168.0.0/16 addresses. How can looking up such an address identify the client? Thanks. Norm ---------- From: *Jason A. Donenfeld* Date: Tue, Jul 5, 2016 at 6:19 PM To: Norman Shulman Hi Norm, I think you're misunderstanding how things work. I'll try to explain a bit more clear here: A linux system has several network interfaces, such as lo, eth0, wlan0, wg0. The ordinary kernel routing table determines which interface to use when sending outgoing packets. So, let's say the kernel routing table is setup to route 192.168.0.0/16 via WireGuard: # ip route add 192.168.0.0/16 dev wg0 or # ip addr add 192.168.0.5/16 dev wg0 Now userspace can send packets that will be handled by the wireguard driver: # ping 192.168.32.19 ... When that ping packet hits the wireguard driver, it has a dst IP of 192.168.32.19. What does wireguard do with it now? It looks in the cryptokey routing table to see if 192.168.32.19 belongs to any peers. If so, it uses that peer's public key to make a secure session and encrypt that ping packet. It then sends it off to the peer's configured external internet endpoint. Does this make more sense? Or is there still something you're wondering about? Regards, Jason ---------- From: *Norman Shulman* Date: Tue, Jul 5, 2016 at 6:23 PM To: "Jason A. Donenfeld" Hi Jason, I'm still wondering what wireguard does if more than one peer has the address 192.168.32.19. Thanks. Norm ---------- From: *Jason A. Donenfeld* Date: Tue, Jul 5, 2016 at 6:30 PM To: Norman Shulman Hi Norm, If you run these commands: wg set wg0 peer ABCD allowed-ips 192.168.32.19/32 wg set wg0 peer EFGH allowed-ips 192.168.32.19/32 After the first command ABCD has 192.168.32.19/32. After the second command, ABCD has no allowed ips, and EFGH has 192.168.32.19/32. However, if you run these commands: wg set wg0 peer ABCD allowed-ips 192.168.32.0/24 wg set wg0 peer EFGH allowed-ips 192.168.32.19/32 After running both commands, ABCD will have 192.168.32.0/24 and EFGH will have 192.168.32.19/32. However, when sending packets, the routing table lookups will always match on the most specific match, so ABCD will not be able to send or receive packets for 192.168.32.19/32. Make sense? Jason