El 26/1/26 a las 14:41, Greg Troxel escribió:
Ramiro Aceves <[email protected]> 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.
