Ramiro Aceves <[email protected]> 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: > 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 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 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 The next question is what prefix is supposed to be reachable via wg? > 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 make sense because you are just being a host. > > 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 so same. > 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 allowed is the entire internet.
