I'm new to wireguard. While trying to repeat https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261711 I have ever made a mistake and the wireguard interface did not come up properly but there was no good prompt about that. Environment: FreeBSD 13.1, wireguard-kmod-0.0.20220615, wireguard-tools-1.0.20210914_1 The content of wg1.conf ``` [Interface] PrivateKey = +Gu/JLpCpS5kG7tfHE1FYizocef+HlsebE/5djg+XUU= Address = 192.168.100.1/24 ListenPort = 51820 [Peer] PublicKey = ADTJlJuuTjUaAkPchD4Fk6nOiH1Kw3vqqzBiaKHScHE= AllowedIPs = 0.0.0.0/0 Endpoint = 192.168.117.155:51820 PersistentKeepalive = 15 ``` Be aware the peer's public key is same with the interface. I was trying to reuse the same pair of private key and public key for different wireguard box. ``` root@:~ # echo "+Gu/JLpCpS5kG7tfHE1FYizocef+HlsebE/5djg+XUU=" | wg pubkey ADTJlJuuTjUaAkPchD4Fk6nOiH1Kw3vqqzBiaKHScHE= ``` Steps to repeat: ``` root@:~ # wg-quick up ./wg1.conf [#] ifconfig wg create name wg1 [#] wg setconf wg1 /dev/stdin [#] ifconfig wg1 inet 192.168.100.1/24 alias [#] ifconfig wg1 mtu 1420 [#] ifconfig wg1 up [+] Backgrounding route monitor root@:~ # wg show wg1 interface: wg1 public key: ADTJlJuuTjUaAkPchD4Fk6nOiH1Kw3vqqzBiaKHScHE= private key: (hidden) listening port: 51820 root@:~ # ping -t 1 -c 1 192.168.100.2 PING 192.168.100.2 (192.168.100.2): 56 data bytes ping: sendto: Capabilities insufficient 92 bytes from 127.0.0.1: Destination Host Unreachable Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 ada5 0 0000 40 01 83af 192.168.100.1 192.168.100.2 --- 192.168.100.2 ping statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss ``` The error message "Capabilities insufficient" is misleading.
I agree, 'Capabilities insufficient' is not very helpful. It would have been even more puzzling if the issue had arisen when not testing WireGuard, but in some operational setting. When it hit me, I first had to guess if it was a firewall problem, a jail-capability limitation, something I messed up myself, or WireGuard. After all, I was seeing that the handshakes with the server were going through, so it seemed to be something else that I hadn't straightened out yet. It sounds that my first encounter with this message is similar to the reporter's. I was testing with a known-good "server" and confirmed that my configuration and initialization was functional. I failed to switch the config over to the FreeBSD server before testing that the client could reach the server's endpoint on the same IPv6 ULA /64 subnet. This can also be replicated if the requested address is routed through the interface, but not among AllowedIPs. Assigning a /64 out of an IPv6 ULA to the interface and using a different IP than configured for AllowedIPs will also trigger the message. Client and server both running 13.2-RELEASE with if_wg.ko loaded through /boot/loader.conf $ freebsd-version -ku 13.2-RELEASE 13.2-RELEASE FreeBSD 13.2-RELEASE releng/13.2-n254617-525ecfdad597 GENERIC amd64
NB: Reported here as "the same" issue -- although now part of the core system in 13.2-RELEASE
MARKED AS SPAM