WireGuard connection fails, no packets sent to peer

J

janedenone

I deployed a WireGuard on a server (Ubuntu Linux) and created peer profiles (split tunnel) for several clients (Linux, macOS, iOS). Everything worked as expected.

Now I set up a FreeBSD client (14.3) and created a new WireGuard profile for it. The profile was tested successfully on a different client (running macOS) and transferred to the FreeBSD client. I installed the WireGuard tools package ( pkg install wireguard-tools) and loaded the WireGuard kernel module ( kldload if_wg). When executing wg-quick up wg0, the interface and routes are created (according to wg show wg0 and netstat -rn), but no packets are sent to the server according to tcpdump -i wlan0 udp port 51820 (the listening port on the server).

What could be the problem here?
 
It would probably help if you showed the client configuration.
 
Sure, sorry:

Code: 
[Interface]
PrivateKey = [redacted]
Address = 2a00:11c0:5f:30d6::9306/128, 10.100.0.6/32
DNS = 2620:fe::fe, 9.9.9.9

[Peer]
PublicKey = [redacted]
AllowedIPs = 2620:fe::fe/128, 9.9.9.9/32, 2a00:11c0:5f:30d6::9300/120, 10.100.0.1/24, [more IPs here, belonging to servers behind the VPN gateway]
Endpoint = wg.example.com:51820

As stated in the original post, this configuration works well on a different client.
 
Is the wlan0 interface actually up and associated? I mean is there any other network traffic going through it? A ifconfig output from the FreeBSD host would be useful, as does a netstat -rn output.

Does the FreeBSD host happen to have both a wired and wireless connected and active? This seems to confuse FreeBSD newbies a lot, if two or more interfaces are active and on the same network (subnet; 192.168.21.0/24 for example), routing becomes quite ambigious as there will be two (or more) so-called "directly connected" networks. If both interfaces use DHCP things become even more ambiguous.

Might move the thread to "Networking", my first impression was a configuration issue with the client (hence "Web and Network services") but that seems to be in order.
 
Yes, the interface wlan0 is up and running, and the ethernet interface is not connected. After activating the WireGuard interface, ifconfig prints this:

Code: 
em0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=4e524bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
    ether c8:5b:76:17:a4:85
    media: Ethernet autoselect
    status: no carrier
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
    options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    inet 127.0.0.1 netmask 0xff000000
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
    groups: lo
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=0
    ether 44:85:00:f4:9d:db
    inet 192.168.8.191 netmask 0xffffff00 broadcast 192.168.8.255
    inet6 fe80::4685:ff:fef4:9ddb%wlan0 prefixlen 64 scopeid 0x3
    inet6 [IPv6 prefix, redacted]:4685:ff:fef4:9ddb prefixlen 64 autoconf pltime 81198 vltime 81198
    groups: wlan
    ssid [SSID, redacted] channel 36 (5180 MHz 11a) bssid 12:59:03:4d:4c:3e
    regdomain FCC country US authmode WPA2/802.11i privacy ON
    deftxkey UNDEF AES-CCM 3:128-bit txpower 17 bmiss 10 mcastrate 6
    mgmtrate 6 scanvalid 60 wme roaming MANUAL
    parent interface: iwm0
    media: IEEE 802.11 Wireless Ethernet OFDM/6Mbps mode 11a
    status: associated
    nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
wg0: flags=10080c1<UP,RUNNING,NOARP,MULTICAST,LOWER_UP> metric 0 mtu 1420
    options=80000<LINKSTATE>
    inet 10.100.0.6 netmask 0xffffffff
    inet6 2a00:11c0:5f:30d6::9306 prefixlen 128
    groups: wg
    nd6 options=101<PERFORMNUD,NO_DAD>

The output of netstat -rn is the following:

Code: 
Routing tables

Internet:
Destination        Gateway            Flags         Netif Expire
default            192.168.8.1        UGS           wlan0
9.9.9.9            link#4             UHS             wg0
10.100.0.0/24      link#4             US              wg0
10.100.0.6         link#2             UH              lo0
78.47.178.18       link#4             UHS             wg0
127.0.0.1          link#2             UH              lo0
152.53.206.52      link#4             UHS             wg0
192.168.8.0/24     link#3             U             wlan0
192.168.8.191      link#2             UHS             lo0
217.154.195.8      link#4             UHS             wg0

Internet6:
Destination                       Gateway                       Flags         Netif Expire
::/96                             link#2                        URS             lo0
default                           fe80::9683:c4ff:feaa:be4e%wlan0 UG          wlan0
::1                               link#2                        UHS             lo0
::ffff:0.0.0.0/96                 link#2                        URS             lo0
2620:fe::fe                       link#4                        UHS             wg0
2a00:11c0:5f:30d6::9300/120       link#4                        US              wg0
2a00:11c0:5f:30d6::9306           link#2                        UHS             lo0
2a00:11c0:5f:30d6:74e2:89ff:fed1:83f5 link#4                    UHS             wg0
2a01:239:295:c900::1              link#4                        UHS             wg0
2a01:4f8:c17:d87e::1              link#4                        UHS             wg0
[IPv6 prefix, redacted]::/64            link#3                        U             wlan0
[IPv6 prefix, redacted]:4685:ff:fef4:9ddb link#2                      UHS             lo0
fe80::%lo0/10                     link#2                        URS             lo0
fe80::%lo0/64                     link#2                        U               lo0
fe80::1%lo0                       link#2                        UHS             lo0
fe80::%wlan0/64                   link#3                        U             wlan0
fe80::4685:ff:fef4:9ddb%lo0       link#2                        UHS             lo0
ff02::/16                         link#2                        URS             lo0

