El 28/1/26 a las 1:19, Greg Troxel escribió:
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.
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.
