IGMP IPV4 endless log-messages / rules not working :(
-
@louis2 said in IGMP IPV4 endless log-messages / rules not working :(:
"more more than bizar" !!
I know, I know.
I'm like you : wanted to stop my logs being filled up with 'useless' info.
This trick did it. -
Gertjan, in my personal vision, I am just as concerned about threats from inside my network as for threats coming from the internet.
So my rule sets are very strict also for traffic leaving the network!
- for security reasons first
- blocking the option that things are collected from the internet for bad, commercial or good reasons ....
- for privacy reasons
So I would never ever define a rule like "every thing outgoing allowed.
Next to that the rules allow all subsets to freely communicate with each other. No way !! Never !!My opinion of course!
-
@louis2 said in IGMP IPV4 endless log-messages / rules not working :(:
It does not work here also with IP-options set! Let me start with that.
Please post screen shots of your rules.
-
@louis2 said in IGMP IPV4 endless log-messages / rules not working :(:
IP-options is necessary for a match, than the rule without IP-options, should simply not match should not do any thing !!
To be clear, IP options are not matchable like protocols, addresses, ports, etc.
-
I think I fixed it. The following way:
-
I did add as first rule for the vlan:
-
I did reset the states via Diagnostics / States / Rest States
Just defining the rule, was not enough !!!
-
-
@louis2 Glad you got it working. Thank you for letting me know that you had to perform Reset States. That may help others.
-
@louis2 said in IGMP IPV4 endless log-messages / rules not working :(:
So I would never ever define a rule like "every thing outgoing allowed.
Next to that the rules allow all subsets to freely communicate with each other. No way !! Never !!I fully agree with that.
I've kept the default Netgate LAN firewall rules because I have the luxury of totally trusting all my LAN devices, I don't need to block something from going outside.
Beyond the devices, I can also trust the users that uses these devices. I'm lucky, probably.Closing all destination ports, leaving open only port 53,80,443,110,143,995,992, 993, 143 doesn't give me more security, as 99% of all threads are downloaded by users over 443 (a web browser using https) or by mail, for example IMAP SSL, port 993, a mail client.
My LAN is my trusted network, and they could access to my other, less trusted networks, like a captive portal, or my server network. These networks can not access my trusted LAN.
My non trusted networks have devices I need to admin, like access points etc. I can access these from my LAN. -
@Gertjan In this case, it's a bit more than just passing ports. Allowing IP Options on a pass all rule opens your firewall to these options as well. IMO, you want to be very specific in the circumstance that you allow IP options.
I would have a preference to silently dropping all packets with IP options, including IGMP, rather than allowing all IP packets with options.
-
@dennypage said in IGMP IPV4 endless log-messages / rules not working :(:
you want to be very specific in the circumstance that you allow IP options.
I wanted to clean my logs. I've chosen the fast way out - not necessarily the best one.
-
Hello from 2025.
On my 6100 running 25.07, I'm noticing these IGMP packets getting blocked (they were probably there all along but since I'm troubleshooting multicast issues I happened to be digging around and saw them)
I haven't collected packet dumps of this traffic yet, but based on the LAN IPs of the 2 hosts below, I identify them as my main Mac workstation and a Windows 11 VM, so it's not platform-specific.
That "inet access" rule is the very bottom of my ruleset on the LAN interface, and looks like this
What's the best course of action here?
- Make a separate rule just above it that allows ip-options just for protocol IGMP?
- Just ignore them?
- Something else?
Do I need IGMP Proxy enabled for any reason?
edit: I decided to go with a rule to pass IGMP on the LAN for now. It's matching...
Thinking about this, I'm not sure that this actually does anything other than tidy the logs. Once the IGMP packet hits my pfSense, I don't think it "goes" anywhere useful.
-
@luckman212 I have this in Firewall / Local / Rules:
There really isn't much reason to suppress IGMP packets in the local network.
-
@dennypage while I agree - pfsense isn't going to do anything with it.
-
@johnpoz said in IGMP IPV4 endless log-messages / rules not working :(:
while I agree - pfsense isn't going to do anything with it.
Depends upon what packages you are using I guess. From a switch POV, IGMP is pertinent for Avahi, mDNS-Bridge, mcast-bridge (not yet released), IGMP proxy and pimd. Perhaps others that I am not aware of.
IGMP is a goodness that prevents unnecessary multicast packet flooding. In my view, it should always be enabled if available.
-
"Firewall / Local / Rules"
I assume Local is an interface group you created? Good idea. I just changed mine:
I read the Wikipedia article on IGMP, and according to my interpretation, it's an IPv4-only protocol. So there shouldn't be a need to allow IPv6 there (saw v4+v6 in your screenshot)
In any case, I agree with @johnpoz that this is tilting at windmills.
-
@luckman212 said in IGMP IPV4 endless log-messages / rules not working :(:
I assume Local is an interface group you created?
Yes, sorry I didn't point that out. Yes, I use a "Local" group for controlling a bunch of stuff such as ICMP, IGMP, DNS, NTP, etc.
Btw, yes you are correct IGMP is only used for IPv4. It's a habit I guess (and a poor one at that) that I casually choose IPv4/IPv6. For IPv6, ICMP/MLD is what is actually used, but I believe a rule for this is not necessary because the MLD packets do not have the router alert bit set (at least on my Cisco switches, YMMV).