The AllowedIPs for the tunnel are routed correctly through the wg0 interface. On the surface, everything looks as it should (at least to me), but as I said, no packets are sent to the WireGuard server. pf is not running on the FreeBSD host. Could it be that there is something wrong with the if_wg kernel module? The result described above is the same with and without if_wg loaded.
 
I am using sniffnet to debug a lot of issues around FreeBSD and Linux wireguard configuration.

Code: 
$ pkg search sniffnet
sniffnet-1.4.1                 Comfortably monitor your Internet traffic

In this way you can see what traffic is going on wg0 ... and what is not.

NOTE: You will need to run the program as root as it needs access to the Berkley Packet Filter (BPF).

Code: 
# ls -al /dev/bpf
crw-------  1 root wheel 0x27 Nov  4 00:00 /dev/bpf
#
 
covacat said:
try ifconfig wg0 debug
see if messages (log) shows anything
Click to expand...
After I create the interface ( wg-quick up wg0), nothing happens, so switching ifconfig to debug mode does not produce any output. Pinging the VPN server's tunnel IP just returns nothing. I successfully tested sending a UDP packet manually to the VPN server, but with wireguard, the expected packets to port 51820 are just never sent. wg show wg0 (on the client) displays the correct configuration, but no active connection.
 
FWIW, I have a FreeBSD 15.0-BETA4 VM running wireguard tunnels to both Debian and 14.3-RELEASE peers, with split tunnelling.

I'm using the rc.d script that monwarez posted in the thread https://forums.freebsd.org/threads/how-to-enable-wireguard-service-in-freebsd14-2.96022/#post-682595

This essentially replaces wg-quick. The wgX.conf files are simpler, with various properties of the tunnels specified in rc.conf similar to this:

Code: 
# see https://forums.freebsd.org/threads/how-to-enable-wireguard-service-in-freebsd14-2.96022/#post-682595
# You can configure multiple tunnels to different peers like this:
#   the config file path includes the interface name, eg /usr/local/etc/wireguard/wg1.conf
#   both tunnels are brought up when you do 'service wireguard start'
#   THEREFORE you can't have both interfaces routes including the same destination
wireguard_wg0_ips="192.168.1.165/32"
wireguard_wg0_routes="192.168.1.0/24 1.2.3.0/24"
wireguard_wg1_ips="10.0.0.165/32"
wireguard_wg1_routes="10.0.0.0/24 4.5.6.0/24"
wireguard_enable="NO"
wireguard_interfaces="wg0 wg1"

I then leave the routing open in the .conf files, which don't have the wg-quick Address line, eg

Code: 
root@freebsd15:~ # cat wireguard/wg0.conf
[Interface]
PrivateKey = (redacted)

[Peer]
# this peer is a Debian vpn server
PublicKey = (redacted)
AllowedIPs = 0.0.0.0/0
Endpoint = (my public IPv4 address):51820
I haven't tried IPv6.
 
When manually creating the tunnel (without wg-quick), there are two parsing errors for the Address and DNS parameters:

Code: 
root@bsdbook:~ # ifconfig wg create name wg0
wg0
root@bsdbook:~ # ifconfig wg0 debug
root@bsdbook:~ # wg setconf wg0 /usr/local/etc/wireguard/wg0.conf 
Line unrecognized: `Address=2a00:11c0:5f:30d6::9306/128,10.100.0.6/32'
Configuration parsing error

This is consistent with the wg man page (dating back to 2015-08-13), which only allows PrivateKey, ListenPort and FwMark in the Interface section of the configuration file. But on other systems, I never saw these parsing errors.

When removing both the Address and DNS parameters, I still get a warning for the AllowedIPs list (which includes my tunnel IP subnet):

Code: 
 Warning: AllowedIP has nonzero host part: 10.100.0.1/24

Again, this warning does not appear on Linux or macOS clients. Simplifying the configuration (full tunnel, no IPv6) avoids the warning, but still does not lead to a single UDP packet being sent to the WireGuard server. I am truly baffled.
 
It's really confusing that wg and wg-quick have conf files with typically the same names and the same locations and the same syntax BUT different contents.

monwarez's rc.d script handles the routing outside wg, so you can get away with 0.0.0.0/0 in AllowedIP. I don't _think_ there's any security implication in that but that may be my lack of imagination.

An IP spec like 10.100.0.1/24 is a bit unusual - have you tried it with 10.100.0.0/24?
 
Problem solved! My list of AllowedIPs contained the public endpoint IP of the WireGuard server (and this did not cause a problem with the WireGuard app on macOS clients), so the handshake failed. Removing the server's IPs from the list did the trick, I can now establish a tunnel successfully.
 
You must log in or register to reply here.
Back
Top