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 - [email protected]
> On 25. Jan 2026, at 08:43, Ramiro Aceves <[email protected]> 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
