Bug #17084
closedIPv6 packets with options are not correctly matched with source address '[::]'
0%
Description
Rules for IPv6 packets with options (router alert) no longer match correctly with a source address of '[::]'.
[NB: Rule examples shown below are pulled from /tmp/rules.debug for clarity.]
This rule should match a packet with a source address of '[::]' and a destination of '[ff02::/16]' but does not:
pass in quick on $LAN inet6 from any to ff02::/16 ridentifier 1788968224 allow-opts keep state label "id=1788968224" label "tags=user_rule" label "descr=IPv6 Option Test Rule"
Even changing to a destination of 'any' does not match:
pass in quick on $LAN inet6 from any to any ridentifier 1788968224 allow-opts keep state label "id=1788968224" label "tags=user_rule" label "descr=IPv6 Option Test Rule"
Even as the first rule in the floating list the rule still does not match:
pass quick on { ix0 } inet6 from any to any ridentifier 1788983463 allow-opts keep state label "id=1788983463" label "tags=user_rule" label "descr=IPv6 Option Test Rule"
The filter log entries all identify the blocking rule as 4294967295 (-1):
<134>1 2026-09-09T12:41:19.763865-07:00 fw.mydomain filterlog 73070 - - 4294967295,,,0,ix0,ip-option,block,in,6,0x00,0x00000,1,Options,0,76,::,ff02::16,HBH,PADN,RTALERT,0x0000, <134>1 2026-09-09T12:41:19.763905-07:00 fw.mydomain filterlog 73070 - - 4294967295,,,0,ix0,ip-option,block,in,6,0x00,0x00000,1,Options,0,36,::,ff02::16,HBH,PADN,RTALERT,0x0000, <134>1 2026-09-09T12:41:19.763923-07:00 fw.mydomain filterlog 73070 - - 4294967295,,,0,ix0,ip-option,block,in,6,0x00,0x00000,1,Options,0,76,::,ff02::16,HBH,PADN,RTALERT,0x0000, <134>1 2026-09-09T12:41:19.763939-07:00 fw.mydomain filterlog 73070 - - 4294967295,,,0,ix0,ip-option,block,in,6,0x00,0x00000,1,Options,0,56,::,ff02::16,HBH,RTALERT,0x0000,PADN, <134>1 2026-09-09T12:41:20.764206-07:00 fw.mydomain filterlog 73070 - - 4294967295,,,0,ix0,ip-option,block,in,6,0x00,0x00000,1,Options,0,56,::,ff02::16,HBH,RTALERT,0x0000,PADN,
The problem appears to be very specific to a source address of '[::]'.
The following rule does match source addresses of '[fe80::/10]', but does not match source address '[::]':
pass in log quick on $LAN inet6 from any to ff02::/16 ridentifier 1788984935 allow-opts keep state label "id=1788984935" label "tags=user_rule" label "descr=IPv6 Test Rule"
Example filter log entries with that rule in place:
<134>1 2026-09-09T14:03:03.250607-07:00 fw..mydomain filterlog 73070 - - 1,176,,1788984935,ix0,match,pass,in,6,0x00,0x00000,1,Options,0,36,fe80::c884:8c19:8530,ff02::16,HBH,RTALERT,0x0000,PADN, <134>1 2026-09-09T14:03:03.250624-07:00 fw..mydomain filterlog 73070 - - 1,176,,1788984935,ix0,match,pass,in,6,0x00,0x00000,1,Options,0,56,fe80::6662:66ff:fe22:86b5,ff02::16,HBH,RTALERT,0x0000,PADN, <134>1 2026-09-09T14:03:05.286217-07:00 fw..mydomain filterlog 73070 - - 1,176,,1788984935,ix0,match,pass,in,6,0x00,0x00000,1,Options,0,96,fe80::cb69:4971:b1f6:3514,ff02::16,HBH,RTALERT,0x0000,PADN, <134>1 2026-09-09T14:03:05.286254-07:00 fw..mydomain filterlog 73070 - - 1,176,,1788984935,ix0,match,pass,in,6,0x00,0x00000,1,Options,0,76,fe80::211:32ff:feec:7c33,ff02::16,HBH,RTALERT,0x0000,PADN, <134>1 2026-09-09T14:03:06.291869-07:00 fw..mydomain filterlog 73070 - - 1,176,,1788984935,ix0,match,pass,in,6,0x00,0x00000,1,Options,0,176,fe80::85:3561:de4a:1091,ff02::16,HBH,PADN,RTALERT,0x0000, <134>1 2026-09-09T14:03:34.540217-07:00 fw..mydomain filterlog 73070 - - 4294967295,,,0,ix0,ip-option,block,in,6,0x00,0x00000,1,Options,0,56,::,ff02::16,HBH,RTALERT,0x0000,PADN, <134>1 2026-09-09T14:03:35.539503-07:00 fw..mydomain filterlog 73070 - - 4294967295,,,0,ix0,ip-option,block,in,6,0x00,0x00000,1,Options,0,56,::,ff02::16,HBH,RTALERT,0x0000,PADN, <134>1 2026-09-09T14:03:36.570369-07:00 fw..mydomain filterlog 73070 - - 1,176,,1788984935,ix0,match,pass,in,6,0x00,0x00000,1,Options,0,56,fe80::2e8d:48ff:fe4b:bcfe,ff02::16,HBH,RTALERT,0x0000,PADN, <134>1 2026-09-09T14:03:40.584722-07:00 fw..mydomain filterlog 73070 - - 1,176,,1788984935,ix0,match,pass,in,6,0x00,0x00000,1,Options,0,36,fe80::18f6:c02e:dc08:a5bb,ff02::16,HBH,PADN,RTALERT,0x0000, <134>1 2026-09-09T14:04:16.914517-07:00 fw..mydomain filterlog 73070 - - 1,176,,1788984935,ix0,match,pass,in,6,0x00,0x00000,1,Options,0,36,fe80::1828:db78:7107:7fef,ff02::16,HBH,PADN,RTALERT,0x0000, <134>1 2026-09-09T14:04:53.376373-07:00 fw..mydomain filterlog 73070 - - 1,176,,1788984935,ix0,match,pass,in,6,0x00,0x00000,1,Options,0,36,fe80::c27:755:ebc:aaf7,ff02::16,HBH,PADN,RTALERT,0x0000,
FWIW, I believe this is new to 26.07, but I have not loaded an old version to test. Also, I have not tested with CE but assume the bug is likely present there as well.
DP Updated by Denny Page 8 days ago
FWIW, I am unable to figure out any way to put '[::]' in as a source address via the UI (possibly just my lack of imagination?), so I tested this rule as well:
pass in log quick on $LAN inet6 from 0:0:0:0:0:0:0:0 to ff02::/16 ridentifier 1789055666 allow-opts keep state label "id=1789055666" label "tags=user_rule" label "descr=IPv6 Test Rule"
which does not work for a source address of '[::]' with router alert set.
Just for completeness, I also modified filter.inc to add an explicit MLD rule:
pass in quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type {130,131,132,143} keep state allow-opts ridentifier 1000000112 label "descr=ICMPv6 Test"
as one would expect from prior testing, this rule also does not work for a source address '[::]' with router alert set.
All filter.log entries have the enigmatic identifier of 4294967295 (-1).
I cannot think of any other permutations to test.
DP Updated by Denny Page 8 days ago
While I generally agree, unfortunately in the context of MLD, these packets are frequently seen with some devices. Without a way to separately block/discard these packets, the filter log fills up with useless information.
Also, given the descriptive text of the option:
_ Packets blocked due to IP options Log packets that are blocked due to unmatched IP options in "pass" rules.
I would expect these packets to be silently dropped rather than to be logged because there is no "pass" rule matching.
Can we change this to a silent drop instead?
MM Updated by Marcos M 8 days ago
The way pfSense silences these is through filterlog and the corresponding reason (IIRC 8). These drops share the same reason code as other IP options which is why that setting works. Perhaps filterlog could be changed to do some custom log parsing but that doesn't sound ideal. Potentially pf could offer a separate reason code but that would need to be implemented upstream.
DP Updated by Denny Page 8 days ago
I can take a look at filterlog. If we want to conform to the RFC 9777, then the packets must to be silently dropped as quoted in Redmine #16851.
DP Updated by Denny Page 7 days ago
The more I consider and research, the more I believe that the rationale behind #16851 does not apply to native pfSense at all.
Native pfSense is not a router as defined in RFC 9777, and does not implement the router side of the MLD protocol for the purpose of multicast routing. The only role native pfSense has in RFC 9777 is one of host, and this is implemented by the operating system (FreeBSD).
Native pfSense is a firewall, and there is nothing in RFC 9777 governing the behavior of firewalls.
As a firewall, I don’t see a reason that pfSense rules should be actively prevented from matching any packet. It particularly doesn’t make sense to have this one special case for MLDv2 that cannot be matched simply because of its source address. FWIW, the firewall implementation in Cisco switches, even though they actually implement the MLDv2 router specification, does not prohibit matching of these packets in allow or deny rules. I don't see any reason pfSense should not do the same.
In short, I believe that the current pfSense behavior is actually a bug, and I would like to ask that this case be reopened for consideration.
Note: There is one case when pfSense does become a router in the context of RFC 9777, which is when the optional package mcast-bridge is installed, and active with MLD enabled. In this configuration, mcast-bridge does implement the router side of the MLD protocol.
As of this writing, mcast-bridge does not conform to RFC 9777 in that it does not discard MLD packets with a source address of ‘[::]’. This is a bug which I will address shortly.
MM Updated by Marcos M 7 days ago
In short, I believe that the current pfSense behavior is actually a bug, and I would like to ask that this case be reopened for consideration.
Sounds reasonable given that the details are correct, though I still lean towards discussing it in an upstream FreeBSD pf ticket for wider feedback and consideration.
DP Updated by Denny Page 5 days ago
Are you saying that the code the prevents matching packets with a source address of '[::]', destination address of '[ff02::16]', and router alert set is part of upstream FreeBSD?
DP Updated by Denny Page about 18 hours ago
The mcast-bridge update is issue #17104.
I'll start looking at the upstream issue when I can, hopefully next week.