NetBSD-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes
Ramiro,
as you do not mention any sysctl settings -- do you have these entries in /etc/sysctl.conf:
net.inet.ip.forwarding=1
net.inet.ip.redirect=0
Do you see redirects from netstat -s?
--
J. Hannken-Illjes - hannken%mailbox.org@localhost
> On 25. Jan 2026, at 08:43, Ramiro Aceves <ea1abz%gmail.com@localhost> wrote:
>
> Hello,
>
> I have been investigating this subject during days and the conclusion after testing the same WireGuard tunnel in FreeBSD and Linux (were it works fine) is that NetBSD works as is intended in the man page but fails in this particular scenario. I do not know whether perhaps is intentional, aiming security in the tunnels.
>
> I am experiencing an issue with WireGuard on NetBSD when using a provider that assigns a single routed IPv4 address (/32) over the tunnel. (AMateurPackeRadioNetwork AMPRNet https://wiki.ampr.org)
>
> My setup is the following:
>
> -NetBSD-10.1 on Raspberry Pi ZeroW
> (have also tested in NetBSD AMD64, even NetBSD-current using
> a live image.). Home router and ISP provider without CGNAT.
>
> -WireGuard tunnel from a https://connect.44net.cloud.
>
> -Provider assigns one public IPv4 address (44.27.132.76/32)
> over the tunnel
>
> -The provider routes this address through the WireGuard peer
>
> -No NAT is involved
>
> -The same provider and configuration work correctly on Linux
> and FreeBSD
>
> The configuration script:
>
> netbsd-raspaZeroW$ cat levantatunel.sh
> #!/bin/sh
> set -x
> ifconfig wg0 create mtu 1380
> ifconfig wg0 inet 44.27.132.76/32
> ifconfig wg0 inet6 fe80::644d:cf7a:c00:bae9/128
> wgconfig wg0 set private-key /etc/wg/wg0.priv
> wgconfig wg0 add peer A \
> asdfggfhffghkjhkhkhlkjhlkjhlkjhljhlkj \
> --allowed-ips=0.0.0.0/0,::/0 \
> --endpoint=44.27.227.1:44000
> ifconfig wg0 up
>
>
> netbsd-raspaZeroW# ifconfig wg0
> wg0: flags=0x8041<UP,RUNNING,MULTICAST> mtu 1380
> status: active
> inet6 fe80::ba27:ebff:feed:8547%wg0/64 flags 0 scopeid 0x3
> inet6 fe80::644d:cf7a:c00:bae9%wg0/128 flags 0 scopeid 0x3
> inet 44.27.132.76/32 flags 0
> netbsd-raspaZeroW#
>
>
> Observed behavior on NetBSD:
>
> Outgoing traffic works
>
> The tunnel is established correctly (I can see it in the
> provider "Dashboard" WEB page)
>
> Ping and SSH from the NetBSD host to the Internet work
>
> Incoming traffic from the Internet to 44.x.x.x does not work
>
> TCP connections (SSH, HTTP) time out
>
> ICMP do not work
>
> sshd is listening on all interfaces, and no firewall is active.
>
> Comparison with Linux and FreeBSD
>
> With the same provider and same IP address:
>
> On Linux, ip route installs a local route for the tunnel address:
>
> local 44.x.x.x dev wg0
>
> On FreeBSD, the address is bound to lo0 and treated as a local
> host route. It does some trick dividing internet adreeses in
> twoblocks
>
> 0.0.0.0/1 link#3 US wg0
> 128.0.0.0/1 link#3 US wg0
>
> In both Linux and FreeBSD operating systems, incoming connections work correctly (please see routing tables at the botton of this email:
>
> On NetBSD, the address appears to be treated mainly as a point-to-point/host route, and incoming packets do not seem to be handled as local traffic in the same way.
>
> Possible workaround will be ask for a routed subnet (e.g. /29) instead of a /32, and the interface is configured with that subnet, everything possibly will work correctly on NetBSD (AI guess).
>
> This suggests that the problem is specific to single-address (/32) routed setups.
>
> It seems that when a WireGuard interface is configured with a /32 address, NetBSD does not install a proper “local” route for that address, or does not treat it as fully local, which causes incoming traffic to be dropped or misrouted.
>
> Linux and FreeBSD appear to handle this case differently by creating explicit local/loopback routes.
>
> When a WireGuard interface is configured with a /32 address that is routed to the host, incoming packets destined to that address should be treated as local and delivered to local sockets, similarly to Linux and FreeBSD.
>
> Could this be considered a bug or missing feature in the NetBSD WireGuard/network stack?
>
> Is there a recommended way to configure routed /32 tunnel addresses so that incoming connections work correctly?
>
> Any guidance or suggestions would be appreciated.
>
> Should I fill a bug report/feature request?
>
> Thank you very much for your time.
>
> Best regards,
> Ramiro
>
> ***NetBSD routing tables:
>
> netbsd-raspaZeroW# route -n show
> Routing tables
>
> Internet:
> Destination Gateway Flags Refs Use Mtu Interface
> default 192.168.1.1 UGS - - - bwfm0
> 44.27.132.76 wg0 UHl - - - wg0
> 44.27.132.76/32 44.27.132.76 U - - - wg0
> 127/8 127.0.0.1 UGRS - - 33176 lo0
> 127.0.0.1 lo0 UHl - - 33176 lo0
> 192.168.1/24 link#2 UC - - - bwfm0
> 192.168.1.230 link#2 UHl - - - lo0
> 192.168.1.200 1c:69:7a:0a:83:9d UHL - - - bwfm0
> 192.168.1.203 d8:3a:dd:99:78:45 UHL - - - bwfm0
> 192.168.1.1 60:8d:26:32:34:23 UHL - - - bwfm0
>
> ***FreeBSD routing tables:
> root@freebsd-nuc8i7:/home/ramiro # netstat -rn
> Routing tables
>
> Internet:
> Destination Gateway Flags Netif Expire
> 0.0.0.0/1 link#3 US wg0
> default 192.168.1.1 UGS em0
> 44.27.132.76 link#2 UH lo0
> 44.27.227.1 192.168.1.1 UGHS em0
> 127.0.0.1 link#2 UH lo0
> 128.0.0.0/1 link#3 US wg0
> 192.168.1.0/24 link#1 U em0
> 192.168.1.200 link#2 UHS lo0
>
> ***Linux tables:
>
> root@debian-nuc8i7:~# ip -4 r show table all
> default dev wg0 table 51820 scope link
> default via 192.168.1.1 dev eno1 proto static metric 100
> 192.168.1.0/24 dev eno1 proto kernel scope link src 192.168.1.200 metric 100
> local 44.27.132.76 dev wg0 table local proto kernel scope host src 44.27.132.76
> local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
> local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
> broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
> local 192.168.1.200 dev eno1 table local proto kernel scope host src 192.168.1.200
> broadcast 192.168.1.255 dev eno1 table local proto kernel scope link src 192.168.1.200
Home |
Main Index |
Thread Index |
Old Index