How to silence logging for packets dropped due to IP options?

johnpoz

@beatvjiking I can not duplicate this... I don't normally have any igmp traffic on my network... But I generated some just to test.

So as you can see, it was logging traffic I generated..

I then created firewall rule not to log, and nothing more seen in my logs, but via packet capture I do see my traffic hitting my lan interface.

You sure your rules are being applied, you mention ha cluster.. Sure the rules are syncing to whatever actual interface the traffic is hitting your cluster?

SteveITS

@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)

beatvjiking

@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?

johnpoz

@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.

beatvjiking

@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.

beatvjiking

@johnpoz looks like the secondary has the same issue, and the weird rule ID matches. Whatever it is, it's on both units.

beatvjiking

@beatvjiking I tried adding floating rules to see if that would fix the issue... nope.

Logs still pouring in.

beatvjiking

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 :)

SteveITS

@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

beatvjiking

@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.

johnpoz

@beatvjiking

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

beatvjiking

@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.

johnpoz

@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?

beatvjiking

@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?

johnpoz

@beatvjiking seems something like that yeah.

ex1580

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.

SteveITS

@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

ex1580

@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.

SteveITS

@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.

johnpoz

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.