Why bogon packets?

pslpsl · 21 June 2023 21:58

Continuing the discussion from Feature Request: Arpwatch add-on:

Article explaining arpwatch.
Video at YT, Arpwatch in pfSense, nice!

I think that author missed importance of file /var/lib/arpwatch/arp.dat, it is database of all MAC addresses ever visiting your network. My database had data for about 10 years. Format is like this:

# head -3 /var/lib/arpwatch/arp.dat
ec:b1:d7:42:af:6e	192.168.222.116	1687383245	elite	eth0
90:1b:0e:1d:a8:83	192.168.222.1	1687383225	ipfire	eth0
d8:50:e6:2f:a2:56	192.168.222.119	1687382381	vivo	eth0

Other interesting feature is that it can detect “bogon” hosts in the network, like this one (/var/logs/syslog):

Jun 21 21:16:29 c4 arpwatch: new station 192.168.222.1 90:1b:0e:1d:a8:83 eth0
Jun 21 21:19:36 c4 arpwatch: new station 192.168.222.119 d8:50:e6:2f:a2:56 eth0
Jun 21 21:30:08 c4 arpwatch: bogon 213.28.29.235 90:1b:0e:1d:a8:83 eth0
Jun 21 21:45:08 c4 arpwatch: bogon 213.28.29.235 90:1b:0e:1d:a8:83 eth0
Jun 21 22:15:09 c4 arpwatch: message repeated 2 times: [ bogon 213.28.29.235 90:1b:0e:1d:a8:83 eth0]
Jun 21 22:30:09 c4 arpwatch: bogon 213.28.29.235 90:1b:0e:1d:a8:83 eth0

I am not sure why I see IP address 213.28.29.235 in my local network; that is IP address of my RED interface and MAC address is from ipfire gateway, so it looks like some problem with “ipfire” gateway, such packets should not be here…

I found a way to start arpwatch on Debian server. I ignore systemd configuration and I started it manually with “arpwatch -i eth0”; If file /var/lib/arpwatch/arp.dat doesn’t exists, it has to be created with touch /var/lib/arpwatch/arp.dat. This is just basic setup, no email alarms, just monitor network, report to syslog and update arp.dat file…

UPDATE. bogon packets I capture are ARP packets sent from ipfire to find “nas.home” that has IP address 192.168.222.22; this computer is down but it is configured in “wio” extension (who is online). I captured several packets with tcpdump and I see that four ARP queries were sent with interval 1 second and those had correct source IP address 192.168.222.1; after that one more ARP query is sent and this one has source IP address from RED, that is not expected. This happens every 15 minutes (refresh interval configured in WIO service configuration). I assume this is a bug in some Linux networking process responsible for ARP but it could be a feature, I am not sure. What about firewall rules at IPfire, shouldn’t be these packets captured and eliminated??

Screenshot from Wireshark, packets captured in GREEN network…

jon · 22 June 2023 00:05

This is what I see for 213.28.29.235:

I don’t know why it is on the local network… may a firewall rule is open instead of closed? (wild guess)

EDIT:
It is attached to a Fujitsu Technology device. Maybe a scanner?

pslpsl · 22 June 2023 00:14

Fujitsu is my IPfire gateway. Address 213.28.29.235 is not my real IP address, I “modified” it for this public post. Anyway, I see that IP address from RED interface is sent to local network and that is ARP request for local computer that is down; I updated my previous post. Troublemaker is IPfire, it sends a bogon packet every 15 minutes; the only problem of that bogon packet is source IP address, it should be GREEN but it is RED…

jon · 22 June 2023 02:22

I’m lost… I cannot understand what the issue is.

The IPFire device won’t send a bogon packet. Maybe this is related to the WIO? If you have the IPFire pakfire WIO add-on installed, can you post a screenshot the WIO WebGUI page table?

It looks like this:

pslpsl · 22 June 2023 06:16

I believe that troublemaker is Linux kernel. Some information

~~WIO screenshot~~, nas.home is offline and Linux cannot find its MAC address so it sends ARP requests but receives no answer so it tries different source IP address…

~~WIO & ARP screenshot~~ “nas.home” related to bogon packet is not in the ARP table (it is down, it has no IP address; well, it is not down but that is another story…). Only budgie.home is on both screenshots.

jon · 22 June 2023 14:45

Petr,

I see you have four different topics going at one time. And all are active.

my best advice is not to try NOT solving all four at the same time. This becomes very confusing for both of us.

Pick one to solve. Maybe the DNS & DHCP, trouble first since that seems like the most important to me.

Is the IPFire system hosted at Amazon? If it is, please let the other volunteers know.

Also, please post your images / screenshots on the IPFire site and not a remote site. The Upload button will help grab your pictures.

pslpsl · 22 June 2023 16:47

My IPfire is not hosted at Amazon but I have some advanced experience with AWS… Amazon sells many nice gadgets, like tablets, media boxes, eBook readers, devices with Alexa, IoT devices, etc, that is what you see in the screenshot, just clients served by IPfire. Amazon sells nice hardware, good hardware for money, reliable, LTS support… My IPfire runs on bare metal, Fujitsu Futro S900 was designed as thin client (office mini PC) but was converted to internet gateway with IPfire…

Issue with DHCP & DNS is high priority for me too and as I try to solve it I found some other issues too…

jon · 22 June 2023 18:48

so is the .home domain your local domain for your network?

or is it connecting to something outside your network?

EDIT: You may want to try (as a test) to disable WIO or disable each entry. And then see if that makes the bogon messages disappear.

Once you able to get other things working (the other active topics) then turn on the WIO items.

pslpsl · 22 June 2023 22:20

home is my local domain, it is served by IPfire, IPfire is local DNS master for .home domain, DHCP server announces .home domain to clients. “home” is not public domain, it is on some blacklist with domains like “lan”, “corp” and others article, RFC6762 And I already know about home.arpa

OK, I can disable test for “nas.home” in WIO and I bet it will stop those bogon packets… There is clear relations between these. WIO triggers search for “nas.home” every 15 minutes and Linux kernel tries to find MAC address for IP address 192.168.222.22 but it fails… This should be easy to replicate, just define some random hostname to host list, assign it IP address that is not used by real device and watch for ARP packets in LAN…

UPDATE: I confirm then when I disable host “nas.home” in WIO then I cannot see bogon packets in LAN. When I add new host to WIO, host with IP address 192.168.222.66 (no such device in LAN), I see bogon packets. This was “expected”. Then I tried to create bogon packets manually, I ping IP address 192.168.222.66 from IPfire box but no bogon was created. I tried similar action with arpping, I tried to replicate situation that was captured by tcpdump but no bogon packet was created. This was not expected. The key question is how WIO creates bogon packets…