Constant arpwatch bogon reports .... related to my own network !!??? (*strange andannoying!!*)
-
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.
-
@johnpoz said:
@dennypage I would recommend ANDwatch as well - and I haven't even given it a spin yet.
When andwatch becomes integrated into the normal pfsense packages I will for sure give it a spin ;)
I hope you’ll give it a go. Btw, if you don’t want to trust my build of the core, you can just install the package from upstream FreeBSD. The pfSense package itself (php code) is easily inspectable.
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.
I’d have to recheck code, which I can’t do right now, but I believe Arpwatch listens on whatever interface(s) you specify. If you specifiy a parent interface then that’s what it will use. Not sure if you can spec a parent interface with pfSense however, unless you make the mistake of mixing tagged and untagged on a single interface…
-
@dennypage oh I will for sure give it a spin - and completely trust your coding.. But I normally don't install stuff that is not from the pfsense repository - once it shows up there I will be playing with it for sure.
"unless you make the mistake of mixing tagged and untagged on a single interface…"
Not sure what call that a mistake - it is a valid configuration. I have an interface that has a native network on it, and then vlans on it as well. But yeah some people are if vlans on interface, then no untagged.. But it is a valid configuration - you just need to know what your doing ;) or yeah you could mess it up.
-
@johnpoz said:
"unless you make the mistake of mixing tagged and untagged on a single interface…"
Not sure what call that a mistake - it is a valid configuration. I have an interface that has a native network on it, and then vlans on it as well. But yeah some people are if vlans on interface, then no untagged.. But it is a valid configuration - you just need to know what you’re doing ;) or yeah you could mess it up.
True. However…
While mixing tagged and untagged packets on an interface is a valid configuration for pfSense, and most/all switches, I would generally call it a mistake for most folk. Mixing tagged and untagged on a single port requires a good deal of attention to detail, and has a high cost of failure. There is good opportunity for confusion, particularly with add ons such as Arpwatch, Avahi, etc.
YMMV
-
@dennypage your not wrong in that you have to understand what your doing or sure you could mess it up.. Maybe that is what is causing his flood of bogons..
But running an untagged native vlan on an interface (single network) while also having tag is valid configuration. If something like arpwatch can't run like that - then that is a problem with arpwatch. Not with configuration of native and tagged vlans on the same physical interface.
Shoot many devices would actually require that sort of connection. Many cheap smart switches do not allow you to put the management IP on a tagged vlan. Unifi not that long ago did not support management on a tagged vlan.
So if you kept tagged off an interface for management - you would need to leverage another interface for your tagged vlan traffic.
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.11 | Lab VMs 2.8, 24.11
