Bug 266712 - net/wireguard-kmod: Misleading error message when if_wg is not properly configured
Summary: net/wireguard-kmod: Misleading error message when if_wg is not properly confi...
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Bernhard Froehlich
URL:
Keywords: honeypot
Depends on:
Blocks:
 
Reported: 2022-09-30 02:07 UTC by Zhenlei Huang
Modified: 2024-02-07 14:23 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (decke)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zhenlei Huang freebsd_committer freebsd_triage 2022-09-30 02:07:40 UTC
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.
Comment 1 Jeff Kletsky 2023-05-01 04:47:42 UTC
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
Comment 2 Jeff Kletsky 2023-05-01 04:49:09 UTC
NB: Reported here as "the same" issue -- although now part of the core system in 13.2-RELEASE
Comment 3 Bessie Shea 2023-12-29 07:15:37 UTC
MARKED AS SPAM
Comment 4 Christina Allen 2024-01-10 10:16:32 UTC
MARKED AS SPAM