El 28/1/26 a las 1:19, Greg Troxel escribió:
Ramiro Aceves <ea1abz%gmail.com@localhost> 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 wg0 UHl - - - wg0 44.27.132.76/32 44.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, the endpoint 44.27.227.1 via em0 (ethernet). Divide the internet addresses in two halfs and route to the wg0. I do not know, I am an complete ignorant.
root@freebsd-nuc8i7:/home/ramiro # netstat -rn Routing tables Internet: Destination Gateway Flags Netif Expire 0.0.0.0/1 link#3 US wg0 default 192.168.1.1 UGS em0 44.27.132.76 link#2 UH lo0 44.27.227.1 192.168.1.1 UGHS em0 127.0.0.1 link#2 UH lo0 128.0.0.0/1 link#3 US wg0 192.168.1.0/24 link#1 U em0 192.168.1.200 link#2 UHS lo0
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?
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.
You said things "work" in FreeBSD. Do the same diagnosing there.
Yes, I will do that. I only need more free time, this week is being a bit overloaded.
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?
I do not understand, sorry.
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.
I think that this overpasses me. I am going to repeat the tests this week end if family allows it ;-), trying to do them better to see if we reach something useful. If I do not succeed and someone with good understanding wants to debug this I can send the keys and is free to investigate. I will change the keys after all the debugging.
Another thing I have to test (with other amateur radio friends that have also asked for a 44Net address, they are making the setup but do not have it working permanently untill they configure their firewalls) is whether I can ping their 44Net addresses and they can ping mine.
Many thanks. Ramiro.