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
FreeBSD 13.1 reaches EOL. The kernel wg(4) WireGuard driver is available since 13.2 [1]. No need to fix it in ports. Commit 63613e3ba1e1 (wg: Use ENETUNREACH when transmitting to a non-existent peer) in CURRENT fixes this issue. The fix be MFCed to stable branches after about 2 weeks.
(In reply to Zhenlei Huang from comment #5) My bad. > The kernel wg(4) WireGuard driver is available since 13.2 [1]. 1. https://www.freebsd.org/releases/13.2R/announce/ > The fix be MFCed to stable branches after about 2 weeks. **Will** be .
markj@ fixed this as a side effect in https://cgit.freebsd.org/src/commit/?id=63613e3ba1e188e9fece43e1613bd697f04b345e Let's give it to him to close out.
Move it to the base system, too; the port is deprecated.
Submitter confirmed it was fixed by 63613e3ba1e188e9fece43e1613bd697f04b345e
(In reply to Renato Botelho from comment #10) This probably should have been left open to track MFCs.
oops. Sorry
The fix is MFCed into stable/14 as https://cgit.freebsd.org/src/commit/?h=stable/14&id=14148b5c5cd602f57a7536fe295632173939380e . @makj Can it also be MFCed into stable/13 ?
(In reply to Zhenlei Huang from comment #14) Certainly, done.
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=894bf6bd7d1dcdb2869cf065bea697e1dda07cb0 commit 894bf6bd7d1dcdb2869cf065bea697e1dda07cb0 Author: Mark Johnston <markj@FreeBSD.org> AuthorDate: 2024-04-01 17:20:55 +0000 Commit: Mark Johnston <markj@FreeBSD.org> CommitDate: 2024-04-16 16:08:54 +0000 wg: Use ENETUNREACH when transmitting to a non-existent peer The old errno value used is specifically for Capsicum and shouldn't be co-opted in this way. It has special handling in the generic syscall layer (see syscallret()). OpenBSD returns ENETUNREACH in this case; let's do the same thing. PR: 266712 Reviewed by: kevans, imp MFC after: 2 weeks Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D44582 (cherry picked from commit 63613e3ba1e188e9fece43e1613bd697f04b345e) sys/dev/wg/if_wg.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
(In reply to Mark Johnston from comment #15) > Certainly, done. Thanks !