["solved"] IGMP w options blocked on lo0 interface, filling the log, can't be silenced

pst

(I'll start this in the 25.03-beta sub, but it might be more generic)

I moved pfblockerNG DNSBL web server interface from the LAN interface to the default Localhost, so the pfblocker VIPs now resides on lo0. This change, however, caused the firewall log to fill up with blocked IGMPs (ip-options)

I tried solving it by adding a floating rule to silence them, but it had no effect

While the above used direction 'any', changing it to 'out' did not help. The rules relating to pfblockerNG is currently

[25.03-BETA][admin@pfsense.local.lan]/root: grep pfB_DNSBL_VIPs /tmp/rules.debug
table <pfB_DNSBL_VIPs> {   10.10.10.1  ::10.10.10.1 }
pfB_DNSBL_VIPs = "<pfB_DNSBL_VIPs>"
block return  out  quick inet from $pfB_DNSBL_VIPs to <_multicast46_> ridentifier 1749386266 label "USER_RULE" label "id:1749386266"
block return  out  quick inet6 from $pfB_DNSBL_VIPs to <_multicast46_> ridentifier 1749386266 label "USER_RULE" label "id:1749386266"
pass  quick  on {  mvneta1  mvneta1.10  mvneta1.30  mvneta1.50  mvneta1.60  mvneta1.80  mvneta1.90  mvneta1.120  } inet proto icmp  from any to $pfB_DNSBL_VIPs icmp-type echoreq ridentifier 1770001239 keep state label "USER_RULE: pfB_DNSBL_Ping auto rule" label "id:1770001239"
pass  quick  on {  mvneta1  mvneta1.10  mvneta1.30  mvneta1.50  mvneta1.60  mvneta1.80  mvneta1.90  mvneta1.120  } inet6 proto ipv6-icmp  from any to $pfB_DNSBL_VIPs icmp6-type echoreq ridentifier 1770001239 keep state label "USER_RULE: pfB_DNSBL_Ping auto rule" label "id:1770001239"
pass  quick  on {  mvneta1  mvneta1.10  mvneta1.30  mvneta1.50  mvneta1.60  mvneta1.80  mvneta1.90  mvneta1.120  } inet proto { tcp udp }  from any to $pfB_DNSBL_VIPs port $pfB_DNSBL_Ports ridentifier 1770001466 keep state label "USER_RULE: pfB_DNSBL_Permit auto rule" label "id:1770001466"
pass  quick  on {  mvneta1  mvneta1.10  mvneta1.30  mvneta1.50  mvneta1.60  mvneta1.80  mvneta1.90  mvneta1.120  } inet6 proto { tcp udp }  from any to $pfB_DNSBL_VIPs port $pfB_DNSBL_Ports ridentifier 1770001466 keep state label "USER_RULE: pfB_DNSBL_Permit auto rule" label "id:1770001466"

The floating rule does not seem to affect interface 'lo0', even though it is on 'any', should it?:

[25.03-BETA][admin@pfsense.local.lan]/root: grep lo0 /tmp/rules.debug
loopback = "{ lo0 }"
[25.03-BETA][admin@pfsense.local.lan]/root: grep loopback /tmp/rules.debug
loopback = "{ lo0 }"
table <_loopback4_> {   127.0.0.0/8 }
_loopback4_ = "<_loopback4_>"
table <_loopback6_> {   ::1/128 }
_loopback6_ = "<_loopback6_>"
table <_loopback46_> {    127.0.0.0/8   ::1/128 }
_loopback46_ = "<_loopback46_>"
# loopback
pass in  on $loopback inet all ridentifier 1000034061 label "pass IPv4 loopback"
pass out  on $loopback inet all ridentifier 1000034062 label "pass IPv4 loopback"
pass in  on $loopback inet6 all ridentifier 1000034063 label "pass IPv6 loopback"
pass out  on $loopback inet6 all ridentifier 1000034064 label "pass IPv6 loopback"

Do these look OK? ^^^^^ Could my issue be worked-around by adding an "allow-opts"?

Is pfblockerNG responsible for adding rules to 'lo0' if configured on Localhost?

Any suggestions how to suppress the IGMP (options) getting logged on 'lo0'?

.
.
.
.
.
N.B. I have always had the pfblockng DNSBL webserver on LAN, so unfortunately I don't know the behaviour configuring it on Localhost under 24.11, and the appliance used back then is now decommisioned.

I have also checked my services that could generate these IGMPs: Avahi, udp broadcast relay, IGMP Proxy, but neither of those are operating on the local interface, so I am at a loss at where these IGMPs originate. tcpdump doesn't reveal much useful information:

[25.03-BETA][admin@pfsense.local.lan]/root: tcpdump -vvv -n -i lo0 igmp
tcpdump: listening on lo0, link-type NULL (BSD loopback), snapshot length 262144 bytes
16:48:16.778460 IP (tos 0xc0, ttl 1, id 18190, offset 0, flags [none], proto IGMP (2), length 32, options (RA))
    10.10.10.1 > 224.0.0.1: igmp query v2

Wireshark:

Perhaps the "Router Alert" suggests these IGMPs originate within pfSense itself? Should pfSense be sending these for VIPs on lo0?

dennypage

@pst IGMP isn’t related to pfBlockerNG. IGMP comes from your switch or router, and is for multicast.

It’s an issue due to the router alert flag being set. There are a bunch of references in the forum. Here’s one.

Sort version is that you need to allow IP options in your rule.

stephenw10

Did you enable IP Options on that floating rule?

The behaviour of traffic with IP options changed since 2.7.2. It was actually broken for years and is now correct.
https://redmine.pfsense.org/issues/15400#note-2

pst

@stephenw10 said in IGMP w options blocked on lo0 interface, filling the log, can't be silenced:

Did you enable IP Options on that floating rule?

yes I did.

I upgraded to the 0606-beta and the problem went away. Same set of rules, but no issue. June 10-beta is also fine, so I'm happy with that.

stephenw10

Hmm, interesting. Do you know which build you were running when this was happening?

pst

@stephenw10 it must have been the build prior to 0606: May15 (as it was the previous official build)

louis2

@pst @stephenw10

See the blog I did open yesterday!!

Sevire issues related to IGMP multicast traffic

I do mention a number of IGMP related issues there!

And its not the first time I and others complain.

small peace of my actual log

johnpoz

@louis2 well that sure looks like just not having ip options set. Create a rule above the default allow that either blocks or allows that traffic and don't log it.

Or allow ip options on your default allow rule.

Pfsense more likely than not isn't going to do anything with that traffic anyway.. Not unless you want avahi or pimd running and doing something.

There should prob be a log setting not to log such noise.. How you turn off logging bogon/rfc and default deny, etc. I haven't looked in 2.8 or the 25.03 better - maybe there is?

louis2

@johnpoz

John we had that discussion before. But two things here (also see Sevire issues related to IGMP multicast traffic)

pass rules without logging should never ever become block rules with logging
and yep despite that an knowing this completely wrong behavoir I did put a rule in front of other rules WITH options set, but even that does not help !!!
and apart from that what really happens is completely unclear!

So .... really nothing is behaving here like it should !!

The title in the bar is not completely valid, but that is not important here. (example copied from my pclan ruleset)

johnpoz

@louis2 and what cidrs do you in that alias? I take it you have ip options selected in that rule? since see the gear on it. If it includes the multicast destinations being sent, then I agree that shouldn't log.

I also agree that blocking on an allow rule especially if any any rule is bit odd, and can be confusing. if the ip options doesn't match the allow rule - then it should fall through and be logged by default deny.

If have any any, with ip options not allowed - and traffic has ip options the traffic should just not match and fall through.

dennypage

@louis2 The important thing to keep in mind is that you must have allow IP options set in the rule if you expect it to match a packet with the router alert flag set.

Suggest an “Allow” from all rule for IPv4/IPv6 and protocol IGMP on the “Local” interface.

stephenw10

Yup the change in behaviour there is confusion I agree. It logs on whatever matched the traffic, even if that was pass rule, if IP options are no allowed. This is the correct behaviour now, it was broken for years!

See: https://redmine.pfsense.org/issues/15400

louis2

@stephenw10

IMHO the behavoir is fully incorrect! But apart from that I have options set.

Also see part of my rule stack higher up.

Note I am running pfSense+ latest beta

stephenw10

But what's in your MulticastMediaServer alias? Since it's matching the default LAN rule below that.

johnpoz

@stephenw10 exactly - asked the same question, just because you clicked off ip options, and want this media server(s) to see this traffic doesn't mean that rule actually matched if you put in the servers actual IP address, vs the multicast addresses..

louis2

@johnpoz

dennypage

IGMP should be allowed to all.

Try this rule on the “Local” interface:

johnpoz

@louis2 well that last one is wrong.. its 239.255.255.250

so yeah its still going to log that traffic as blocked.

louis2

@johnpoz said in ["solved"] IGMP w options blocked on lo0 interface, filling the log, can't be silenced:

239.255.255.250

John you are right, I should have added that address. The problem is that '239.255.255.0' is a range not an address. I do not know the exact usage of 239.255.255.250 however it is a used control address.

However, adding that address does not solve the problem. Below a small part of my actual log

At this particular moment the log shows 244.0.0.1 Note that the shown rule set was already in place when created the picture of the log somewhat higher (showing addresses being filtered)

PIMD not yet working properly, could be due to the fact that I did not recompile it yet for FreeBSD15 current, but I am not sure about that.

Next to that I really and fully stick to my vision that rules should do what they say what they do !!!

Not logging pass rules turning in block rules and start logging ....... terrible ...

Rules affecting traffic not selected by that rule .... terrible

I really really can not accepted that as being OK !!

stephenw10

You have that rule duplicated on both those interfaces?