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