Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes

●To: Greg Troxel <gdt%lexort.com@localhost> ●Subject: Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes ●From: Ramiro Aceves <ea1abz%gmail.com@localhost> ●Date: Tue, 27 Jan 2026 18:56:56 +0100



El 26/1/26 a las 14:41, Greg Troxel escribió:

Ramiro Aceves <ea1abz%gmail.com@localhost> 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:

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




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<UP,HOST,DONE,LOCAL>

recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 0 0


netbsd-raspaZeroW# route get 44.27.227.1 (the WireGuard endpoint address)
   route to: 44.27.227.1
destination: default
       mask: default
    gateway: liveboxfibra
 local addr: 192.168.1.230
  interface: bwfm0
      flags: 0x843<UP,GATEWAY,DONE,STATIC>

recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 0 0



Everything within the experiment was using:

netbsd-raspaZeroW# sysctl -w net.inet.ip.forwarding=0
net.inet.ip.forwarding: 0 -> 0

I do not see any difference using sysctl

netbsd-raspaZeroW# sysctl -w net.inet.ip.forwarding=1
net.inet.ip.forwarding: 0 -> 1


This is the tcpdump session captured packets pinging from outside and
net.inet.ip.forwarding=1

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:27:55.618088 IP 208.pool90-167-219.static.orange.es > 44.27.132.76: ICMP echo request, id 35361, seq 1, length 64 18:27:56.652034 IP 208.pool90-167-219.static.orange.es > 44.27.132.76: ICMP echo request, id 35361, seq 2, length 64


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:27:55.618608 IP 44.27.132.76 > 208.pool90-167-219.static.orange.es: ICMP echo reply, id 35361, seq 1, length 64 18:27:56.652544 IP 44.27.132.76 > 208.pool90-167-219.static.orange.es: ICMP echo reply, id 35361, seq 2, length 64



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#

netbsd-raspaZeroW# wgconfig wg0
interface: wg0
 private-key: (hidden)
 listen-port: (none)
 peer: A
  public-key: asdfgasdfg
  endpoint: 44.27.227.1:44000
  preshared-key: (hidden)
  allowed-ips: 0.0.0.0/0,::/0
  latest-handshake: Tue Jan 27 18:27:32 2026
netbsd-raspaZeroW#


This is dmesg output with net.wg.debug = 1 when it is "sleeping"


[ 180269.488308] wg_overudp_cb: type=4
[ 180269.488308] wg_handle_msg_data: mlen=80, encrypted_len=64
[ 180269.488308] wg_handle_msg_data: outsize=48

[ 180269.488308] wg_update_endpoint_if_necessary: old=inet: 44.27.227.1:44000, new=inet: 44.27.227.1:44000

[ 180269.488308] wg_validate_inner_packet: af=2
[ 180269.488308] wg_pick_peer_by_sa: sa=inet: 87.121.84.88

[ 180269.488308] wg_handle_msg_data: time_uptime32=180269 wgs_time_last_data_sent=180264 [ 180395.860645] wg_schedule_session_dtor_timer: scheduling session dtor in 180 secs

[ 180395.860645] wg_schedule_peer_task: tasks=0, task=32

[ 180395.860645] wg_task_destroy_prev_session: destroying current session 180 sec old [ 180395.860645] wg_destroy_session: session[L=4a965566 R=75892b5d] -> WGS_STATE_UNKNOWN



When the "link" resurrects it makes a new handshake:



[ 181667.647064] wg_pick_peer_by_sa: sa=inet: 44.27.132.76
[ 181667.647064] wg_schedule_peer_task: tasks=0, task=1

[ 181667.647064] wg_send_handshake_msg_init: session[L=d359e5eb R=(unknown)] -> WGS_STATE_INIT_ACTIVE

[ 181667.657090] wg_fill_msg_init: wg_fill_msg_init: sender=d359e5eb
[ 181667.697140] wg_overudp_cb: type=2
[ 181667.697140] wg_handle_msg_resp: receiver=226b2c03

[ 181667.697140] wg_update_endpoint_if_necessary: old=inet: 44.27.227.1:44000, new=inet: 44.27.227.1:44000 [ 181667.697140] wg_schedule_session_dtor_timer: scheduling session dtor in 180 secs [ 181667.697140] wg_handle_msg_resp: session[L=d359e5eb R=226b2c03]: calculate keys as initiator [ 181667.697140] wg_handle_msg_resp: session[L=d359e5eb R=226b2c03 -> WGS_STATE_ESTABLISHED

[ 181667.697140] wg_send_data_msg: inner=84, padded=96, encrypted_len=112
[ 181667.697140] wg_fill_msg_data: counter=0
[ 181667.727190] wg_overudp_cb: type=4
[ 181667.727190] wg_handle_msg_data: mlen=80, encrypted_len=64


Regards.
Ramiro.

●Follow-Ups: ●Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes ●From: Greg Troxel ●References: ●Wireguard woes ●From: beaker ●Re: Wireguard woes ●From: Peter Miller ●Re: Wireguard woes ●From: Ramiro Aceves ●Re: Wireguard woes ●From: Sad Clouds ●Re: Wireguard woes ●From: Ramiro Aceves ●Re: Wireguard woes ●From: Martin Husemann ●Re: Wireguard woes ●From: Ramiro Aceves ●Re: Wireguard woes ●From: Ramiro Aceves ●Re: Wireguard woes ●From: Martin Husemann ●Re: Wireguard woes ●From: Ramiro Aceves ●WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes ●From: Ramiro Aceves ●Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes ●From: Sad Clouds ●Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes ●From: Ramiro Aceves ●Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes ●From: Greg Troxel

●Prev by Date: missing function prototypes for orcmd() and orcmd_af()? ●Next by Date: Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes ●Previous by Thread: Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes ●Next by Thread: Re: WireGuard + /32 tunnel endpoint: incoming connections unreachable on NetBSD was: Wireguard woes ●Indexes: ● reverse Date ● reverse Thread ● Old Index Home | Main Index | Thread Index | Old Index