Hi all, I just found out that WireGuard apparently allows you to configure an interface that has peers with overlapping AllowedIPs ranges -- which obviously won't work with cryptokey routing -- but additionally is strange since I feel this should cause an error when configuring the interface. In my case, I accidentally used /32 when generating the IPv6 addresses of my clients and ended up with a config like: [Interface] Address = 10.13.37.1/32,fd00:dead:beef:cafe::1/64 ListenPort = 51820 PrivateKey = [key] # Peer A. [Peer] PublicKey = [pub] PreSharedKey = [psk] AllowedIPs = 10.13.40.1/32,fd00:dead:beef:1000::/32 # Peer B. [Peer] PublicKey = [pub] PreSharedKey = [psk] AllowedIPs = 10.13.41.1/32,fd00:dead:beef:1001::/32 This config is wrong (because both peers have overlapping addresses specified for AllowedIPs), but wireguard will happily accept it: % wg-quick up wg-foo [#] ip link add wg-yavin type wireguard [#] wg setconf wg-yavin /dev/fd/63 [#] ip address add 10.13.37.1/32 dev wg-yavin [#] ip address add fd00:dead:beef:cafe::1/64 dev wg-yavin [#] ip link set mtu 1420 up dev wg-yavin [#] ip route add fd42:dead::/32 dev wg-yavin [#] ip route add 10.13.41.1/32 dev wg-yavin [#] ip route add 10.13.40.1/32 dev wg-yavin This configuration results in only one of the peers actually being given the IPv6 range, but I feel like "wg setconf" should've rejected this configuration. % wg interface: wg-foo public key: [pub] private key: (hidden) listening port: 51820 peer: [peer A] preshared key: (hidden) allowed ips: 10.13.40.1/32 peer: [peer B] preshared key: (hidden) allowed ips: 10.13.41.1/32, fd42:dead::/32 -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH