Re: [solved] Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes
El 8/2/26 a las 15:23, Greg Troxel escribió: Ramiro Aceves writes: #!/bin/sh set -x ifconfig wg0 create mtu 1380 #ifconfig wg0 create mtu 1280 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 \ asdfasdfasdfasdfasdfasdf= \ --allowed-ips=0.0.0.0/0,::/0 \ --endpoint=44.27.227.1:44000 ifconfig wg0 up You should add a comment explaining why you chose 1380. Hi Greg, thanks for answering: I set MTU=1380 cause the instructions of the tunnel provider said that MTU setting should be 1380: netbsd-raspaZeroW$ cat wg-quick.conf [Interface] PrivateKey = gdsfgdfgdgdsfgdfgdfgdfgdfgdfg= Address = fe80::644d:cf7a:c00:bae9/128, 44.27.132.76/32 DNS = 1.1.1.1,1.0.0.1 MTU = 1380 [Peer] PublicKey = sdfgdfgdsfgdsfgdfgdfgdfg= Endpoint = 44.27.227.1:44000 PersistentKeepalive = 20 Any straightforward tunneling will take the inner packet (from wg0 in your case), process it, perhaps rounding up length depending on crypto algorithm, perhaps insert some kind of application-layer header, and then place it in another packet, with an IP header, and often UDP. Based on those sizes, there is a calculated max feasible MTU for the inner interface that results in not exceeding the MTU of the outer interface. Beyond that, there is the question of the minimum MTU along the path. If a packet exceeds MTU, it can either be fragmented (v4 only) or dropped. Increasingly the world has moved to a don't-fragemnt approach which causes an ICMP reply that the packet is too big, causing the source send smaller packets. With firewalls, tunneling, etc. this can go badly if those packets are not both allowed and translated properly. Thanks so much for explanation. I understand it better now. netbsd-raspaZeroW# cat cambia_rutas.sh #!/bin/sh set -x route add 44.27.227.1 192.168.1.1 route delete default route add default 44.27.132.76 This is more straightforward than 0/1 and 128/1. Yes As man page says, only 0 or 1 values seem to be valid. tcp.mss_ifmtu If set to 1, TCP calculates the outgoing maximum segment size based on the MTU of the appropriate interface. If set to 0, it is calculated based on the greater of the MTU of the interface, and the largest (non-loopback) interface MTU on the system. You've shown the code, and it's quite clear it is 0 or not zero, and the man page documents 0 and 1. Thus it is a configuration error to set any other value; don't do that! Yes, I have set mss_ifmut=1 from now.The story is that the AI suggested to me put 1380-40=1360 and did so. It inmediately worked fine and I went to visit the sysctl man page and saw that 0 and 1 were the possible values. Then I looked at the code to see what was actually written. I can run now successful ssh sessions from outside. This is a huge clue, almost proof, that your setup has Path MTU discovery problems. I would suggest reading: https://en.wikipedia.org/wiki/Path_MTU_Discovery https://datatracker.ietf.org/doc/html/rfc1191 maybe https://datatracker.ietf.org/doc/html/rfc4821 Thanks so much for those links. I will read them. I looked at your FreeBSD tcpdump but the wg0/real don't cover the same time period, so it really isn't helpful. I was trying to suggest that you run them both at once, -w to a file, -s1500 with *no filters*, and then after the experiment analyze them with -r and then using filters to omit things that you have decided don't matter. Probably you should redo tcpdump and see if you can see the ICMP Fragmentation Needed replies. From your earlier tcpdump 07:13:37.531243 IP 90.167.219.193.44127 > 44.27.132.76.22: Flags [S], seq 145184924, win 65535, options [mss 1410,sackOK,TS val 851808448 ecr 0,nop,wscale 10], length 0 07:13:37.531257 IP 44.27.132.76.22 > 90.167.219.193.44127: Flags [S.], seq 1482509222, ack 145184925, win 32768, options [mss 1460,nop,wscale 3,sackOK,TS val 1 ecr 851808448], length 0 07:13:37.701029 IP 90.167.219.193.44127 > 44.27.132.76.22: Flags [.], ack 1, win 86, options [nop,nop,TS val 851808627 ecr 1], length 0 connection opened. Trace is clearly at the 44 side because the timestamps from SYN to SYNACK are only 14 us apart, whereas the SYNACK to ACK is 169 ms ish. Oh, I see. That is the difference between looking to the tcpdump captures by trained brain and eyes and me that I do not know anything about network protocols ;-) Anyway, I think from all of this nightmare I have learnt many new things for me. 07:13:37.708854 IP 90.167.219.193.44127 > 44.27.132.76.22: Flags [P.], seq 1:23, ack 1, win 86, options [nop,nop,TS val 851808631 ecr 1], length 22 07:13:37.745163 IP 44.27.132.76.22 > 90.167.219.193.44127: Flags [P.], seq 1:64, ack 23, win 4194, options [nop,nop,TS val 1 ecr 851808631], length 63 07:13:37.920768 IP 90.167.219.193.44127 >
Re: [solved] Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes
Ramiro Aceves writes:
> #!/bin/sh
> set -x
> ifconfig wg0 create mtu 1380
> #ifconfig wg0 create mtu 1280
> 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 \
> asdfasdfasdfasdfasdfasdf= \
> --allowed-ips=0.0.0.0/0,::/0 \
> --endpoint=44.27.227.1:44000
> ifconfig wg0 up
You should add a comment explaining why you chose 1380.
Any straightforward tunneling will take the inner packet (from wg0 in
your case), process it, perhaps rounding up length depending on crypto
algorithm, perhaps insert some kind of application-layer header, and
then place it in another packet, with an IP header, and often UDP.
Based on those sizes, there is a calculated max feasible MTU for the
inner interface that results in not exceeding the MTU of the outer
interface. Beyond that, there is the question of the minimum MTU along
the path.
If a packet exceeds MTU, it can either be fragmented (v4 only) or
dropped. Increasingly the world has moved to a don't-fragemnt approach
which causes an ICMP reply that the packet is too big, causing the
source send smaller packets. With firewalls, tunneling, etc. this can
go badly if those packets are not both allowed and translated properly.
> netbsd-raspaZeroW# cat cambia_rutas.sh
> #!/bin/sh
> set -x
> route add 44.27.227.1 192.168.1.1
> route delete default
> route add default 44.27.132.76
This is more straightforward than 0/1 and 128/1.
> As man page says, only 0 or 1 values seem to be valid.
>
> tcp.mss_ifmtu
> If set to 1, TCP calculates the outgoing maximum segment
> size based on the MTU of the appropriate interface. If
> set to 0, it is calculated based on the greater of the
> MTU of the interface, and the largest (non-loopback)
> interface MTU on the system.
You've shown the code, and it's quite clear it is 0 or not zero, and the
man page documents 0 and 1. Thus it is a configuration error to set any
other value; don't do that!
> I can run now successful ssh sessions from outside.
This is a huge clue, almost proof, that your setup has Path MTU
discovery problems.
I would suggest reading:
https://en.wikipedia.org/wiki/Path_MTU_Discovery
https://datatracker.ietf.org/doc/html/rfc1191
maybe https://datatracker.ietf.org/doc/html/rfc4821
I looked at your FreeBSD tcpdump but the wg0/real don't cover the same
time period, so it really isn't helpful. I was trying to suggest that
you run them both at once, -w to a file, -s1500 with *no filters*, and
then after the experiment analyze them with -r and then using filters to
omit things that you have decided don't matter.
Probably you should redo tcpdump and see if you can see the ICMP
Fragmentation Needed replies.
>From your earlier tcpdump
> 07:13:37.531243 IP 90.167.219.193.44127 > 44.27.132.76.22: Flags [S], seq
> 145184924, win 65535, options [mss 1410,sackOK,TS val 851808448 ecr
> 0,nop,wscale 10], length 0
> 07:13:37.531257 IP 44.27.132.76.22 > 90.167.219.193.44127: Flags [S.], seq
> 1482509222, ack 145184925, win 32768, options [mss 1460,nop,wscale
> 3,sackOK,TS val 1 ecr 851808448], length 0
> 07:13:37.701029 IP 90.167.219.193.44127 > 44.27.132.76.22: Flags [.], ack 1,
> win 86, options [nop,nop,TS val 851808627 ecr 1], length 0
connection opened. Trace is clearly at the 44 side because the
timestamps from SYN to SYNACK are only 14 us apart, whereas the SYNACK
to ACK is 169 ms ish.
> 07:13:37.708854 IP 90.167.219.193.44127 > 44.27.132.76.22: Flags [P.], seq
> 1:23, ack 1, win 86, options [nop,nop,TS val 851808631 ecr 1], length 22
> 07:13:37.745163 IP 44.27.132.76.22 > 90.167.219.193.44127: Flags [P.], seq
> 1:64, ack 23, win 4194, options [nop,nop,TS val 1 ecr 851808631], length 63
> 07:13:37.920768 IP 90.167.219.193.44127 > 44.27.132.76.22: Flags [.], ack 64,
> win 86, options [nop,nop,TS val 851808841 ecr 1], length 0
> 07:13:37.920794 IP 44.27.132.76.22 > 90.167.219.193.44127: Flags [P.], seq
> 64:1184, ack 23, win 4197, options [nop,nop,TS val 2 ecr 851808841], length
> 1120
This seems ok
> 07:13:37.929014 IP 90.167.219.193.44127 > 44.27.132.76.22: Flags [P.], seq
> 1421:1591, ack 64, win 86, options [nop,nop,TS val 851808847 ecr 1], length
> 170
This is a packet covering 1421:1591, but the previous seq was 1:23. so
24:1420 is missing. Surely that was sent from 90. and dropped. So you
need to tcpdump (again, -wFILE and -s1500, no filters, as always) on the
remote machine, and on the wg client's real interface.
> 07:13:37.929029 IP 44.27.132.76.22 > 90.167.219.193.44127: Flags [.], ack 23,
> win 4197, options [nop,nop,TS val 2 ecr 851808841,nop,nop,sack 1
> {1421:1591}], length 0
you are acking 23 again with a sack block for the out-of-order data.
> 07:13:38.139063 IP 90.167.219.193.44127 > 44.27.132.76.22: Flags [.], ack
> 1184, win 89, options [nop,nop,TS val 8
[solved] Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes
Hello,
After many days of blind experimenting, I have got it working (I have to test
it a bit more cause now I am too excited ;-) )
Tunnel configuration:
netbsd-raspaZeroW# cat levantatunel.sh
#!/bin/sh
set -x
ifconfig wg0 create mtu 1380
#ifconfig wg0 create mtu 1280
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 \
asdfasdfasdfasdfasdfasdf= \
--allowed-ips=0.0.0.0/0,::/0 \
--endpoint=44.27.227.1:44000
ifconfig wg0 up
Route modification:
netbsd-raspaZeroW# cat cambia_rutas.sh
#!/bin/sh
set -x
route add 44.27.227.1 192.168.1.1
route delete default
route add default 44.27.132.76
The routes:
netbsd-raspaZeroW# route -n show
Routing tables
Internet:
DestinationGatewayFlagsRefs UseMtu Interface
default44.27.132.76 UGS -- - wg0
44.27.132.76 wg0UHl -- - wg0
44.27.132.76/3244.27.132.76 U -- - wg0
44.27.227.1192.168.1.1UGHS-- - bwfm0
127/8 127.0.0.1 UGRS-- 33176 lo0
127.0.0.1 lo0UHl -- 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.160:8d:26:32:34:23 UHL -- - bwfm0
netbsd-raspaZeroW# ifconfig wg0
wg0: flags=0x8041 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# cat /etc/resolv.conf
# Generated by resolvconf
domain remigio
nameserver 192.168.1.1
nameserver 8.8.8.8
nameserver 1.1.1.1
nameserver 1.0.0.1
netbsd-raspaZeroW#
But the most important thing:
by default:
sysctl variable net.inet.tcp.mss_ifmtu=0
setting it to
sysctl -w net.inet.tcp.mss_ifmtu=1340 (that was the first guess)
or
sysctl -w net.inet.tcp.mss_ifmtu=1
Both appear to work, but have to test more to see if there is a difference
As man page says, only 0 or 1 values seem to be valid.
tcp.mss_ifmtu
If set to 1, TCP calculates the outgoing maximum segment
size based on the MTU of the appropriate interface. If
set to 0, it is calculated based on the greater of the
MTU of the interface, and the largest (non-loopback)
interface MTU on the system.
Looking at the code in
/usr/src/sys/netinet/tcp_subr.c :
if (tcp_mss_ifmtu == 0)
switch (af) {
#ifdef INET6
case AF_INET6: /* FALLTHROUGH */
#endif
case AF_INET:
mss = uimax(in_maxmtu, mss);
break;
}
seems that 1 or 1340 should be the same but the experts will say.
I can run now successful ssh sessions from outside.
netbsd-nuc$ ssh 44.27.132.76
([email protected]) Password for ramiro@netbsd-raspaZeroW:
Last login: Fri Feb 6 20:14:07 2026 from 85.48.187.62
NetBSD 10.1 (RPI) #0: Mon Dec 16 13:08:11 UTC 2024
Welcome to NetBSD!
netbsd-raspaZeroW$
I have setup a lighttpd server to test and also serves the WEB page.
Also think that sending a ping from the Rpi to the 44.27.132.76 IP is mandatory to mantain the tunnel alive. If not, when time passes, It becomes a bit lazy until it responds to the external requests.
Have to experiment that subject.
Regards.
Ramiro.
Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes
Hi, This is the promised FreeBSD tcpdump session: First a ping from Termux on the phone, and then an ssh session from the phone after password input (under Termux): I see some 1.1.1.1, perhaps DNS... root@freebsd-nuc8i7:/home/ramiro # tcpdump -n -i wg0 host 44.27.132.76 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on wg0, link-type NULL (BSD loopback), snapshot length 262144 bytes 11:59:15.870087 IP 90.167.219.169 > 44.27.132.76: ICMP echo request, id 3408, seq 1, length 64 11:59:15.870101 IP 44.27.132.76 > 90.167.219.169: ICMP echo reply, id 3408, seq 1, length 64 11:59:18.982409 IP 90.167.219.169.3411 > 44.27.132.76.22: Flags [S], seq 1145659086, win 65535, options [mss 1410,sackOK,TS val 856158644 ecr 0,nop,wscale 10], length 0 11:59:18.982435 IP 44.27.132.76.22 > 90.167.219.169.3411: Flags [S.], seq 604954042, ack 1145659087, win 65535, options [mss 1340,nop,wscale 8,sackOK,TS val 2301518137 ecr 856158644], length 0 11:59:19.152136 IP 90.167.219.169.3411 > 44.27.132.76.22: Flags [.], ack 1, win 86, options [nop,nop,TS val 856158814 ecr 2301518137], length 0 11:59:19.160469 IP 90.167.219.169.3411 > 44.27.132.76.22: Flags [P.], seq 1:23, ack 1, win 86, options [nop,nop,TS val 856158818 ecr 2301518137], length 22: SSH: SSH-2.0-OpenSSH_10.2 11:59:19.160910 IP 44.27.132.76.12803 > 1.1.1.1.53: 1358+ PTR? 169.219.167.90.in-addr.arpa. (45) 11:59:19.202603 IP 44.27.132.76.22 > 90.167.219.169.3411: Flags [.], ack 23, win 257, options [nop,nop,TS val 2301518357 ecr 856158818], length 0 11:59:19.225134 IP 1.1.1.1.53 > 44.27.132.76.12803: 1358 1/0/0 PTR 169.pool90-167-219.static.orange.es. (94) 11:59:19.225410 IP 44.27.132.76.43824 > 1.1.1.1.53: 61806+ A? 169.pool90-167-219.static.orange.es. (53) 11:59:19.352579 IP 1.1.1.1.53 > 44.27.132.76.43824: 61806 1/0/0 A 90.167.219.169 (69) 11:59:19.352733 IP 44.27.132.76.22 > 90.167.219.169.3411: Flags [P.], seq 1:40, ack 23, win 257, options [nop,nop,TS val 2301518507 ecr 856158818], length 39: SSH: SSH-2.0-OpenSSH_10.0 FreeBSD-20250801 11:59:19.522262 IP 90.167.219.169.3411 > 44.27.132.76.22: Flags [.], ack 40, win 86, options [nop,nop,TS val 856159184 ecr 2301518507], length 0 11:59:19.522295 IP 44.27.132.76.22 > 90.167.219.169.3411: Flags [P.], seq 40:1080, ack 23, win 257, options [nop,nop,TS val 2301518677 ecr 856159184], length 1040 11:59:19.540481 IP 90.167.219.169.3411 > 44.27.132.76.22: Flags [.], seq 23:1351, ack 40, win 86, options [nop,nop,TS val 856159187 ecr 2301518507], length 1328 11:59:19.541218 IP 90.167.219.169.3411 > 44.27.132.76.22: Flags [P.], seq 1351:1591, ack 40, win 86, options [nop,nop,TS val 856159189 ecr 2301518507], length 240 11:59:19.541231 IP 44.27.132.76.22 > 90.167.219.169.3411: Flags [.], ack 1591, win 256, options [nop,nop,TS val 2301518696 ecr 856159187], length 0 11:59:19.740407 IP 90.167.219.169.3411 > 44.27.132.76.22: Flags [P.], seq 1591:2823, ack 1080, win 89, options [nop,nop,TS val 856159382 ecr 2301518677], length 1232 11:59:19.748305 IP 44.27.132.76.22 > 90.167.219.169.3411: Flags [.], seq 1080:2408, ack 2823, win 257, options [nop,nop,TS val 2301518903 ecr 856159382], length 1328 11:59:19.748309 IP 44.27.132.76.22 > 90.167.219.169.3411: Flags [P.], seq 2408:2660, ack 2823, win 257, options [nop,nop,TS val 2301518903 ecr 856159382], length 252 11:59:19.932141 IP 90.167.219.169.3411 > 44.27.132.76.22: Flags [.], ack 2660, win 94, options [nop,nop,TS val 856159589 ecr 2301518903], length 0 11:59:19.990239 IP 90.167.219.169.3411 > 44.27.132.76.22: Flags [P.], seq 2823:2907, ack 2660, win 94, options [nop,nop,TS val 856159642 ecr 2301518903], length 84 11:59:20.065367 IP 44.27.132.76.22 > 90.167.219.169.3411: Flags [.], ack 2907, win 257, options [nop,nop,TS val 2301519220 ecr 856159642], length 0 11:59:20.232286 IP 90.167.219.169.3411 > 44.27.132.76.22: Flags [P.], seq 2907:2951, ack 2660, win 94, options [nop,nop,TS val 856159897 ecr 2301519220], length 44 11:59:20.232410 IP 44.27.132.76.22 > 90.167.219.169.3411: Flags [P.], seq 2660:2704, ack 2951, win 257, options [nop,nop,TS val 2301519387 ecr 856159897], length 44 11:59:20.410154 IP 90.167.219.169.3411 > 44.27.132.76.22: Flags [P.], seq 2951:3019, ack 2704, win 94, options [nop,nop,TS val 856160064 ecr 2301519387], length 68 11:59:20.410585 IP 44.27.132.76.58571 > 1.1.1.1.53: 45437+ PTR? 169.219.167.90.in-addr.arpa. (45) 11:59:20.490312 IP 44.27.132.76.22 > 90.167.219.169.3411: Flags [.], ack 3019, win 257, options [nop,nop,TS val 2301519645 ecr 856160064], length 0 11:59:20.507248 IP 1.1.1.1.53 > 44.27.132.76.58571: 45437 1/0/0 PTR 169.pool90-167-219.static.orange.es. (94) 11:59:20.507459 IP 44.27.132.76.15545 > 1.1.1.1.53: 10122+ A? 169.pool90-167-219.static.orange.es. (53) 11:59:20.631596 IP 1.1.1.1.53 > 44.27.132.76.15545: 10122 1/0/0 A 90.167.219.169 (69) 11:59:20.634352 IP 44.27.132.76.22 > 90.167.219.169.3411: Flags [P.], seq 2704:2984, ack 3019, win 257, options [nop,nop,TS
Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes
El 30/1/26 a las 23:47, Ramiro Aceves escribió:
Hello Greg
With the following routes I can ping fine from the mobile phone, please see
below. But when I try to start a SSH session, it never success.
netbsd-raspaZeroW# route -n show
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 44.27.132.76 UGS - - - wg0
44.27.132.76 wg0 UHl - - - wg0
44.27.132.76/32 44.27.132.76 U - - - wg0
44.27.227.1 192.168.1.1 UGHS - - - bwfm0
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.203 d8:3a:dd:99:78:45 UHL - - - bwfm0
192.168.1.1 60:8d:26:32:34:23 UHL - - - bwfm0
192.168.1.51 20:28:bc:eb:8d:ae UHL - - - bwfm0
23:19:10.181755 IP 90.167.219.193 > 44.27.132.76: ICMP echo request, id 25199,
seq 1, length 64
23:19:10.181941 IP 44.27.132.76 > 90.167.219.193: ICMP echo reply, id 25199,
seq 1, length 64
23:19:13.699283 IP 90.167.219.193.25196 > 44.27.132.76.22: Flags [S], seq
3379571502, win 65535, options [mss 1410,sackOK,TS val 845496656 ecr 0,nop,wscale
10], length 0
23:19:13.699422 IP 44.27.132.76.22 > 90.167.219.193.25196: Flags [S.], seq
1838093467, ack 3379571503, win 32768, options [mss 1460,nop,wscale 3,sackOK,TS
val 1 ecr 845496656], length 0
23:19:13.869650 IP 90.167.219.193.25196 > 44.27.132.76.22: Flags [.], ack 1,
win 86, options [nop,nop,TS val 845496833 ecr 1], length 0
23:19:13.870218 IP 90.167.219.193.25196 > 44.27.132.76.22: Flags [P.], seq
1:23, ack 1, win 86, options [nop,nop,TS val 845496837 ecr 1], length 22
23:19:14.062777 IP 44.27.132.76.22 > 90.167.219.193.25196: Flags [.], ack 23,
win 4194, options [nop,nop,TS val 2 ecr 845496837], length 0
23:19:14.142755 IP 44.27.132.76.22 > 90.167.219.193.25196: Flags [P.], seq
1:64, ack 23, win 4194, options [nop,nop,TS val 2 ecr 845496837], length 63
23:19:14.309616 IP 90.167.219.193.25196 > 44.27.132.76.22: Flags [.], ack 64,
win 86, options [nop,nop,TS val 845497277 ecr 2], length 0
23:19:14.309778 IP 44.27.132.76.22 > 90.167.219.193.25196: Flags [P.], seq
64:1184, ack 23, win 4197, options [nop,nop,TS val 2 ecr 845497277], length 1120
23:19:14.317253 IP 90.167.219.193.25196 > 44.27.132.76.22: Flags [P.], seq
1421:1591, ack 64, win 86, options [nop,nop,TS val 845497281 ecr 2], length 170
23:19:14.317375 IP 44.27.132.76.22 > 90.167.219.193.25196: Flags [.], ack 23,
win 4197, options [nop,nop,TS val 2 ecr 845497277,nop,nop,sack 1 {1421:1591}],
length 0
23:19:14.522748 IP 90.167.219.193.25196 > 44.27.132.76.22: Flags [.], ack 1184,
win 89, options [nop,nop,TS val 845497496 ecr 2], length 0
^C
32 packets captured
32 packets received by filter
0 packets dropped by kernel
netbsd-raspaZeroW#
ssh server on the RPi negociates but it never ends. AI suggests that UDP
packets inside the tunnel are corrupted because (perhaps) a flaky bwfm driver,
but how knows, many times it says wrong things...
(Also the interface needs to be "resurrected" as before, but it is another
story)
We are far better than before but I does not work yet.
Regards.
Ramiro.
Hi,
I have repeated the test with the new tables in my AMD64 Intel Nuc connected
via ethernet and the result is the same. Sent three test pings followed by
starting an SSH connection that never success:
netbsd-nuc# tcpdump -n -i wg0 host 44.27.132.76
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wg0, link-type NULL (BSD loopback), capture size 262144 bytes
07:13:30.410683 IP 90.167.219.193 > 44.27.132.76: ICMP echo request, id 44133,
seq 1, length 64
07:13:30.410699 IP 44.27.132.76 > 90.167.219.193: ICMP echo reply, id 44133,
seq 1, length 64
07:13:31.429842 IP 90.167.219.193 > 44.27.132.76: ICMP echo request, id 44133,
seq 2, length 64
07:13:31.429860 IP 44.27.132.76 > 90.167.219.193: ICMP echo reply, id 44133,
seq 2, length 64
07:13:32.429833 IP 90.167.219.193 > 44.27.132.76: ICMP echo request, id 44133,
seq 3, length 64
07:13:32.429851 IP 44.27.132.76 > 90.167.219.193: ICMP echo reply, id 44133,
seq 3, length 64
07:13:37.531243 IP 90.167.219.193.44127 > 44.27.132.76.22: Flags [S], seq
145184924, win 65535, options [mss 1410,sackOK,TS val 851808448 ecr 0,nop,wscale
10], length 0
07:13:37.531257 IP 44.27.132.76.22 > 90.167.219.193.44127: Flags [S.], seq
1482509222, ack 145184925, win 32768, options [mss 1460,nop,wscale 3,sackOK,TS val
1 ecr 851808448], length 0
07:13:37.701029 IP 90.167.219.193.44127 > 44.27.132.76.22: Flags [.], ack 1,
win 86, options [nop,nop,TS val 851808627 ecr 1], length 0
0
Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes
Hello Greg
With the following routes I can ping fine from the mobile phone, please see
below. But when I try to start a SSH session, it never success.
netbsd-raspaZeroW# route -n show
Routing tables
Internet:
DestinationGatewayFlagsRefs UseMtu Interface
default44.27.132.76 UGS -- - wg0
44.27.132.76 wg0UHl -- - wg0
44.27.132.76/3244.27.132.76 U -- - wg0
44.27.227.1192.168.1.1UGHS-- - bwfm0
127/8 127.0.0.1 UGRS-- 33176 lo0
127.0.0.1 lo0UHl -- 33176 lo0
192.168.1/24 link#2 UC -- - bwfm0
192.168.1.230 link#2 UHl -- - lo0
192.168.1.203 d8:3a:dd:99:78:45 UHL -- - bwfm0
192.168.1.160:8d:26:32:34:23 UHL -- - bwfm0
192.168.1.51 20:28:bc:eb:8d:ae UHL -- - bwfm0
23:19:10.181755 IP 90.167.219.193 > 44.27.132.76: ICMP echo request, id 25199,
seq 1, length 64
23:19:10.181941 IP 44.27.132.76 > 90.167.219.193: ICMP echo reply, id 25199,
seq 1, length 64
23:19:13.699283 IP 90.167.219.193.25196 > 44.27.132.76.22: Flags [S], seq 3379571502, win 65535, options [mss 1410,sackOK,TS val 845496656 ecr
0,nop,wscale 10], length 0
23:19:13.699422 IP 44.27.132.76.22 > 90.167.219.193.25196: Flags [S.], seq 1838093467, ack 3379571503, win 32768, options [mss 1460,nop,wscale
3,sackOK,TS val 1 ecr 845496656], length 0
23:19:13.869650 IP 90.167.219.193.25196 > 44.27.132.76.22: Flags [.], ack 1,
win 86, options [nop,nop,TS val 845496833 ecr 1], length 0
23:19:13.870218 IP 90.167.219.193.25196 > 44.27.132.76.22: Flags [P.], seq
1:23, ack 1, win 86, options [nop,nop,TS val 845496837 ecr 1], length 22
23:19:14.062777 IP 44.27.132.76.22 > 90.167.219.193.25196: Flags [.], ack 23,
win 4194, options [nop,nop,TS val 2 ecr 845496837], length 0
23:19:14.142755 IP 44.27.132.76.22 > 90.167.219.193.25196: Flags [P.], seq
1:64, ack 23, win 4194, options [nop,nop,TS val 2 ecr 845496837], length 63
23:19:14.309616 IP 90.167.219.193.25196 > 44.27.132.76.22: Flags [.], ack 64,
win 86, options [nop,nop,TS val 845497277 ecr 2], length 0
23:19:14.309778 IP 44.27.132.76.22 > 90.167.219.193.25196: Flags [P.], seq 64:1184, ack 23, win 4197, options [nop,nop,TS val 2 ecr 845497277], length
1120
23:19:14.317253 IP 90.167.219.193.25196 > 44.27.132.76.22: Flags [P.], seq
1421:1591, ack 64, win 86, options [nop,nop,TS val 845497281 ecr 2], length 170
23:19:14.317375 IP 44.27.132.76.22 > 90.167.219.193.25196: Flags [.], ack 23, win 4197, options [nop,nop,TS val 2 ecr 845497277,nop,nop,sack 1
{1421:1591}], length 0
23:19:14.522748 IP 90.167.219.193.25196 > 44.27.132.76.22: Flags [.], ack 1184,
win 89, options [nop,nop,TS val 845497496 ecr 2], length 0
^C
32 packets captured
32 packets received by filter
0 packets dropped by kernel
netbsd-raspaZeroW#
ssh server on the RPi negociates but it never ends. AI suggests that UDP packets inside the tunnel are corrupted because (perhaps) a flaky bwfm
driver, but how knows, many times it says wrong things...
(Also the interface needs to be "resurrected" as before, but it is another
story)
We are far better than before but I does not work yet.
Regards.
Ramiro.
El 30/1/26 a las 16:25, Greg Troxel escribió:
Ramiro Aceves writes:
El 28/1/26 a las 1:19, Greg Troxel escribió:
Ramiro Aceves writes:
I am using this two commands to monitor interfaces in the RPi ZeroW:
tcpdump icmp -i wg0 ---> to monitor the wireguard interface
tcpdump icmp -i bwfm0 ---> to monitor the WIFI link to the home router.
Don't use filters, or filter out stuff you dno't want to see. The
wireguard packets surely are some UDP port or similar and encrypted, so
icmp will not match.
Thanks for answering. The problem is that because of by my lack of
understanding about networking I do not know what to monitor ;-) I
knew that ping uses ICMP packets so I wanted to see them alone and
discarded everything. I saw that bwmf0 tcmpdump out put was with high
traffic and was lost watching so many lines of (for me) cryptic
messages ;-) >
That's why I suggested, or meant to suggest, writing to a file, so that
you can go over it later and filter out what you know doesn't matter.
Generally when debugging it's important to avoid excluding things that
you don't expect that might matter.
raspaZeroW# ping -c 1 44.27.132.76
you are pinging your own address? That should stay local.
Yes, I am pinging my 44 net assigned address from the RPiZero. Should
it correspond to:?
44.27.132.76 wg0UHl -- - wg0
44.27.132.76/3244.27.132.76 U -- - wg0
I think it should stay local. For example, if I ping my (inner) side of
a gi
Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes
Ramiro Aceves writes: > El 28/1/26 a las 1:19, Greg Troxel escribió: >> Ramiro Aceves writes: >> >>> I am using this two commands to monitor interfaces in the RPi ZeroW: >>> >>> tcpdump icmp -i wg0 ---> to monitor the wireguard interface >>> tcpdump icmp -i bwfm0 ---> to monitor the WIFI link to the home router. >> Don't use filters, or filter out stuff you dno't want to see. The >> wireguard packets surely are some UDP port or similar and encrypted, so >> icmp will not match. > > Thanks for answering. The problem is that because of by my lack of > understanding about networking I do not know what to monitor ;-) I > knew that ping uses ICMP packets so I wanted to see them alone and > discarded everything. I saw that bwmf0 tcmpdump out put was with high > traffic and was lost watching so many lines of (for me) cryptic > messages ;-) > That's why I suggested, or meant to suggest, writing to a file, so that you can go over it later and filter out what you know doesn't matter. Generally when debugging it's important to avoid excluding things that you don't expect that might matter. >>> raspaZeroW# ping -c 1 44.27.132.76 >> you are pinging your own address? That should stay local. > > Yes, I am pinging my 44 net assigned address from the RPiZero. Should > it correspond to:? > > 44.27.132.76 wg0UHl -- - wg0 > 44.27.132.76/3244.27.132.76 U -- - wg0 I think it should stay local. For example, if I ping my (inner) side of a gif tunnel, the RTT is 340 us, clearly local. But I haven't set up wireguard, and I haven't read the driver. > I believe that pings from outside reach the RPI through the tunnel in > wg0 but the ICMP reply try to go via the default route 192.168.1.1. I > do not know, perhaps I am saying silly things. I think you are correct, and the problem is that your tunnel setup does not really make sense. > root@freebsd-nuc8i7:/home/ramiro # netstat -rn > Routing tables > > Internet: > DestinationGatewayFlags Netif Expire > 0.0.0.0/1 link#3 US wg0 > default192.168.1.1UGS em0 > 44.27.132.76 link#2 UH lo0 > 44.27.227.1192.168.1.1UGHSem0 > 127.0.0.1 link#2 UH lo0 > 128.0.0.0/1link#3 US wg0 > 192.168.1.0/24 link#1 U em0 > 192.168.1.200 link#2 UHS lo0 Here, in addition to what you have in NetBSD, there are a pair of half-default routes that route all traffic into the tunnel, or at least that's what I think is going on. Often when doing "VPN" what's what people want. > The intended usage for this setup would be setting up a lighttpd WEB > server in the RPiZeroW that would be accessible from the hole > internet. So you really do want all outgoing packets -- except for the wrapped packets -- to go via wg. >> The next question is what prefix is supposed to be reachable via wg? > > I do not understand, sorry. I meant whether the tunnel is supposed to let you connect to the entire internet, or just the (remaining part of) net 44. Back when I used net 44, it was over-the-air only, and there were not gateways to the internet, on purpose, for rules compliance. Now it seems to be normal internet for ham community.
Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes
Hello, I confirm that sending a ping from my mobile phone originates a reply via bwfm0 (nothing in wg0) but it is never acknowledged by my phone (1 packet transmitted, 0 received). I also see what you noticed that seq0 is missing. tcpdump -n -i wg0 15:44:58.522606 IP 90.167.219.193 > 44.27.132.76: ICMP echo request, id 31395, seq 1, length 64 tcpdump -n -i bwfm0 host 44.27.132.76 15:44:58.522978 IP 44.27.132.76 > 90.167.219.193: ICMP echo reply, id 31395, seq 1, length 64 Regards.
Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes
El 28/1/26 a las 1:19, Greg Troxel escribió: Ramiro Aceves writes: I am using this two commands to monitor interfaces in the RPi ZeroW: tcpdump icmp -i wg0 ---> to monitor the wireguard interface tcpdump icmp -i bwfm0 ---> to monitor the WIFI link to the home router. Don't use filters, or filter out stuff you dno't want to see. The wireguard packets surely are some UDP port or similar and encrypted, so icmp will not match. Thanks for answering. The problem is that because of by my lack of understanding about networking I do not know what to monitor ;-) I knew that ping uses ICMP packets so I wanted to see them alone and discarded everything. I saw that bwmf0 tcmpdump out put was with high traffic and was lost watching so many lines of (for me) cryptic messages ;-) > I have discovered that pinging from outside (using the mobile phone connected to the 4G network under Termux terminal emulator) leads to ICMP tcpdump activity in the RPi but after several seconds, 25 seconds or something like that, the tcpdump activity with the pings from outside dissappears. I stops showing the ICMP requests. (I do not know if it has to do with the lack of PersistentKeepAlive WIreGuard parameter. interesting, could be relevant. Also discovered that in order to resurrect the tcpdump activity to pings, it can be reached by pinging the asignated IP on the 44 Net: raspaZeroW# ping -c 1 44.27.132.76 you are pinging your own address? That should stay local. Yes, I am pinging my 44 net assigned address from the RPiZero. Should it correspond to:? 44.27.132.76 wg0UHl -- - wg0 44.27.132.76/3244.27.132.76 U -- - wg0 Then I get the following ICMP doubled packets on the wg0 interface. Resurrecting procedure sometimes work inmediatley but others it takes some time. It would be good if you could figure out how not to wrap tcpdump output. I do not know if thunderbird is wrapping the lines or it was a matter of how I copy-pasted from the open XCFE4 terminals, sorry for that. netbsd-raspaZeroW# tcpdump icmp -i wg0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wg0, link-type NULL (BSD loopback), capture size 262144 bytes 18:03:42.210703 IP 44.27.132.76 > 44.27.132.76: ICMP echo request, id 12426, seq 0, length 64 18:03:42.340073 IP 44.27.132.76 > 44.27.132.76: ICMP echo request, id 12426, seq 0, length 64 18:03:42.341594 IP 44.27.132.76 > 44.27.132.76: ICMP echo reply, id 12426, seq 0, length 64 18:03:42.411632 IP 44.27.132.76 > 44.27.132.76: ICMP echo reply, id 12426, seq 0, length 64 That looks like the packets are round tripped via the server. Nothing is heard on bwfm0 interface. because you are filtering on icmp. Argg sorry, I should repeat it better done. After resurrecting the link with: raspaZeroW# ping -c 1 44.27.132.76 what is in the wg logs? I am going to repeat the tests and we will see, in order to match the wg logs with the executed commands. I issued this ping from the mobile phone calling my 44Net assigned IP: $ping -c 1 -w 2 44.27.132.76 (from the mobile phone outside under Termux) netbsd-raspaZeroW# tcpdump icmp -i wg0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wg0, link-type NULL (BSD loopback), capture size 262144 bytes .. .. 18:14:53.278440 IP 208.pool90-167-219.static.orange.es > 44.27.132.76: ICMP echo request, id 18250, seq 1, length 64 18:14:54.278530 IP 208.pool90-167-219.static.orange.es > 44.27.132.76: ICMP echo request, id 18250, seq 2, length 64 there is no reply in wg0. Should replies be observed in this interface?, I think... yes, and interesting that seq0 is missing and the timestamps are so close. I did not noticed it, it is the problem of not understanding. I have started to read the CCNA Cisco Networking course in order to understand all of this. I do not understand routing. I will pass looong time before I understand a bit more about this networking subject. In bwfm0 there is a reply: netbsd-raspaZeroW# tcpdump icmp -i bwfm0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bwfm0, link-type EN10MB (Ethernet), capture size 262144 bytes .. .. 18:14:53.278953 IP 44.27.132.76 > 208.pool90-167-219.static.orange.es: ICMP echo reply, id 18250, seq 1, length 64 18:14:54.278995 IP 44.27.132.76 > 208.pool90-167-219.static.orange.es: ICMP echo reply, id 18250, seq 2, length 64 this is a huge clue. Your routing table is messed up! I believe that pings from outside reach the RPI through the tunnel in wg0 but the ICMP reply try to go via the default route 192.168.1.1. I do not know, perhaps I am saying silly things. I tried to replicate the FreeBSD routing table with no luck, but I think it is a complete nosense. Perhaps their implementation is completely different from NetBSD. They route 44.27.132.76 to the lo0 interface
Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes
Ramiro Aceves writes: > I am using this two commands to monitor interfaces in the RPi ZeroW: > > tcpdump icmp -i wg0 ---> to monitor the wireguard interface > tcpdump icmp -i bwfm0 ---> to monitor the WIFI link to the home router. Don't use filters, or filter out stuff you dno't want to see. The wireguard packets surely are some UDP port or similar and encrypted, so icmp will not match. > I have discovered that pinging from outside (using the mobile phone > connected to the 4G network under Termux terminal emulator) leads to > ICMP tcpdump activity in the RPi but after several seconds, 25 seconds > or something like that, the tcpdump activity with the pings from > outside dissappears. I stops showing the ICMP requests. (I do not > know if it has to do with the lack of PersistentKeepAlive WIreGuard > parameter. interesting, could be relevant. > Also discovered that in order to resurrect the tcpdump activity to > pings, it can be reached by pinging the asignated IP on the 44 Net: > > raspaZeroW# ping -c 1 44.27.132.76 you are pinging your own address? That should stay local. > Then I get the following ICMP doubled packets on the wg0 > interface. Resurrecting procedure sometimes work inmediatley but > others it takes some time. It would be good if you could figure out how not to wrap tcpdump output. > netbsd-raspaZeroW# tcpdump icmp -i wg0 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on wg0, link-type NULL (BSD loopback), capture size 262144 bytes > 18:03:42.210703 IP 44.27.132.76 > 44.27.132.76: ICMP echo request, id > 12426, seq 0, length 64 > 18:03:42.340073 IP 44.27.132.76 > 44.27.132.76: ICMP echo request, id > 12426, seq 0, length 64 > 18:03:42.341594 IP 44.27.132.76 > 44.27.132.76: ICMP echo reply, id > 12426, seq 0, length 64 > 18:03:42.411632 IP 44.27.132.76 > 44.27.132.76: ICMP echo reply, id > 12426, seq 0, length 64 That looks like the packets are round tripped via the server. > Nothing is heard on bwfm0 interface. because you are filtering on icmp. > After resurrecting the link with: > > raspaZeroW# ping -c 1 44.27.132.76 what is in the wg logs? > I issued this ping from the mobile phone calling my 44Net assigned IP: > > $ping -c 1 -w 2 44.27.132.76 (from the mobile phone outside under Termux) > netbsd-raspaZeroW# tcpdump icmp -i wg0 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on wg0, link-type NULL (BSD loopback), capture size 262144 bytes > .. > .. > 18:14:53.278440 IP 208.pool90-167-219.static.orange.es > 44.27.132.76: > ICMP echo request, id 18250, seq 1, length 64 > 18:14:54.278530 IP 208.pool90-167-219.static.orange.es > 44.27.132.76: > ICMP echo request, id 18250, seq 2, length 64 > > there is no reply in wg0. Should replies be observed in this > interface?, I think... yes, and interesting that seq0 is missing and the timestamps are so close. > In bwfm0 there is a reply: > > netbsd-raspaZeroW# tcpdump icmp -i bwfm0 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on bwfm0, link-type EN10MB (Ethernet), capture size 262144 bytes > .. > .. > > 18:14:53.278953 IP 44.27.132.76 > 208.pool90-167-219.static.orange.es: > ICMP echo reply, id 18250, seq 1, length 64 > 18:14:54.278995 IP 44.27.132.76 > 208.pool90-167-219.static.orange.es: > ICMP echo reply, id 18250, seq 2, length 64 this is a huge clue. Your routing table is messed up! > netbsd-raspaZeroW# route -n show > Routing tables > > Internet: > DestinationGatewayFlagsRefs UseMtu > Interface > default192.168.1.1UGS -- - bwfm0 > 44.27.132.76 wg0UHl -- - wg0 > 44.27.132.76/3244.27.132.76 U -- - wg0 > 127/8 127.0.0.1 UGRS-- 33176 lo0 > 127.0.0.1 lo0UHl -- 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.160:8d:26:32:34:23 UHL -- - bwfm0 This is odd in two ways: the /32 is to wg0, not to lo0, and/or one's own address in wg0 isn't looped back you have a default route, and only one address is sent to wireguard. You need to figure out how you want the vpn to work. Do you want this machine to be on net 44 primarily? Then you want to add routes for the wg tunnel, and point the default route into wg. Or is the net44 wg setup only for you to talk to other net44 hosts? You said things "work" in FreeBSD. Do the same diagnosing there. > raspaZeroW# route get 44.27.132.76 >route to: 44.27.132.76 > destination: 44.27.132.76 > local add
Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes
El 26/1/26 a las 14:41, Greg Troxel escribió: Ramiro Aceves writes: Sorry, after adding that route pinging from outside does not work either. When debugging try to obtain intermediate information. First step is to tcpdump on the actual WAN interface and then on wg0, while pinging from outside, and see if you see plausible ciphertext pings arriving and then decrypted icmp echo request on wg0. Then see if you see replies on wg0 and plausible ciphertext replies on the wan interface. If not, then ping from the local machine and watch as well. read the man page for 'route get' and run that, to see how outbound packets are routed. finally, turn on ip forwarding, even if you know it doesn't matter, and see if that changes anything, because it's an easy experiment. Hello Greg, This is what I have experimented today. Sorry for the rudimentary blind procedure but I am newbie in networking and I do not know well what I am doing. I am using this two commands to monitor interfaces in the RPi ZeroW: tcpdump icmp -i wg0 ---> to monitor the wireguard interface tcpdump icmp -i bwfm0 ---> to monitor the WIFI link to the home router. I have discovered that pinging from outside (using the mobile phone connected to the 4G network under Termux terminal emulator) leads to ICMP tcpdump activity in the RPi but after several seconds, 25 seconds or something like that, the tcpdump activity with the pings from outside dissappears. I stops showing the ICMP requests. (I do not know if it has to do with the lack of PersistentKeepAlive WIreGuard parameter. Also discovered that in order to resurrect the tcpdump activity to pings, it can be reached by pinging the asignated IP on the 44 Net: raspaZeroW# ping -c 1 44.27.132.76 Then I get the following ICMP doubled packets on the wg0 interface. Resurrecting procedure sometimes work inmediatley but others it takes some time. netbsd-raspaZeroW# tcpdump icmp -i wg0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wg0, link-type NULL (BSD loopback), capture size 262144 bytes 18:03:42.210703 IP 44.27.132.76 > 44.27.132.76: ICMP echo request, id 12426, seq 0, length 64 18:03:42.340073 IP 44.27.132.76 > 44.27.132.76: ICMP echo request, id 12426, seq 0, length 64 18:03:42.341594 IP 44.27.132.76 > 44.27.132.76: ICMP echo reply, id 12426, seq 0, length 64 18:03:42.411632 IP 44.27.132.76 > 44.27.132.76: ICMP echo reply, id 12426, seq 0, length 64 Nothing is heard on bwfm0 interface. After resurrecting the link with: raspaZeroW# ping -c 1 44.27.132.76 I issued this ping from the mobile phone calling my 44Net assigned IP: $ping -c 1 -w 2 44.27.132.76 (from the mobile phone outside under Termux) netbsd-raspaZeroW# tcpdump icmp -i wg0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wg0, link-type NULL (BSD loopback), capture size 262144 bytes .. .. 18:14:53.278440 IP 208.pool90-167-219.static.orange.es > 44.27.132.76: ICMP echo request, id 18250, seq 1, length 64 18:14:54.278530 IP 208.pool90-167-219.static.orange.es > 44.27.132.76: ICMP echo request, id 18250, seq 2, length 64 there is no reply in wg0. Should replies be observed in this interface?, I think... In bwfm0 there is a reply: netbsd-raspaZeroW# tcpdump icmp -i bwfm0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bwfm0, link-type EN10MB (Ethernet), capture size 262144 bytes .. .. 18:14:53.278953 IP 44.27.132.76 > 208.pool90-167-219.static.orange.es: ICMP echo reply, id 18250, seq 1, length 64 18:14:54.278995 IP 44.27.132.76 > 208.pool90-167-219.static.orange.es: ICMP echo reply, id 18250, seq 2, length 64 But on the phone, where the pings are originated, there is never a response to the pings. The routing table: netbsd-raspaZeroW# route -n show Routing tables Internet: DestinationGatewayFlagsRefs UseMtu Interface default192.168.1.1UGS -- - bwfm0 44.27.132.76 wg0UHl -- - wg0 44.27.132.76/3244.27.132.76 U -- - wg0 127/8 127.0.0.1 UGRS-- 33176 lo0 127.0.0.1 lo0UHl -- 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.160:8d:26:32:34:23 UHL -- - bwfm0 raspaZeroW# route get 44.27.132.76 route to: 44.27.132.76 destination: 44.27.132.76 local addr: 44.27.132.76 interface: wg0 flags: 0x40045 recvpipe sendpipe ssthresh rtt,msecrttvar hopcount mtu expire 0 0 0 0
Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes
El 26/1/26 a las 14:41, Greg Troxel escribió: Ramiro Aceves writes: Sorry, after adding that route pinging from outside does not work either. When debugging try to obtain intermediate information. Yes, thanks Greg for help I am going to try to start making such tests (from my ignorance about networking, and sure I will learn from them), that way I could make a better picture for you and the people than understand this networking hard subjects. Regards. First step is to tcpdump on the actual WAN interface and then on wg0, while pinging from outside, and see if you see plausible ciphertext pings arriving and then decrypted icmp echo request on wg0. Then see if you see replies on wg0 and plausible ciphertext replies on the wan interface. If not, then ping from the local machine and watch as well. read the man page for 'route get' and run that, to see how outbound packets are routed. finally, turn on ip forwarding, even if you know it doesn't matter, and see if that changes anything, because it's an easy experiment.
Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes
El 26/1/26 a las 14:54, Sad Clouds escribió: On Mon, 26 Jan 2026 12:30:08 +0100 Ramiro Aceves wrote: Sorry, after adding that route pinging from outside does not work either. I'm not sure what you mean by outside. I currently use wireguard on a LAN. The way I have it set up - I have a server and a client. I can initiate a connection from client to server any time, but not the other way round if wgconfig on the server shows latest-handshake as never for this peer: wgconfig wg0 interface: wg0 private-key: (hidden) listen-port: 51820 peer: test public-key: XXX endpoint: (none) preshared-key: (hidden) allowed-ips: 10.1.5.50/32 latest-handshake: (never) Once I establish a connection from the client and keepalive is running, I can then ping this client from the server: # ping 10.1.5.50 PING 10.1.5.50 (10.1.5.50): 56 data bytes 64 bytes from 10.1.5.50: icmp_seq=0 ttl=255 time=0.640570 ms 64 bytes from 10.1.5.50: icmp_seq=1 ttl=255 time=0.647329 ms 64 bytes from 10.1.5.50: icmp_seq=2 ttl=255 time=0.626626 ms I think you can configure wireguard server so it acts as a server and client at the same time by specifying option "--endpoint=" in the "add peer" command, but I've not tried it yet. Hello Sad, Thanks for answering. My setup is a bit different than yours. I have a wireguard NetBSD-10.1 client on my raspberry PI ZeroW. My RpiZero is connected to my home router via WIFI (other equipments are also connected to my home LAN, by WIFI or ethernet, but they do not take into account for this problem.). Rpi is 192.168.1.230. Router is 192.168.1.1 and it is the gateway to the internet. On the other side, outside home, on the internet, www.ampr.org asigned to me a 44.27.132.76 IP (There are many reserved IP for licensed amateur radio hams in order to experiment). Also, https://connect.44net.cloud/ provides to the registered users a tunnel to their IPs (in my case, 44.27.132.76). That IP is accessible from all the internet. So when the tunnel is properly configured, any one from anywhere in the internet can ping 44.27.132.76 or access to an SSH or WEB server you may configure at the other side of the tunnel, in your home. (I have tested it both that works in Linux and FreeBSD, to discard any problems before continue fighting it in NetBSD operating system) Ping from the internet to 44.27.132.76 do not work. My RPiZeroW does not reply to ping ICMP requests. SSH does not work either. I configure my tunnel this way: 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 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# Hope I have clarified it a bit more. Regards. Ramiro.
Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes
On Mon, 26 Jan 2026 12:30:08 +0100 Ramiro Aceves wrote: > Sorry, after adding that route pinging from outside does not work either. I'm not sure what you mean by outside. I currently use wireguard on a LAN. The way I have it set up - I have a server and a client. I can initiate a connection from client to server any time, but not the other way round if wgconfig on the server shows latest-handshake as never for this peer: wgconfig wg0 interface: wg0 private-key: (hidden) listen-port: 51820 peer: test public-key: XXX endpoint: (none) preshared-key: (hidden) allowed-ips: 10.1.5.50/32 latest-handshake: (never) Once I establish a connection from the client and keepalive is running, I can then ping this client from the server: # ping 10.1.5.50 PING 10.1.5.50 (10.1.5.50): 56 data bytes 64 bytes from 10.1.5.50: icmp_seq=0 ttl=255 time=0.640570 ms 64 bytes from 10.1.5.50: icmp_seq=1 ttl=255 time=0.647329 ms 64 bytes from 10.1.5.50: icmp_seq=2 ttl=255 time=0.626626 ms I think you can configure wireguard server so it acts as a server and client at the same time by specifying option "--endpoint=" in the "add peer" command, but I've not tried it yet.
Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes
Ramiro Aceves writes: > Sorry, after adding that route pinging from outside does not work either. When debugging try to obtain intermediate information. First step is to tcpdump on the actual WAN interface and then on wg0, while pinging from outside, and see if you see plausible ciphertext pings arriving and then decrypted icmp echo request on wg0. Then see if you see replies on wg0 and plausible ciphertext replies on the wan interface. If not, then ping from the local machine and watch as well. read the man page for 'route get' and run that, to see how outbound packets are routed. finally, turn on ip forwarding, even if you know it doesn't matter, and see if that changes anything, because it's an easy experiment.
Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes
El 26/1/26 a las 10:21, Sad Clouds escribió: On Sun, 25 Jan 2026 08:43:51 +0100 Ramiro Aceves wrote: netbsd-raspaZeroW# route -n show Routing tables Internet: DestinationGatewayFlagsRefs UseMtu Interface default192.168.1.1UGS -- - bwfm0 44.27.132.76 wg0UHl -- - wg0 44.27.132.76/3244.27.132.76 U -- - wg0 I'm not sure how netbsd kernel deals with /32 netmask but it seems it is not routing packets and treating it as a local destination. You may need to add a static route with a different netmask, e.g.: route add -net 44.27.132.76/24 -interface 44.27.132.76 Thanks Sad, Sorry, after adding that route pinging from outside does not work either. Thanks so much for your help. Regards.
Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes
On Sun, 25 Jan 2026 08:43:51 +0100 Ramiro Aceves wrote: > netbsd-raspaZeroW# route -n show > Routing tables > > Internet: > DestinationGatewayFlagsRefs UseMtu > Interface > default192.168.1.1UGS -- - bwfm0 > 44.27.132.76 wg0UHl -- - wg0 > 44.27.132.76/3244.27.132.76 U -- - wg0 I'm not sure how netbsd kernel deals with /32 netmask but it seems it is not routing packets and treating it as a local destination. You may need to add a static route with a different netmask, e.g.: route add -net 44.27.132.76/24 -interface 44.27.132.76
Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes
El 25/1/26 a las 10:16, J. Hannken-Illjes escribió: 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] Hello, Thanks for answering: I have the following default sysctl values, opposite settings to the settings you posted: netbsd-raspaZeroW# sysctl net.inet.ip.forwarding net.inet.ip.forwarding = 0 netbsd-raspaZeroW# sysctl net.inet.ip.redirect net.inet.ip.redirect = 1 netbsd-raspaZeroW# netstat -s -I wg0 wg0 1380 144 0 11 0 0 wg0 1380 44.27.132.76/ 44.27.132.76 144 0 11 0 0 wg0 1380 fe80::/64 fe80::ba27:ebff:f 144 0 11 0 0 wg0 1380 fe80::644d:cf fe80::644d:cf7a:c 144 0 11 0 0 netbsd-raspaZeroW# netbsd-raspaZeroW# netstat -s icmp: 12 calls to icmp_error 0 errors not generated because old message was icmp Output histogram: echoreply: 1 unreach: 12 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored Input histogram: echoreply: 31 echo: 1 1 message response generated 0 path MTU changes igmp: 0 messages received 0 messages received with too few bytes 0 messages received with bad checksum 0 membership queries received 0 membership queries received with invalid field(s) 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 2 membership reports sent tcp: 6747 packets sent 6670 data packets (347061 bytes) 0 data packets (0 bytes) retransmitted 71 ack-only packets (6225 delayed) 0 URG only packets 0 window probe packets 2 window update packets 4 control packets 0 send attempts resulted in self-quench 6869 packets received 6255 acks (for 346984 bytes) 0 duplicate acks 0 acks for unsent data 6273 packets (255397 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 5 out-of-order packets (144 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 2 connection requests 1 connection accept 3 connections established (including accepts) 67 connections closed (including 0 drops) 0 embryonic connections dropped 0 delayed frees of tcpcb 6257 segments updated rtt (of 6194 attempts) 0 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts (resulting in 0 dropped connections) 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 43 correct ACK header predictions 150 correct data packet header predictions 261 PCB hash misses 128 dropped due to no socket 0 connections drained due to memory shortage 0 PMTUD blackholes detected 1 bad connection attempt 3 SYN cache entries added 0 hash collisions 1 completed 0 aborted (no space to build PCB) 2 timed out 0 dropped due to overflow 0 dropped due to bucket overflow 0 dropped due to RST 0 dropped due to ICMP unreachable 1 delayed free of SYN cache entries 8 SYN,ACKs retransmitted 0 duplicate SYNs received for entries already in the cache 0 SYNs dropped (no route or no space) 0 packets with bad signature 0 packets with good signature 0 successful ECN handshakes 0 packets with ECN CE bit 0 packets ECN ECT(0) bit udp: 362 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 12 dropped due to no socket 0 broadcast/multicast datagrams dropped due to no socket 0 dropped due to full socket buffers 350 delivered 333 PCB hash misses 255 dat
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 - [email protected] > On 25. Jan 2026, at 08:43, Ramiro Aceves 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 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/1link#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: > DestinationGatewayFlagsRefs UseMtu Interface > default192.168.1.1UGS -- - bwfm0 > 44.27.132.76 wg0UHl -- - wg0 > 44.27.132.76/3244.27.132.76 U -- - wg0 >
WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes
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 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/1link#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: DestinationGatewayFlagsRefs UseMtu Interface default192.168.1.1UGS -- - bwfm0 44.27.132.76 wg0UHl -- - wg0 44.27.132.76/3244.27.132.76 U -- - wg0 127/8 127.0.0.1 UGRS-- 33176 lo0 127.0.0.1 lo0UHl -- 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.160:8d:26:32:34:23 UHL --
Re: Wireguard woes
El 21/1/26 a las 10:49, Martin Husemann escribió: On Wed, Jan 21, 2026 at 10:44:45AM +0100, Ramiro Aceves wrote: Do you think that in NetBSD-current may I have better luck? I am not aware of any changes that have not been pulled up. Did you try enabling the debug sysctl? Martin Hi Martin , Thanks for answering. Yes, plenty of messages on dmesg after activating debug sysctl (messages that I do not understand from an user perspective :-) ) . Here just an example with the real IPs, no problem at all showing them: Regards. [ 97929.799124] wg_validate_inner_packet: af=2 [ 97929.799124] wg_pick_peer_by_sa: sa=inet: 172.234.192.12 [ 97929.799124] wg_handle_msg_data: time_uptime32=97929 wgs_time_last_data_sent=97929 [ 97929.799124] wg_overudp_cb: type=4 [ 97929.799124] wg_handle_msg_data: mlen=96, encrypted_len=80 [ 97929.799124] wg_handle_msg_data: outsize=64 [ 97929.799124] wg_update_endpoint_if_necessary: old=inet: 44.27.227.1:44000, new=inet: 44.27.227.1:44000 [ 97929.799124] wg_validate_inner_packet: af=2 [ 97929.799124] wg_pick_peer_by_sa: sa=inet: 137.184.215.78 [ 97929.799124] wg_handle_msg_data: time_uptime32=97929 wgs_time_last_data_sent=97929 [ 97929.799124] wg_overudp_cb: type=4 [ 97929.799124] wg_handle_msg_data: mlen=80, encrypted_len=64 [ 97929.799124] wg_handle_msg_data: outsize=48 [ 97929.799124] wg_update_endpoint_if_necessary: old=inet: 44.27.227.1:44000, new=inet: 44.27.227.1:44000 [ 97929.799124] wg_validate_inner_packet: af=2 [ 97929.799124] wg_pick_peer_by_sa: sa=inet: 95.168.178.138 [ 97929.799124] wg_handle_msg_data: time_uptime32=97929 wgs_time_last_data_sent=97929 [ 97929.799124] wg_overudp_cb: type=4 [ 97929.799124] wg_handle_msg_data: mlen=80, encrypted_len=64 [ 97929.799124] wg_handle_msg_data: outsize=48 [ 97929.799124] wg_update_endpoint_if_necessary: old=inet: 44.27.227.1:44000, new=inet: 44.27.227.1:44000 [ 97929.799124] wg_validate_inner_packet: af=2 [ 97929.799124] wg_pick_peer_by_sa: sa=inet: 95.168.178.138 [ 97929.799124] wg_handle_msg_data: time_uptime32=97929 wgs_time_last_data_sent=97929 [ 97929.799124] wg_overudp_cb: type=4 [ 97929.799124] wg_handle_msg_data: mlen=80, encrypted_len=64 [ 97929.799124] wg_handle_msg_data: outsize=48 [ 97929.799124] wg_update_endpoint_if_necessary: old=inet: 44.27.227.1:44000, new=inet: 44.27.227.1:44000 [ 97929.799124] wg_validate_inner_packet: af=2 [ 97929.799124] wg_pick_peer_by_sa: sa=inet: 142.147.97.21 [ 97929.799124] wg_handle_msg_data: time_uptime32=97929 wgs_time_last_data_sent=97929 [ 97929.799124] wg_overudp_cb: type=4 [ 97929.799124] wg_handle_msg_data: mlen=128, encrypted_len=112 [ 97929.799124] wg_handle_msg_data: outsize=96 [ 97929.799124] wg_update_endpoint_if_necessary: old=inet: 44.27.227.1:44000, new=inet: 44.27.227.1:44000 [ 97929.799124] wg_validate_inner_packet: af=2 [ 97929.799124] wg_pick_peer_by_sa: sa=inet: 44.27.132.76 [ 97929.799124] wg_handle_msg_data: time_uptime32=97929 wgs_time_last_data_sent=97929 [ 97929.799124] wg_pick_peer_by_sa: sa=inet: 44.27.132.76 [ 97929.799124] wg_send_data_msg: inner=84, padded=96, encrypted_len=112 [ 97929.799124] wg_fill_msg_data: counter=1 [ 97929.849220] wg_overudp_cb: type=4 [ 97929.849220] wg_handle_msg_data: mlen=128, encrypted_len=112 [ 97929.859239] wg_handle_msg_data: outsize=96 [ 97929.859239] wg_update_endpoint_if_necessary: old=inet: 44.27.227.1:44000, new=inet: 44.27.227.1:44000 [ 97929.859239] wg_validate_inner_packet: af=2 [ 97929.859239] wg_pick_peer_by_sa: sa=inet: 44.27.132.76 [ 97929.859239] wg_handle_msg_data: time_uptime32=97929 wgs_time_last_data_sent=97929 [ 97939.759119] wg_overudp_cb: type=4 [ 97939.759119] wg_handle_msg_data: mlen=80, encrypted_len=64 [ 97939.759119] wg_handle_msg_data: outsize=48 [ 97939.759119] wg_update_endpoint_if_necessary: old=inet: 44.27.227.1:44000, new=inet: 44.27.227.1:44000 [ 97939.759119] wg_validate_inner_packet: af=2 [ 97939.759119] wg_pick_peer_by_sa: sa=inet: 178.20.210.151 [ 97939.759119] wg_handle_msg_data: time_uptime32=97939 wgs_time_last_data_sent=97929 [ 97939.759119] wg_schedule_peer_task: tasks=0, task=16 [ 97939.759119] wg_send_data_msg: inner=0, padded=0, encrypted_len=16 [ 97939.759119] wg_fill_msg_data: counter=2 [ 97946.592533] wg_overudp_cb: type=4 [ 97946.592533] wg_handle_msg_data: mlen=80, encrypted_len=64 [ 97946.592533] wg_handle_msg_data: outsize=48 [ 97946.592533] wg_update_endpoint_if_necessary: old=inet: 44.27.227.1:44000, new=inet: 44.27.227.1:44000 [ 97946.592533] wg_validate_inner_packet: af=2 [ 97946.592533] wg_pick_peer_by_sa: sa=inet: 79.124.40.114 [ 97946.592533] wg_handle_msg_data: time_uptime32=97946 wgs_time_last_data_sent=97939 [ 97949.383826] wg_overudp_cb: type=4 [ 97949.383826] wg_handle_msg_data: mlen=96, encrypted_len=80 [ 97949.383826] wg_handle_msg_data: outsize=64 [ 97949.383826] wg_update_endpoint_if_necessary: old=inet: 44.27.227.1:44000, new=inet: 44.27.227.1:44000 [ 97949.383826] wg_validate_inner_packet: af=2 [ 97949.383826
Re: Wireguard woes
On Wed, Jan 21, 2026 at 10:44:45AM +0100, Ramiro Aceves wrote: > Do you think that in NetBSD-current may I have better luck? I am not aware of any changes that have not been pulled up. Did you try enabling the debug sysctl? Martin
Re: Wireguard woes
El 20/1/26 a las 20:22, Ramiro Aceves escribió: El 20/1/26 a las 18:38, Martin Husemann escribió: On Tue, Jan 20, 2026 at 06:25:42PM +0100, Ramiro Aceves wrote: And then it works again from the local network. This may be related to the absence of the PersistentKeepalive = 20 parameter that comes in the configuration file sent by email from the tunnel provider and that does not exist in NetBSD implementation of WireGuard. It has a default keep alive of 10s, you can adjust it with sysctl net.wg.keepalive_timeout If you want to find out what goes wrong you should enable sysctl net.wg.debug and see if it logs something interesting. Martin Thanks Martin, Oh yes, that is the default, 10 seconds, but this way the connection drops, I do not know why if they recommend a keepalive of 20 seconds, it shoud be enough. It seems to always resurrect with ping to 44.x.y.z from the raspberry pi. netbsd-raspaZeroW# sysctl net.wg.keepalive_timeout net.wg.keepalive_timeout = 10 The "big" problem now is that I cannot ping the 44 IP from the outside. Regards. Ramiro. Hello, Do you think that in NetBSD-current may I have better luck? Thanks.
Re: Wireguard woes
El 20/1/26 a las 18:38, Martin Husemann escribió: On Tue, Jan 20, 2026 at 06:25:42PM +0100, Ramiro Aceves wrote: And then it works again from the local network. This may be related to the absence of the PersistentKeepalive = 20 parameter that comes in the configuration file sent by email from the tunnel provider and that does not exist in NetBSD implementation of WireGuard. It has a default keep alive of 10s, you can adjust it with sysctl net.wg.keepalive_timeout If you want to find out what goes wrong you should enable sysctl net.wg.debug and see if it logs something interesting. Martin Thanks Martin, Oh yes, that is the default, 10 seconds, but this way the connection drops, I do not know why if they recommend a keepalive of 20 seconds, it shoud be enough. It seems to always resurrect with ping to 44.x.y.z from the raspberry pi. netbsd-raspaZeroW# sysctl net.wg.keepalive_timeout net.wg.keepalive_timeout = 10 The "big" problem now is that I cannot ping the 44 IP from the outside. Regards. Ramiro.
Re: Wireguard woes
El 20/1/26 a las 19:53, Sad Clouds escribió: On Tue, 20 Jan 2026 18:25:42 +0100 Ramiro Aceves wrote: And then it works again from the local network. This may be related to the absence of the PersistentKeepalive = 20 parameter that comes in the configuration file sent by email from the tunnel provider and that does not exist in NetBSD implementation of WireGuard. If I'm not mistaken, persistent keepalive setting is sometimes needed for NAT firewalls that keep state. You can try running ping in a while loop every 10 seconds and see if this resolves connectivity issues. Hello Sad Thanks so much for your suggestion but it does not work. The trick mantains active the connection but I cannot ping from outside the local network to the asignated 44 net IP. I have just tested from Debian just to see and it works fine. I will continue investigating. Regards.
Re: Wireguard woes
On Tue, 20 Jan 2026 18:25:42 +0100 Ramiro Aceves wrote: > And then it works again from the local network. This may be related to > the absence of the PersistentKeepalive = 20 parameter that comes in the > configuration file sent by email from the tunnel provider and that does > not exist in NetBSD implementation of WireGuard. If I'm not mistaken, persistent keepalive setting is sometimes needed for NAT firewalls that keep state. You can try running ping in a while loop every 10 seconds and see if this resolves connectivity issues.
Re: Wireguard woes
On Tue, Jan 20, 2026 at 06:25:42PM +0100, Ramiro Aceves wrote: > And then it works again from the local network. This may be related to the > absence of the PersistentKeepalive = 20 parameter that comes in the > configuration file sent by email from the tunnel provider and that does not > exist in NetBSD implementation of WireGuard. It has a default keep alive of 10s, you can adjust it with sysctl net.wg.keepalive_timeout If you want to find out what goes wrong you should enable sysctl net.wg.debug and see if it logs something interesting. Martin
Re: Wireguard woes
El 20/1/26 a las 15:00, Sad Clouds escribió:
These are my notes for NetBSD and Linux.>
My normal subnet is 10.0.0.0/16 and wireguard VPN subnet is 10.1.0.0/16.
rp4-4g is my Raspberry Pi 4 4GB NFS server.
rp4-8g is my Raspberry Pi 4 8GB Debian NFS client.
z600 is my HP Z600 Debian NFS client.
Substitute these for your own IP addresses and peers. Good luck.
Configure NetBSD as WireGuard server:
Load if_wg module on boot:
vi /etc/modules.conf
if_wg
and then reboot
Generate server private and public keys:
umask 0077
mkdir /etc/wireguard
wg-keygen > /etc/wireguard/wg0.prv
wg-keygen --pub < /etc/wireguard/wg0.prv > /etc/wireguard/wg0.pub
umask 0022
Configure wg0 interface and add peers (max peer name length is 16 chars):
cat > /etc/ifconfig.wg0 << 'EOF'
inet 10.1.0.5/16
!wgconfig ${int} set private-key /etc/wireguard/${int}.prv
!wgconfig ${int} set listen-port 51820
!wgconfig ${int} add peer z600
--allowed-ips=10.1.0.2/32
!wgconfig ${int} add peer rp4-8g
--allowed-ips=10.1.0.6/32
up
EOF
rp4-4g$ ifconfig
genet0: flags=0x8843 mtu 1500
ec_capabilities=0x1
ec_enabled=0
address: dc:a6:32:31:71:32
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet6 fe80::dea6:32ff:fe31:7132%genet0/64 flags 0 scopeid 0x1
inet 10.0.0.5/16 broadcast 10.0.255.255 flags 0
lo0: flags=0x8049 mtu 33624
status: active
inet6 ::1/128 flags 0x20
inet6 fe80::1%lo0/64 flags 0 scopeid 0x2
inet 127.0.0.1/8 flags 0
wg0: flags=0x8041 mtu 1420
status: active
inet6 fe80::dea6:32ff:fe31:7132%wg0/64 flags 0 scopeid 0x3
inet 10.1.0.5/16 flags 0
Configure Debian as WireGuard client:
sudo aptitude install wireguard
Generate client private and public keys:
prv_key=$(wg genkey) &&
pub_key=$(echo ${prv_key:?} | wg pubkey) &&
echo "prv_key: ${prv_key}" &&
echo "pub_key: ${pub_key}" &&
unset prv_key pub_key
Manual config:
cat > /etc/network/interfaces.d/wg0 << 'EOF'
auto wg0
iface wg0 inet static
address 10.1.0.6
netmask 255.255.0.0
pre-up ip link add $IFACE type wireguard
pre-up wg setconf $IFACE /etc/wireguard/$IFACE.conf
#post-up ip route add 10.1.0.0/16 dev wg0
post-down ip link del $IFACE
EOF
cat > /etc/wireguard/wg0.conf << 'EOF'
[Interface]
PrivateKey =
[Peer]
Endpoint = 10.0.0.5:51820
PublicKey =
AllowedIPs = 10.1.0.5/32
EOF
Network manager config (alternative to manual config):
Connection name: vpn-rp4-4g
Interface name : wg0
Private key: XXX
Peers:
Public key : XXX
Allowed IPs: 10.1.0.5/32
Endpoint : 10.0.0.5:51820
IPv4 Settings:
Method : Manual
IP : 10.1.0.2
Netmask: 16
Gateway:
Thanks so much Sad for your great notes. I appreciate them very much. I
see that my NetBSD configuration is same as yours except for the
"wgconfig set listen-port " that I did not use cause I am in the
client side.
I observe that:
-Pinging from outside of the local network to 44.x.y.z: it doesn’t
work.
-Pinging from another machine on the local network to 44.x.y.z: it
works. But it only works for a while; afterwards it stops working. To
make it work again I have to do:
ifconfig wg0 down
ifconfig wg0 up
And then it works again from the local network. This may be related to
the absence of the PersistentKeepalive = 20 parameter that comes in the
configuration file sent by email from the tunnel provider and that does
not exist in NetBSD implementation of WireGuard.
I do not know...
I have tested the same thing in RaspberrypiZeroW and Raspberrypi4 with
same result. Both systems in NetBSD 10.1
Regards.
Ramiro.
Re: Wireguard woes
These are my notes for NetBSD and Linux.
My normal subnet is 10.0.0.0/16 and wireguard VPN subnet is 10.1.0.0/16.
rp4-4g is my Raspberry Pi 4 4GB NFS server.
rp4-8g is my Raspberry Pi 4 8GB Debian NFS client.
z600 is my HP Z600 Debian NFS client.
Substitute these for your own IP addresses and peers. Good luck.
Configure NetBSD as WireGuard server:
Load if_wg module on boot:
vi /etc/modules.conf
if_wg
and then reboot
Generate server private and public keys:
umask 0077
mkdir /etc/wireguard
wg-keygen > /etc/wireguard/wg0.prv
wg-keygen --pub < /etc/wireguard/wg0.prv > /etc/wireguard/wg0.pub
umask 0022
Configure wg0 interface and add peers (max peer name length is 16 chars):
cat > /etc/ifconfig.wg0 << 'EOF'
inet 10.1.0.5/16
!wgconfig ${int} set private-key /etc/wireguard/${int}.prv
!wgconfig ${int} set listen-port 51820
!wgconfig ${int} add peer z600
--allowed-ips=10.1.0.2/32
!wgconfig ${int} add peer rp4-8g
--allowed-ips=10.1.0.6/32
up
EOF
rp4-4g$ ifconfig
genet0: flags=0x8843 mtu 1500
ec_capabilities=0x1
ec_enabled=0
address: dc:a6:32:31:71:32
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet6 fe80::dea6:32ff:fe31:7132%genet0/64 flags 0 scopeid 0x1
inet 10.0.0.5/16 broadcast 10.0.255.255 flags 0
lo0: flags=0x8049 mtu 33624
status: active
inet6 ::1/128 flags 0x20
inet6 fe80::1%lo0/64 flags 0 scopeid 0x2
inet 127.0.0.1/8 flags 0
wg0: flags=0x8041 mtu 1420
status: active
inet6 fe80::dea6:32ff:fe31:7132%wg0/64 flags 0 scopeid 0x3
inet 10.1.0.5/16 flags 0
Configure Debian as WireGuard client:
sudo aptitude install wireguard
Generate client private and public keys:
prv_key=$(wg genkey) &&
pub_key=$(echo ${prv_key:?} | wg pubkey) &&
echo "prv_key: ${prv_key}" &&
echo "pub_key: ${pub_key}" &&
unset prv_key pub_key
Manual config:
cat > /etc/network/interfaces.d/wg0 << 'EOF'
auto wg0
iface wg0 inet static
address 10.1.0.6
netmask 255.255.0.0
pre-up ip link add $IFACE type wireguard
pre-up wg setconf $IFACE /etc/wireguard/$IFACE.conf
#post-up ip route add 10.1.0.0/16 dev wg0
post-down ip link del $IFACE
EOF
cat > /etc/wireguard/wg0.conf << 'EOF'
[Interface]
PrivateKey =
[Peer]
Endpoint = 10.0.0.5:51820
PublicKey =
AllowedIPs = 10.1.0.5/32
EOF
Network manager config (alternative to manual config):
Connection name: vpn-rp4-4g
Interface name : wg0
Private key: XXX
Peers:
Public key : XXX
Allowed IPs: 10.1.0.5/32
Endpoint : 10.0.0.5:51820
IPv4 Settings:
Method : Manual
IP : 10.1.0.2
Netmask: 16
Gateway:
Re: Wireguard woes
El 28/9/25 a las 21:51, Peter Miller escribió: On Sat, Sep 27, 2025 at 1:10 PM beaker wrote: sudo ifconfig wg0 create sudo ifconfig wg0 inet 10.2.0.2/32 # /etc/wg/wg0 contains just the Proton PrivateKey sudo wgconfig wg0 set private-key /etc/wg/wg0 sudo wgconfig wg0 add peer Proton '' \ --allowed-ips=0.0.0.0/0,::/0 --endpoint= sudo ifconfig wg0 up fi I have wireguard working fine on NetBSD server and client with a similar looking config. No experience with Proton, but I don't see anything wrong here. My understanding is that changing the default route shouldn't be needed with wireguard and doing so via 'sudo route -f add default 10.2.0.2' consistently hangs the system.. try this # change default route to the Proton servers Peer address. I'm just guessing that it's 10.2.0.1 route change default 10.2.0.1 You might want to remove the DNS line too just while troubleshooting, or set it to 1.1.1.1 or something first. Hello I have the same problem trying to make a tunnel from https://connect.44net.cloud work using the built in NetBSD WireGuard. They provide a free IP address in 44.0.0.0 range for amateur radio registered hams and a tunnel. I see the tunnel ok and "connected" in green colour in the provider WEB admin page but if I ping my IP from outside it does not return. I am using a RaspberryPi Zero W with this config wgconfig script: #!/bin/sh set -x ifconfig wg0 create ifconfig wg0 inet 44.x.y.z/32 ifconfig wg0 inet6 a::b:c:d:f/128 wgconfig wg0 set private-key /etc/wg/wg0.priv wgconfig wg0 add peer A \ xzxzxzxzxzxzxzxcccxvzcxcxzc= \ --allowed-ips=0.0.0.0/0,::/0 \ --endpoint=44.r.s.1:44000 ifconfig wg0 up wg0 is up and running: netbsd-raspaZeroW# ifconfig wg0 wg0: flags=0x8041 mtu 1420 status: active inet6 a::b:e:f:8547%wg0/64 flags 0 scopeid 0x3 inet6 a::b:c:d:bae9%wg0/128 flags 0 scopeid 0x3 inet 44.x.y.z/32 flags 0 Sorry for destroying the IPs, hope not to difficult reading. I also could not replicate this provider settings, I di not found a NetBSD wg equivalent: DNS = 1.1.1.1,1.0.0.1 MTU = 1380 PersistentKeepalive = 20 netbsd-raspaZeroW# route -n show Routing tables Internet: DestinationGatewayFlagsRefs UseMtu Interface default192.168.1.1UGS -- - bwfm0 44.x.y.z wg0UHl -- - wg0 44.x.y.z/3244.x.y.z U -- - wg0 127/8 127.0.0.1 UGRS-- 33176 lo0 127.0.0.1 lo0UHl -- 33176 lo0 192.168.1/24 link#2 UC -- - bwfm0 192.168.1.230 link#2 UHl -- - lo0 192.168.1.203 d8:3a:dd:99:78:45 UHL -- - bwfm0 192.168.1.160:8d:26:32:34:23 UHL -- - bwfm0 Thanks. Ramiro.
Re: Wireguard woes
On Sat, Sep 27, 2025 at 1:10 PM beaker wrote: > sudo ifconfig wg0 create > sudo ifconfig wg0 inet 10.2.0.2/32 > # /etc/wg/wg0 contains just the Proton PrivateKey > sudo wgconfig wg0 set private-key /etc/wg/wg0 > sudo wgconfig wg0 add peer Proton '' \ > --allowed-ips=0.0.0.0/0,::/0 --endpoint= > sudo ifconfig wg0 up > fi I have wireguard working fine on NetBSD server and client with a similar looking config. No experience with Proton, but I don't see anything wrong here. > My understanding is that changing the default route shouldn't be needed with > wireguard and doing so via 'sudo route -f add default 10.2.0.2' consistently > hangs the system.. try this # change default route to the Proton servers Peer address. I'm just guessing that it's 10.2.0.1 route change default 10.2.0.1 You might want to remove the DNS line too just while troubleshooting, or set it to 1.1.1.1 or something first. -- Thanks Peter
Wireguard woes
I would like to try to setup a NetBSD 11 laptop for use with the ProtonVPN Wireguard service and I'm wondering if that is currently possible with the current state of NetBSD's Wireguard using wgconfig(8) ? For manual Wireguard Proton VPN setup one typically makes some selections in their web interface then downloads a config file [1]. I've done this and tried to follow the examples in the wg(4) manpage based on said config file contents (see below). So far, the best I can achieve is a momentary handshake and only if I add an IPv6 address to --allowed-ips argument string for wgconf(8). What has been done: 1) added "if_wg" to /etc/modules.conf to load at startup 2) made a setup script using proton.conf[1] as guide: #! /bin/sh -e # wg_create # if ( 2>1 ifconfig wg0 >/dev/null ) then echo 'wireguard interface already configured.' else echo 'setting up wireguard interface..' sleep 1 sudo ifconfig wg0 create sudo ifconfig wg0 inet 10.2.0.2/32 # /etc/wg/wg0 contains just the Proton PrivateKey sudo wgconfig wg0 set private-key /etc/wg/wg0 sudo wgconfig wg0 add peer Proton '' \ --allowed-ips=0.0.0.0/0,::/0 --endpoint= sudo ifconfig wg0 up fi --- After running wg_create and pinging some random address I can see that there was at least a momentary handshake made: $ ifconfig wg0 wg0: flags=0x8041 mtu 1420 status: active inet6 fe80::725a:b6ff:fe65:5d38%wg0/64 flags 0 scopeid 0x4 inet 10.2.0.2/32 flags 0 $ wgconfig wg0 interface: wg0 private-key: (hidden) listen-port: (none) peer: Proton public-key: *** endpoint: 212.***.**.***:5 preshared-key: (hidden) allowed-ips: 0.0.0.0/0 latest-handshake: Sat Sep 27 01:15:43 2025 However an IPv4 ping fails: $ ping -n 10.2.0.2 PING 10.2.0.2 (10.2.0.2): 56 data bytes 10.2.0.2 PING Statistics 15 packets transmitted, 0 packets received, 100.0% packet loss I can also see that a route gateway has been created: $ route -n show |head Routing tables Internet: DestinationGatewayFlagsRefs UseMtu Interface default192.168.1.1UG -- - urtwn0 10.2.0.2 wg0UHl -- - wg0 10.2.0.2/3210.2.0.2 U -- - wg0 127/8 127.0.0.1 UGRS-- 33624 lo0 127.0.0.1 lo0UHl -- 33624 lo0 192.168.1/24 link#2 UC -- - urtwn0 My understanding is that changing the default route shouldn't be needed with wireguard and doing so via 'sudo route -f add default 10.2.0.2' consistently hangs the system.. Am I missing something or is this sort of use just not achievable at this time? BTW, I tried installing the wireguard-tools package but this package really doesn't seem to be for NetBSD at all. -B -- refs: [1] # proton.conf [Interface] # Key for wg-proton # Bouncing = 1 # NetShield = 1 # Moderate NAT = off # VPN Accelerator = on PrivateKey = *** Address = 10.2.0.2/32 DNS = 10.2.0.1 [Peer] # US-ST#42 PublicKey = AllowedIPs = 0.0.0.0/0 Endpoint = 212.***.**.***:5
