Constant arpwatch bogon reports .... related to my own network !!??? (*strange andannoying!!*)
-
I am getting constant arpwatch message. Disturbing the view on more important alarms and filling the log.
However ....... what is even more ridiculous is ...... that they are related to an address inside my own network !!
So my first question is ^How is it possible that one of my own addresses is handled as 'bogon' !!!!!???
Second question 'how to get rid of it?Below some of the thousands of these equal messages!!
2025-06-04 19:07:14.000 pfSense 6 arpwatch arpwatch[42959]: bogon 192.168.10.3 1c:2a:a3:1e:42:4f
2025-06-04 19:06:14.000 pfSense 6 arpwatch arpwatch[42959]: bogon 192.168.10.3 1c:2a:a3:1e:42:4f
2025-06-04 19:05:14.000 pfSense 6 arpwatch arpwatch[42959]: bogon 192.168.10.3 1c:2a:a3:1e:42:4f
2025-06-04 19:04:13.000 pfSense 6 arpwatch arpwatch[42959]: bogon 192.168.10.3 1c:2a:a3:1e:42:4f
2025-06-04 19:03:14.000 pfSense 6 arpwatch arpwatch[42959]: bogon 192.168.10.3 1c:2a:a3:1e:42:4f
2025-06-04 19:02:14.000 pfSense 6 arpwatch arpwatch[42959]: bogon 192.168.10.3 1c:2a:a3:1e:42:4f
2025-06-04 19:01:14.000 pfSense 6 arpwatch arpwatch[42959]: bogon 192.168.10.3 1c:2a:a3:1e:42:4f
2025-06-04 19:00:14.000 pfSense 6 arpwatch arpwatch[42959]: bogon 192.168.10.3 1c:2a:a3:1e:42:4f -
@louis2 what version of pfsense are you on? I know @dennypage has been working on replacement package - the old arpwatch package had a lot of issues with it. Believe he said it was just easier to start from scratch ;) Not sure if has been implemented into the packages as of yet. Let me see if can dig up the thread.
edit: here is the thread I was thinking about
https://forum.netgate.com/topic/195717/arpwatch-not-downloading-vendor-id-s -
Latest beta pfSense+
25.03-BETA (amd64)
built on Thu May 15 16:15:00 CEST 2025
FreeBSD 15.0-CURRENT -
@louis2 you prob want to try out the Denny package - I don't believe it available in the packages yet - that might take a while.
But he linked to how you can install it.
edit:
As to bogon - you know all of rfc1918 space is by definition part of bogon..I believe in the old package you could turn those off - but part of the problem with packages, isn't didn't do what you thought an option should do ;)
-
I have no idea what the deny package is ......
but IMHO what happens is damn wrong ....Louis
-
@louis2 @dennypage has written a new package for arpwatch..
I linked to the thread that goes over it, etc.
see my edit above about the old package - yes it had/has issues.. Its not really usable if you ask me..
-
John, I am going to filter that strange alarm away in by GrayLog VM, what does not take away that there is a bug somewhere, which should be fixed.
Next to that ...... no idea how arpwatch is behaving / if it is futher on correctly behaving .... ????
I think .... / .... my feeling it is a FreeBSD issue, no idea it there is a ticket
-
@louis2 I thought I saw something in that thread where Denny mentions he filed something upstream with freebsd.
Here is the things with packages - who owns them. many have been written by others.. Denny nice enough to carry the touch forward - if someone gets a package into pfsense packages, doesn't mean netgate takes over maint and fixes to that package.
But the old version use to allow you to block bogon..
I haven't ran it in a long time - its too noisy, that one where 0.0.0.0 changes disable report, I am pretty sure that just doesn't work - but thought the disable bogon did.. Maybe something changed in 25.03? Do you have that set? And still seeing them?
If was me, I would forget this package and look to package Denny wrote.. If something isn't working - he would fix it normally pretty quick. He has other packages for pfsense that he maintains well.
-
@louis2 oh I looked a bit deeper - because I am no seeing any bogon messages after I fired it back up, with it no set to disable bogon
bogon The source ip address is not local to the local subnet.
That would seem to me - that your seeing source IP into an interface that is not on that 192.168.10 network?
Also that brought up same issue, but not thousands of them.,
https://forum.netgate.com/topic/157512/arpwatch-reports-bogons-frequently
I am going to try and force a bogon by putting machine on different IP then network its on.
Yeah that does it - a lot of them
Jun 4 16:57:49 arpwatch 55289 bogon 192.168.33.10 2:11:32:28:ef:98 Jun 4 16:57:48 arpwatch 55289 bogon 192.168.33.10 2:11:32:28:ef:98 Jun 4 16:57:47 arpwatch 55289 bogon 192.168.33.10 2:11:32:28:ef:98 Jun 4 16:57:46 arpwatch 55289 bogon 192.168.33.10 2:11:32:28:ef:98 Jun 4 16:57:45 arpwatch 55289 bogon 192.168.33.10 2:11:32:28:ef:98 Jun 4 16:57:44 arpwatch 55289 bogon 192.168.33.10 2:11:32:28:ef:98 Jun 4 16:57:43 arpwatch 55289 bogon 192.168.33.10 2:11:32:28:ef:98 Jun 4 16:57:42 arpwatch 55289 bogon 192.168.33.10 2:11:32:28:ef:98 Jun 4 16:57:41 arpwatch 55289 bogon 192.168.33.10 2:11:32:28:ef:98 Jun 4 16:57:41 arpwatch 55289 bogon 192.168.33.10 2:11:32:28:ef:98 Jun 4 16:57:40 arpwatch 55289 bogon 192.168.33.10 2:11:32:28:ef:98 Jun 4 16:57:39 arpwatch 55289 bogon 192.168.33.10 2:11:32:28:ef:98 Jun 4 16:57:37 arpwatch 55289 bogon 192.168.33.10 2:11:32:28:ef:98 Jun 4 16:57:36 arpwatch 55289 bogon 192.168.33.10 2:11:32:28:ef:98 Jun 4 16:57:35 arpwatch 55289 bogon 192.168.33.10 2:11:32:28:ef:98 Jun 4 16:57:34 arpwatch 55289 bogon 192.168.33.10 2:11:32:28:ef:98 Jun 4 16:57:33 arpwatch 55289 bogon 192.168.33.10 2:11:32:28:ef:98 Jun 4 16:57:33 arpwatch 55289 bogon 192.168.33.10 2:11:32:28:ef:98 Jun 4 16:57:32 arpwatch 55289 bogon 192.168.33.10 2:11:32:28:ef:98I set wrong IP on device - and bam!!!! let see if disable bogon stops those?
edit: ok telling it to disable bogon got rid of that flood, but did get notice of new station
Jun 4 16:59:28 arpwatch 23451 new station 192.168.33.10 2:11:32:28:ef:98
But the network its on is actually 192.168.3.0/24 I don't have a .33 network.. So if your being flooded, seems to me arpwatch is seeing some device traffic on the wrong interface for that source IP.
-
@johnpoz said in Constant arpwatch bogon reports .... related to my own network !!??? (*strange andannoying!!*):
I know @dennypage has been working on replacement package - the old arpwatch package had a lot of issues with it. Believe he said it was just easier to start from scratch ;) Not sure if has been implemented into the packages as of yet.
Yes, ANDwatch itself is merged in FreeBSD upstream, with most recent version here.
A pfSense ANDwatch package has been created, and is in the queue. The Redmine issue is here, and the PR is here.
For background, there are related forum threads here and here. And probably others that aren't coming quickly to mind.
Please note that the upper level pfSense package version in the first thread is a bit out of date. If you want to try it out, I recommend grabbing the pfSense package from the PR. The lower level package, ANDwatch 2.1, in that thread is current, or alternatively you can pull it from upstream FreeBSD directly.
-
I noticed that arpwatch as it is now is a package, I did install some where in the past. I removed it since it is causing thousands of 'bogon' messages.
Also note that in my case the messages were related to a Mokerlink switch its management IP. No idea why that did trigger arpwatch.
Bogon is of course not correct, but what else could have triggered arpwatch ???
-
@louis2 If it sees an IP that is not suppose to be on this network. So bogon..
If pfsense is seeing say 192.168.10.3 on network that is suppose to be say 192.168.20.0/24 then that is bogon to that network.
I duplicated what your seeing by just setting a devices IP to wrong IP for the network it was on - and then yup lots and lots of bogon log entries.
If your switches management IP was seen on an interface for a different network then yup arpwatch will log bogon.
A bogon is an IP that is not suppose to be on a network - ie rfc1918 should not be on the internet. IP ranges that have not been assigned to be on the internet yet are bogon. This list has gotten smaller since IPv4 space that has not been assigned yet has gotten smaller.
But if you see IP X on network Y - where X should not be there, that yes that could be considered bogon - because it shouldn't be there.
A better term might be martian - which is a packet that shows up , that would not be returned to the sender.. if some X ip shows up on an interface in network Y as the source - the return traffic would not come back to the sender, because return traffic wanting to go to this X ip would be routed to the X network, not the Y network.
-
@louis2 Arpwatch has been a package for years. ANDwatch, which replaces Arpwatch, is new.
-
OK good to know that also local addresses not belonging to the subnet are bogon. I did not know that!
I would have looked differently to the alarms if I had known.What does not take away that the messages I did saw where related to the switch its IP, so that looked completely OK!
I wonder if that address has been seem in multiple vlan's ... however the message is so limited, it does not give enough info! :(
What ever it should not happen. The weird behavoir is around a cheap Mokerlink switch. I am using Mokerlink 2.5/10G switches as 'room switches', since they are small and cheap and apart from this, seems to work OK.
-
@louis2 said in Constant arpwatch bogon reports .... related to my own network !!??? (*strange andannoying!!*):
cheap Mokerlink switch
do they actually support vlans? Since they have management IPs I would guess they should. But do they support the management vlan on a tagged vlan?
Yeah might be easier to know exactly what was going on if arpwatch listed what interface it saw this traffic on that it considers bogon because the network doesn't match the interface it was seen on.
-
Yep, I only use vlan's !!
The switch is connected to the upper layer switch via a trunk, all tagged.
Since I would like to understand the problem, I am going to install ANDwatch (as it becomes availailable) at least temporarily, hoping that that packages give more precise messages.
After reading the definition you gave for bogon's, I am starting to fear that the management IP of the cheap switch is showing up in multiple vlan's. Which is really bad of course ..
On the other hand, I an not the only one having this trouble, so not sure if the problem is the package or the switch.
-
@louis2 said
Since I would like to understand the problem, I am going to install ANDwatch (as it becomes availailable) at least temporarily, hoping that that packages give more precise messages.
After reading the definition you gave for bogon's, I am starting to fear that the management IP of the cheap switch is showing up in multiple vlan's. Which is really bad of course ..
Yes, ANDwatch will report what interface the IP address appears on. However, it does not offer any judgments about the IP address (bogon, etc.).
-
@louis2 said in Constant arpwatch bogon reports .... related to my own network !!??? (*strange andannoying!!*):
On the other hand, I an not the only one having this trouble, so not sure if the problem is the package or the switch.
I have not seen this exact problem before that I recall - mostly issues with dhcp being flagged as bogon, etc. Where the source IP is all zeros. Or if there was this issue reported, didn't recognize as this at the time.. where your seeing network A source traffic into network B.
For the package to report it - it has to be seen by the package.. And you shouldn't be seeing network A as source into network B. The only time you should see other network IPs into some network interface is if that network is a transit network.
Is your switch management IP a downstream network being routed over a transit/connector network?
If you had something like this, where some downstream router was routing over a transit into pfsense to be routed, then yeah pfsense seeing traffic sourced from say 192.168.2.x into its 172.16.0.1/30 interface would be normal and shouldn't be reported as bogon by arpwatch.
arpwatch should have a method of listing what source networks could be seen on an interface, so not to report such traffic as bogon without having to turn off reporting of bogon completely.
It is also possible that arpwatch is looking at traffic it shouldn't be to report that. If you have an physical interface say igb0 and then you have sub interfaces for vlans igb0.10 igb0.20 etc.. arpwatch shouldn't be reporting that traffic meant for igb0.20 for example with a tag of vlan ID being seen on igb0 which it would be but tagged shouldn't be reported as bogon.
-
@johnpoz said
arpwatch should have a method of listing what source networks could be seen on an interface, so not to report such traffic as bogon without having to turn off reporting of bogon completely.
It does, but it’s not exposed in the pfSense package. Also, it affects all of Arpwatch, instead of a single interface, so it wouldn’t be very useful in this case.
I recommend ANDwatch (obviously), which works on individual interfaces and should provide a clearer picture.
-
@dennypage I would recommend ANDwatch as well - and I haven't even given it a spin yet. I don't really use arpwatch any more - I stopped using it when there was an issue way back when - after it ran for a while it would lock up my pfsense.
When andwatch becomes integrated into the normal pfsense packages I will for sure give it a spin ;)
You might know - does arpwatch just listen on the parent interface in promiscuous mode and ignore tags? If so then yeah any other vlans on that parent interface could cause it to list bogons from your vlans that are tagged.
