25.07: protocol "options" in default block all rule

[beerguzzle]

I upgraded my 1100 from 24.11 to 25.07 yesterday. Since then I have seen a ton of blocks on my OPT (wireless) interface of IPv6 traffic, see attached screenshot, with protocol "options"

This seems to be ICMP broadcast traffic -- I cannot find the addresses ending in 4497 and 69fa in the NDP table or anywhere else so I don't know the source.

I went into the advanced area of the rule and turned on "allow packets with IP options to pass". That did not quell the block msgs. Plus I don't want ICMP traffic to be tracking my devices anyway. I tried both "block" and "reject", no difference. The rule looks like:

What is going on here?

[Gertjan]

@beerguzzle

Do you log the firewall rule ?

[johnpoz]

@beerguzzle ff02::16 is not icmp it is multicast "All MLDv2-capable routers"

If you want to create a rule to allow that doesn't log that you would need to set options in the rule, and then set it not to log.

what is the order of rules on your opt interface? outbound is only available in the floating tab.

[jimp]

https://redmine.pfsense.org/issues/16194

Hover your mouse over the action icon and look at the details it shows you there.

[beerguzzle]

@jimp @johnpoz

This rule is the last (bottom) rule for my OPT interface, a default "block anything not allowed above" rule. I have a similar rule for LAN, that also fires this "options" blurb too in 25.07. Hovering over the action shows:

which looks similar to (but not identical) to redmine 16194.

I went into advanced options for the rule and turned on "Allow IP options", but nothing changed after the rules reloaded.

I also searched the pfsense docs for MLD, not much came up. In head scratch mode. Is this a redmine 16194 style "feature"?

[jimp]

If you can find the line that corresponds to those log messages in /var/log/filter.log, copy/paste it here. It may be a similar packet to the redmine issue but maybe not identical.

Since I was able to reproduce the one I was seeing I got a packet capture of it to see what it was, but depending on what you are seeing that may not be viable.

[beerguzzle]

@jimp

Here it is:

Aug 5 13:49:59 cleo filterlog[66564]: 247,,,1649447902,mvneta0.4092,match,block,in,6,0x00,0x00000,1,Options,0,56,fe80::417:952d:77be:4497,ff02::16,HBH,PADN,RTALERT,0x0000,

which should match with this from the gui:

[beerguzzle]

I'll state the obvious here... I went to System->Advanced->Networking and unchecked "Allow IPv6". Poof, the firewall log entries went away. I had found the reddit webpage on this topic:

https://www.reddit.com/r/PFSENSE/comments/1hzmc5y/ipv6_noise_protocol_options_to_ff0216/

and started down knox203's suggested fix for quieting the syslogs. I already had "Allow IPv6" checked, and wondered why I need IPv6 on my network at all. Unchecked it and bliss.

[Gertjan]

@beerguzzle said in 25.07: protocol "options" in default block all rule:

and wondered why I need IPv6 on my network at all

You, as a person, you don't.
Look again at our LAN network. Get you hands on a dumb switch - also known as a hub, and now do some network sniffing for IPv6 packets on your LAN and you discover that most IP traffic is IPv6 - not IPv4.
Only traffic to and from the Internet is still IPv4 for you, because you didn't set it up yet - or maybe your ISP doesn't support it.

True, you have still some time to dive into IPv6.... but the clock is set and counting ;)

[johnpoz]

@Gertjan said in 25.07: protocol "options" in default block all rule:

LAN and you discover that most IP traffic is IPv6 - not IPv4.

Not true at all..

You will most likely see a lot of extra noise from IPv6 from window machines - most iot devices don't even support IPv6, and they don't use it to talk to each other that is for sure.

While true IPv6 is the future - if you have no need to access public resources via IPv6, name one resource you want/need that is only IPv6 or your not stuff behind some cgnat for IPv4 and need IPv6 to allow for unsolicited inbound traffic. The typical user has zero need for IPv6.

If I access my nas via its rfc1918 IPv4 address, it doesn't in the background say oh, I am going to use IPv6 to transfer these files. Because that nas also has a IPv6 link local address.

My isp doesn't even provide IPv6 if I wanted to use it. And shoot most isp that do provide it, do so in some borked fashion.

Even if devices did use it internally between devices on the same L2. linklocal doesn't route, so from the point of view of the user on their router, it means nothing.

[Gertjan]

@johnpoz said in 25.07: protocol "options" in default block all rule:

Not true at all..

True, a load of conditions apply.
If the network is mostly cameras doorbells and other (look to the east) 'connected stuff', IPv4 is probably used more. That said, the small stuff normally don't transfer a lot of data.

But the classic company network, my case : a load of windows PCs and servers, unifi stuff, NAS (Syno) and 'modern networked printers : I persist : IPv6.
All 'recent' PCs phone pad etc OSes use IPv6 be default.
For that to happen, true, IPv6 must work flawlessly of course. A 'perfect' IPv6 starst with an ISP that supports it.

A global overview of IPv6 usage in the ancient world (Europe, France to be exact) : Baromètre IPv6 Arcep 2025

edit : even amazon and facebook (in Europe) went full '6' recently.