How to silence logging for packets dropped due to IP options?
-
@beatvjiking said in How to silence logging for packets dropped due to IP options?:
manual filter reload
...and no errors there?
https://docs.netgate.com/pfsense/en/latest/troubleshooting/firewall.html#new-rules-are-not-applied(I mean you didn't say there were, but thought I'd ask)
-
@johnpoz I did doublecheck, and the rules are syncing to the interface that hits the cluster - it's the LAN interface on each, and the rules are in the LAN set.
@SteveITS no errors on filter reload, although after rebooting both cluster nodes, the rule ID got renumbered and had an @ added before it - and now I can't filter on or against that ID:
Looking up above, that default LAN allow rule was 100000101. I hadn't made a change. Not sure where that's coming from... Could this be symptomatic of a different issue, or is it just a cosmetic thing?
-
@beatvjiking the default lan rule should always have that same ID.. you got something going on.
Notice in my log, its the same 101 rule ID.
-
@johnpoz any tips on how to troubleshoot that? I pulled a backup and the XML file shows it as 101 still. I'm not seeing any weird formatting or other red flags in the backup, and the filesystem on these units is ZFS so filesystem/file damage seem quite unlikely.
-
@johnpoz looks like the secondary has the same issue, and the weird rule ID matches. Whatever it is, it's on both units.
-
@beatvjiking I tried adding floating rules to see if that would fix the issue... nope.
Logs still pouring in.
-
So I tried some rules in deployments beyond this one, and they seem to work. Specifically, I set up floating rules that block IGMP any>any and configured quick match. In this environment, they didn't work, but everywhere else, they seem to, so it's gotta be something on these machines that's screwing things up.
Thanks @johnpoz and @SteveITS for your help and suggestions. If anyone has ideas on how to find the source of the config issue I'm all ears, I'd rather not rebuild these from bare metal if I can avoid it :)
-
@beatvjiking You mentioned doing the filter reload, but that didn't show an error?
Is the rule shown in /tmp/rules.debug per:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/firewall.html#ruleset-failing-to-load -
@SteveITS the rule is shown there, and there are no errors thrown by the filter reload.
block quick inet proto igmp from any to any ridentifier 1721162300 label "USER_RULE: Silent IGMP drop" label "id:1721162300" block quick inet from any to 224.0.0.0/24 ridentifier 1721162354 label "USER_RULE: Silent local multicast drop" label "id:1721162354"Interestingly, the first 1000000101 rule isn't the default allow. It's:
# block IPv4 link-local. Per RFC 3927, link local "MUST NOT" be forwarded by a routing device, # and clients "MUST NOT" send such packets to a router. FreeBSD won't route 169.254./16, but # route-to can override that, causing problems such as in redmine #2073 block in quick from 169.254.0.0/16 to any ridentifier 1000000101 label "Block IPv4 link-local"Another point of interest:
pass in quick on $LAN inet from $LAN__NETWORK to any ridentifier 0100000101 keep state ( max-src-states 8192 ) label "USER_RULE: Default allow LAN to any rule" label "id:0100000101"Where the labeling doesn't align with the logs. I did try clearing the logs, and the mislabeling persists.
-
hmmm
# and clients "MUST NOT" send such packets to a router. FreeBSD won't route 169.254./16, but block in quick from 169.254.0.0/16 to any ridentifier 1000000101 label "Block IPv4 link-local" block in quick from any to 169.254.0.0/16 ridentifier 1000000102 label "Block IPv4 link-local"pass in quick on $LAN inet from $LAN__NETWORK to any ridentifier 0100000101 keep state label "USER_RULE: Default allow LAN to any rule" label "id:0100000101"The rules seem fine to me.. notice the 169.254 rules are 100, where the default lan is 010
-
@johnpoz ah yes, I missed that... looked right too quickly :) But yeah, as far as I can tell, everything seems okay. I exported a config backup and scanned the XML by eye and didn't see anything that seemed amiss. I'm not sure why the logging subsystem is identifying the rule as "(@4294967295)," let alone why the blocks keep getting logged. There's no item 4294967295 in the rules.debug file.
-
@beatvjiking I recall something in the past with that number I think..Are you running pfblocker with auto rules? I will have to search but pretty sure there was some other thread(s) where that ID came up in the discussion.
Your not running UPnP are you?
-
@johnpoz No pfblocker or UPnP. We have one URL alias rule that pulls in the emerging threats list and quickdrops anything bound to those IPs, but we also have that same rule in other locations that don't have this problem.
Come to think of it, (@4294967295) would indicate an overflow in a 32-bit value, right?
-
@beatvjiking seems something like that yeah.
-
Thanks for posting this! I was seeing some IGMP packets at one of my clients sites and created a rule to suppress the logging. Then I came here to see if anyone else was seeing this. I still think it's odd that a rule with logging tuned off can still log. Anyway, problem solved.
-
@ex1580 said in How to silence logging for packets dropped due to IP options?:
still think it's odd that a rule with logging tuned off can still log.
It's a "feature" added in 24.03 I believe.
https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html#packets-with-ip-options -
@SteveITS said in How to silence logging for packets dropped due to IP options?:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html#packets-with-ip-options
Thanks for the link Steve! I normally expect a packet that doesn't match an allow rule to be passed on to the next rule. I suppose in this instance it "kinda" matches (source/destination match but the IP Option is not allowed).
I have not come across a reason to need to allow IP Options at the firewall on any of my networks so I guess the rule to block those packets will end up in my standard configuration less the firewall log get filled with garbage.
-
@ex1580 I suppose, if it didn't match the allow, it would fall through to the default block rule which could also be confusing because one might expect it to match the allow rule. Not logging a block might also be confusing. Adding a block rule to every interface on every router by default is probably also not great. I would guess, there wasn't a great solution.
We have also started adding the rule as we upgrade client routers.
-
What sort of devices are generating this traffic? I had to craft specific igmp traffic to see this rule kick in.. But yeah with @SteveITS not sure what other sort of way to do this that would be better.
Blocking the traffic that has IP options set unless specifically allowed is a good thing.. But how to show that in the log that wouldn't confuse the typical user is the hard part.
The only thing that might be an improvement.. Is a check box in the logging setup, you know where you can disable logging of say the default deny, rfc and bogon rules, etc. They could add say add a don't log block of igmp that has IP options set, or something like that.
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.03 | Lab VMs 2.7.2, 24.03 -
@johnpoz said in How to silence logging for packets dropped due to IP options?:
What sort of devices are generating this traffic?
I have not tried to track it down, tbh, but it's on every network so far, that is on 24.03.
A checkbox would be handy. I think, it would always need to be the last rule? And/or hidden. And/or made clear it doesn't affect logging of not-the-last-rule rules.
The down side to all this is, the constant logging on eMMC storage which has a more limited write life than SSD. (which is why we always turn off the default block logging)
