Big issues related to Firewall logging.
-
@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.
