Big issues related to Firewall logging.
-
Two perhaps related serious issues
- Today I had to dig into a problem needing the firewall logging for that. I noticed that there was no firewall logging. It had stopped !!! (all ready for a couple of days)
After clearing the alarm log the logging did work again. Note that I have a lot of ram and disk space in my system.
- Perhaps related and very very annoying (complained already a couple of times) , is that pass rules without logging do behave like block rules with logging. Which is I keep saying that is really ridiculous.
And that issue is causing many thousands of alarms and perhaps it is reason of the problem mentioned above.
below an very often occurring example of the mentioned problem.
Note that I am running the latest plus version.
-
@louis2 #2 is not a problem per se…IGMP/options drops are logged now.
https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html#packets-with-ip-options
You can create a rule to match and not-log them.
-
@SteveITS said in Big issues related to Firewall logging.:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html#packets-with-ip-options
Steve,
I tried a lot but the behavoir is definitively not ok and in my opinion disgusting.
I tried to stop this logging adding extra rules in front of the rule generating the logging. Nothing stops it!
As you can see three rules:
- a rule to block IGMP with options set
- the same rule without options set
- the >>pass rule without Logging<< generating the logs .....
IMHO nothing justifies this behavoir !!
-
@louis2 in your screenshot both IGMP rules have “ Log packets that are handled by this rule” checked.
It should be protocol IPv4 IGMP, interface LAN, log unchecked, and that’s it.
-
Steve ... you overlooked something ....
It are not those rules which are causing the logging, it is the rule at the bottom which is causing the logging !!!
I now even add four rows above that rule trying to stop the logging. All those rules have logging on because I want to see it those rules are triggered.
They are not as you can also see from the counters
-
@louis2 please show a screen cap of the rule.
We created a not-log rule on all routers we manage. The behavior change was new in 24.03 or thereabouts.
-
-
@louis2 The IGMP one.
-
Below the rule with advance options set. The other one is identical without the advance options
-
I leave home for a couple of hours, will respond afterwords if required
-
@louis2 Try a Status/Filter Reload to ensure they're loading?
here are mine:
no advanced anything set:
-
Hum ... I did reboot the FW ..... which changed the behavior .... what should not be the case ....
The first rule in my 'rule-group' blocks the packet now
Also in the log a message from the 0.0.0.0 filter rule
not clear why sometimes that rule matches and sometimes notThe whole thing is bizar in multiple ways .....
note: alias MyIPV4network = '192.168.0.0/16'
-
I did a small modification in my rule group.
- A small change in the rule description and
- I reordered the rules so that the rule without iP-options comes before the rule with IP-options set.
Note that there are a couple of addresses:
source 0.0.0.0 destination 224.0.0.22
source 192.168.100.2 destination 224.0.0.22
source 192.168.100.1 destination 224.0.0.1192.168.100.1 = vlan gateway
224.0.0.22 = is used for the IGMPv3 protocol. This protocol is used by hosts to manage its multicast interests
224.0.0.1 = is a well-known multicast address reserved for the all-hosts group, meaning it addresses all devices that have joined the multicast group192.168.100.2 = address inside my VM-lan assigned to the VM-host. I do not know why it behaves like this, however for this moment (during this test) I leave it as it is.
-
Steve this pfSense behavoir is really really unacceptable !! :(
I try to block the logging with all possible means, to a certain extend that works however:
- I have to add all kind of rules which should not be there
- Rules are only working after a reboot, which makes it very very hard to understand what works and what not !!
( and that is of course also a bug !!) - Since recent I have problems with my media server using pimd which always have been working. And given the actual situation (rules required to stop logging and reboots needed to see the effect of them) it is not clear what is causing this.
So please fix it / have it fixed:
- not logging pass rules behaving as block rule for not related traffic
- rules which need a reboot before they become active
-
@louis2 said in Big issues related to Firewall logging.:
So please fix it / have it fixed:
not logging pass rules behaving as block rule for not related trafficWhat do you mean ?
Example - I list my first 3 WAN rules :
Ignore the first rule.
The second WAN rule is a pass rule, matching IPv4 UDP with destination port 1194 (and must come from the alias list called pfB_Europe_v4). This rule doesn't log.
If this rule doesn't match incoming traffic, it will not block that traffic. if it would, the third (and more) WAN firewall would not (= never) be parsed anymore.Btw : there is always a last, 'hidden' (not shown in the GUI) firewall rule any every interface that 'blocks everything'.
@louis2 said in Big issues related to Firewall logging.:
rules which need a reboot before they become active
No reboot needed. When a new list is created by the admin, (the GUI) the firewall rule set is reloaded.
Be ware that connections with an active state might need a 'reset'. If needed : Diagnostics > States > Reset States -
@louis2 said in Big issues related to Firewall logging.:
So please fix it / have it fixed
What exactly do you think other forum users can do here?
Your stated issue with rules needing a reboot is not normal behavior. If the filter reload I suggested shows no errors and a reboot is required (after you apply your changes) that screams it's a problem with open states/connections, as Gertjan suggested.
-
active state might need a 'reset'
I agree that ^connections with an active state might need a 'reset'^ (thanks for explaining the command for that, however I do not think that is the problem.Because the issue (logging) keeps going on after adding rules, and I assume that new logging entry's will not be generated for a state all ready active !! (am I wrong!?)
there is always a last, 'hidden' firewall rule
Yep, I know that is how it should be (blocking what is not allowed)
Note that I frequently add explicit blocking rules, for either things I want to see or explicitly block, of the other way around keep away from my own final logging blocking at the end.
As latest rule I frequently add my own blocking rule so that I can see what is blocked.The (example) rule showing the problem
The rule above is a PASS rule NOT a BLOCK rule
And it is NOT logging !!
And it is NOT related to IGMPAnd as you can see despite of that a hell of a lot IGMP messages are generated by that rule. Which is IMHO violating all named aspects above !!
What exactly do you think other forum users can do here?
Nothing! But Steve that sentence is for you as the coordinator here and representative of Netgate
-
@louis2 said in Big issues related to Firewall logging.:
as the coordinator here and representative of Netgate
I work for a Netgate partner but I have no direct relationship with Netgate or the forum management.
The (example) rule showing the problem
It looks like it doesn't have logging enabled...there should be an icon for that, by the green checkmark.
I have no idea why the "prevent logging" rules aren't working for your case as they do for routers I've set up.
-
@louis2 said in Big issues related to Firewall logging.:
[ . . . ] as the coordinator here and representative of Netgate
Netgate employees have an official "Netgate" forum badge next to their handles. See @jimp's profile, for example.
-
@louis2 said in Big issues related to Firewall logging.:
... of that a hell of a lot IGMP messages are generated by that rule
Overlooked that on.
That's a ... euh .. new ;) Since 24.0x or so. Suddenly, IGMP gets logged on rules that don't log.This forum talks (a lot) about it, an what you can do against it.
