How to silence logging for packets dropped due to IP options?
-
Re: [Pass firewall rules are logged blocking packets](even after deleting the rule)
I'm glad I found this previous thread about the cause of what's going on with the logs, but I've got a bit of the opposite problem - I'm now dropping these packets early in the ruleset, but they're still getting through to the default allow rule and getting dropped/logged due to the options.
My question is this: what's the best way to drop these packets silently? I don't want to allow them through (these are not routable, but I don't want to blanket allow options and let routable packets with options through), and I don't want to log them (these IGMP/multicast drops are just log spam). I had hoped simply dropping them early in the rule list was enough, but that doesn't seem to be the case. I can't drop multicast at the edge within the network because people are using it legitimately, but I don't need the firewall to log it all the time either.
-
@beatvjiking You can add a rule on LAN that has logging disabled. We used IGMP as the protocol, as opposed to by IP:
-
@SteveITS Thanks, but we've got that rule in place already (see 2nd rule in the ruleset). I actually added the rule above it blocking destination 224.0.0.0/24 since I figured it was a glitch before I started searching the internet for solutions. Both these rules are definitely dropping packets, at least according to their counters, but... Packets are still getting logged.
-
@beatvjiking D'oh! I read them in order and stopped at the first, like one should with firewall rules. ;)
I double checked, and found that we'd set up the block only on LAN and not our LAB interface. The latter was logging the IGMP drops, and when I copied the rule there, it stopped.
Open states?
What if you create it as IPv4 IGMP, without IPv6? -
@SteveITS No worries, that's how it's supposed to work :)
I tried creating it as an IPv4 IGMP rule initially, in case someone was doing something weird, but even after switching it back to IPv4 only it's still logging. I also did go in and do a manual filter reload after the change, just in case.
Good call on the open states question, but the mystery deepens - I killed all the IGMP states that were open, but... then new ones opened. Considering these are supposed to be dropped by a total of three rules, each for a different reason, how are these states getting opened in the first place?
-
@SteveITS also, this is part of a failover cluster, but I did kill the states with the other firewall mid-reboot to ensure I was really, truly killing the states, and they reappeared.
-
@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?
-
@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?
