IPv6 neighbor solicitation with next header = "IPv6 Hop-by-Hop" option results in blocked entry in LAN Firewall

gambit100

My pfsense 2.9.0 LAN Firewall log has blocked entries such as:

Sep 21 11:15:19 LAN (@4294967295) [Windows 11 IPv6 address] [pfsense router IPv6 address] Options
Sep 21 08:36:05	LAN (@4294967295) [Windows 11 IPv6 address] [pfsense router IPv6 address] Options
Sep 21 07:15:09	LAN (@4294967295) [Windows 11 IPv6 address] [pfsense router IPv6 address] Options

Wireshark shows these are neighbor solicitations from my windows 11 PC to the pfsense router. There are many of these in the wireshark log but the ones that produce the firewall log entry have the Hop-by-Hop option as shown below. Packets without this option do not show up in the firewall log.

Frame=> [...]
	[Protocols in frame: eth:ethertype:ipv6:ipv6.hopopts:icmpv6]
Internet Protocol Version 6 [...]
    Next Header: IPv6 Hop-by-Hop Option (0)
	[...]
	IPv6 Hop-by-Hop Option
    Next Header: ICMPv6 (58)
    Length: 0
    [Length: 8 bytes]
    Router Alert
    PadN

Only the windows 11 PC causes these. Linux and android do not.
All of the firewall check boxes for implicit rules are unchecked so I'm not sure why they are showing up in the log.
As far as I can tell, the system is performing without any issues but these entries tend to fill up my firewall logs.

Any ideas on whether this is actually a problem would be helpful. Also, if it's not really a problem, a way to silence these entries so they don't fill up my firewall log would be helpful.

dennypage

@gambit100 It's the Router Alert option that is triggering the issue.

There seem to be a few issues with handling of packets that contain IP options. The problem appears to originate with upstream FreeBSD. See Redmine 17084 for another example.

The only way to get rid of the log entries is to disable the logging of blocked packets with options. Go to Status -> System Logs -> Firewall, click on the wrench icon, and deselect Packets blocked due to IP options.

gambit100

@dennypage Thanks for the response. The "Packets blocked due to IP options" is actually unchecked and I still get entries.

Since I can't actually detect any issues with my windows 11 PC, I'm going to assume these packets are not causing any issue by being blocked, especially since the majority of neighbor solicitations don't have that option. The firewall log is annoying but not crucial so I can live with it.

dennypage

@gambit100 said in IPv6 neighbor solicitation with next header = "IPv6 Hop-by-Hop" option results in blocked entry in LAN Firewall:

The "Packets blocked due to IP options" is actually unchecked and I still get entries.

Hmm... maybe there is an issue with the logging option on 2.9.0. I'm running Plus, but I'm curious so I'll play around with it.

dennypage

@gambit100 Just to double check, can you run the following command please?

ps -axuw | grep filterlog

gambit100

@dennypage [2.9.0-RELEASE][admin@Firewall.home.com]/root: ps -axuw | grep filterlog
root 52551 0.0 0.0 15072 3892 - Ss 14:49 0:01.58 /usr/local/sbin/filterlog -i pflog0 -p /var/run/filterlog.pid -r 8

dennypage

@gambit100 said in IPv6 neighbor solicitation with next header = "IPv6 Hop-by-Hop" option results in blocked entry in LAN Firewall:

root 52551 0.0 0.0 15072 3892 - Ss 14:49 0:01.58 /usr/local/sbin/filterlog -i pflog0 -p /var/run/filterlog.pid -r 8

The -r 8 is correct, and should suppress logging of packets with options. Definitely works on Plus in my environment, not sure why it wouldn't be working on CE with yours.

@marcosm, do you know of any CE specific issues with this?

marcosm

I don't expect any different issues - both 2.9.0 and 26.07 share the same base code. I can't really comment on the reported issue without real examples; it sounds more like pf is dropping the packets because of the ruleset though rather than the IP options / packet validation that pf does. For example, an IPv4 packet with embedded IPv6 may result in a similar log and could be matched/passed with an IPv4 rule with the IPv6 protocol selected.

dennypage

@marcosm He posted a partially decoded frame up above. It's a standard icmpv6 packet with a router alert option in it.

dennypage

@marcosm said in IPv6 neighbor solicitation with next header = "IPv6 Hop-by-Hop" option results in blocked entry in LAN Firewall:

it sounds more like pf is dropping the packets because of the ruleset though rather than the IP options / packet validation that pf does

It's showing rule 4294967295 (-1), so it's kinda hard to tell anything. Maybe there is some way to bring a little more detail to these mysterious -1 rules in the future?

gambit100

@dennypage if it helps...
The filter.log entry shows:

Sep 24 09:08:05 Firewall filterlog[52551]: 4294967295,,,0,igc1,normalize,block,in,6,0x00,0x00000,64,Options,0,40,2603:9001:7c00:1cf7:500b:1591:ec
64:8eaf,2603:9001:7c00:1cf7:6662:66ff:fe25:8cee,HBH,RTALERT,0x0000,PADN,

and pfctl shows:

pfctl -sr | grep -i "icmp6"
pass quick inet6 proto ipv6-icmp all icmp6-type unreach keep state (if-bound) label "descr=ICMPv6 operation" ridentifier 1000000107
pass quick inet6 proto ipv6-icmp all icmp6-type toobig keep state (if-bound) label "descr=ICMPv6 operation" ridentifier 1000000107
pass quick inet6 proto ipv6-icmp all icmp6-type neighbrsol keep state (if-bound) label "descr=ICMPv6 operation" ridentifier 1000000107
pass quick inet6 proto ipv6-icmp all icmp6-type neighbradv keep state (if-bound) label "descr=ICMPv6 operation" ridentifier 1000000107

Regarding the firewall log entries, I found this quote although I can't state whether it's accurate: The "Packets blocked due to IP options" setting only controls IPv4 Options (such as Source Routing or Record Route), while these packet are being blocked by a completely different mechanism: IPv6 Extension Headers

Just a though. Perhaps my windows 11 PC is not generating the neighbor solicitation packets the same as on your network so the two versions of pfsense are working the same but are seeing different packets.

The windows 11 PC appears to be functioning correctly so this isn't a crucial problem for me. I'm going to try and write a floating rule to try and pass these so my firewall log doesn't stay cluttered.

marcosm

The setting for "Packets blocked due to IP options" is not dependent on the IP address family. Ultimately it avoids logging packets that get dropped according to a particular pf reason (code 8) - that can be either IPv4 or IPv6. That fiterlog line above shows that the reason for the drop is "normalize" (code 4) which is separate from what the setting controls. Depending on how pf handles those, you may or may not be able to craft a rule to silently drops those. If it's not possible then potentially fiterlog could be called with "-r 4" in addition to "-r 8".

dennypage

@marcosm said in IPv6 neighbor solicitation with next header = "IPv6 Hop-by-Hop" option results in blocked entry in LAN Firewall:

That fiterlog line above shows that the reason for the drop is "normalize" (code 4) which is separate from what the setting controls.

Thanks Marcos.

gambit100

Thanks for the help @dennypage and @marcosm .
I added "-r 4" to /etc/inc/filter.inc and restarted the filterlog. The firewall log no longer gets flooded by the neighbor solicitation messages. My understanding is this change will get overridden by the next update but at least for now I have a clean log.

marcosm

I would investigate the device generating those packets and fix it there if possible instead of silencing it.

gambit100

@marcosm I researched the issue on windows 11 but I'm not very proficient in this network area.
There does not appear to be a way to turn the hop-by-hop option off. Windows 11 appears to use this with routers but I could not find why it decides to sometimes add this option and other times sends the NS packet without the hop-by-hop option. When it chooses to add the option to the NS packet, it sends quite a few of them (presumably because it doesn't get a NA response) which fills the log.
I found two possible solutions on the windows 11 side:

Use the windows firewall to block these packets. Blocking NS packets with the Hop-by-Hop option but allowing others to proceed seemed difficult. Also, it wasn't clear to me that this was better than the silencing method on the router.
Drop back windows 11 Multicast Listener Discovery (MLD) from v2 to v1. This removes the option for Hop-by_Hop: "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\MldVersion=1"
There were warnings about inefficient multicast groups and a possible security risk for LAN clients injecting malicious multicast traffic. I'm not sure how important either of these would be on my LAN but since I didn't completely understand the side effects, I chose to leave the functionality alone and just silence the router logs.

I may research this some more in the future.

dennypage

@gambit100 said in IPv6 neighbor solicitation with next header = "IPv6 Hop-by-Hop" option results in blocked entry in LAN Firewall:

There does not appear to be a way to turn the hop-by-hop option off. Windows 11 appears to use this with routers but I could not find why it decides to sometimes add this option and other times sends the NS packet without the hop-by-hop option.

The purpose of a hop-by-hop header is simply to house other (real) options. There are a number of options that may be contained in the hop-by-hop header. You would need to identify the specific option that is being included if you want to discover why Windows is doing it.

If it's an MLD advertisement, then by definition it has to have a router alert option. But that's not "ND". The only reference I know of for ND in the context of MLD is that ND is a type used in mDNS. But that would be in a mDNS data packet and not an ICMP packet.

There's a lot of uncertainty here about what is actually triggering the issue. A packet capture would clarify a lot if you can provide one.

gambit100

@dennypage Below is a wireshark capture of a packet containing the Hop-by-Hop option with alert type of MLD (0). Google's AI claims:

A Neighbor Solicitation (NS) packet carrying an MLD (0) router alert is a completely normal, standard component of IPv6 core networking on Windows 11.
When your firewall or router logs a packet with these terms, it is witnessing Windows 11 performing a mandatory routine called Duplicate Address Detection (DAD) to ensure its own local IP* address doesn't conflict with another device on the network.*

Unfortunately, windows 11 appears to start sending these frequently when it doesn't get a response which floods the firewall log.
I'm not sure what causes windows 11 to generate these since the PC was running and didn't just boot up or come up from sleep state. I don't believe anything changed on the network either.

534	2026-09-27 19:50:48.408517200	<windows 11>	<pfsense>	ICMPv6	94	Neighbor Solicitation for <pfsense> from 00:e0:4c:01:f4:0c

Frame 534: Packet, 94 bytes on wire (752 bits), 94 bytes captured (752 bits) on interface \Device\NPF_{B898AED1-CA87-489E-ACCD-623745EE4B22}, id 0
    Section number: 1
    Interface id: 0 (\Device\NPF_{B898AED1-CA87-489E-ACCD-623745EE4B22})
    Encapsulation type: Ethernet (1)
    Arrival Time: Sep 27, 2026 19:50:48.408517200 Eastern Daylight Time
    UTC Arrival Time: Sep 27, 2026 23:50:48.408517200 UTC
    Epoch Arrival Time: 1790553048.408517200
    [Time shift for this packet: 0.000000000 seconds]
    [Time delta from previous captured frame: 4.962271000 seconds]
    [Time delta from previous displayed frame: 4.962271000 seconds]
    [Time since reference or first frame: 1 hour, 24 minutes, 58.309973300 seconds]
    Frame Number: 534
    Frame Length: 94 bytes (752 bits)
    Capture Length: 94 bytes (752 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ipv6:ipv6.hopopts:icmpv6]
    Character encoding: ASCII (0)
    [Coloring Rule Name: ICMP]
    [Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: RealtekSemic_01:f4:0c (00:e0:4c:01:f4:0c), Dst: Protectli_5:8c:ee (64:62:66:25:8c:ee)
    Destination: Protectli_5:8c:ee (64:62:66:25:8c:ee)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: RealtekSemic_01:f4:0c (00:e0:4c:01:f4:0c)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv6 (0x86dd)
    [Stream index: 0]
Internet Protocol Version 6, Src: <windows 11>, Dst: <pfsense>
    0110 .... = Version: 6
    .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
        .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
        .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
    Payload Length: 40
    Next Header: IPv6 Hop-by-Hop Option (0)
    Hop Limit: 64
    Source Address: <windows 11>
        [Address Space: Global Unicast]
    Destination Address: <pfsense>
        [Address Space: Global Unicast]
    [Destination SLAAC MAC: Protectli_5:8c:ee (64:62:66:25:8c:ee)]
    [Stream index: 0]
    IPv6 Hop-by-Hop Option
        Next Header: ICMPv6 (58)
        Length: 0
        [Length: 8 bytes]
        Router Alert
            Type: Router Alert (0x05)
            Length: 2
            Router Alert: MLD (0)
        PadN
            Type: PadN (0x01)
            Length: 0
            PadN: <none>
Internet Control Message Protocol v6
    Type: Neighbor Solicitation (135)
    Code: 0
    Checksum: 0xa947 [correct]
    [Checksum Status: Good]
    Reserved: 00000000
    Target Address: <pfsense>
    ICMPv6 Option (Source link-layer address : 00:e0:4c:01:f4:0c)
        Type: Source link-layer address (1)
        Length: 1 (8 bytes)
        Link-layer address: RealtekSemic_01:f4:0c (00:e0:4c:01:f4:0c)

dennypage

@gambit100 said in IPv6 neighbor solicitation with next header = "IPv6 Hop-by-Hop" option results in blocked entry in LAN Firewall:

A Neighbor Solicitation (NS) packet carrying an MLD (0) router alert

Okay, now I see how things are getting confused. First and foremost, the packet in question is a Neighbor Solicitation packet, and not a Multicast Listener Discovery packet. The reason that it says "MLD" in the decode is because the type encoded in the Router Alert header is 0, which would be the MLD type if this were a MLD packet. But it's not an MLD packet, so we'll set MLD aside...

What we have is an IPv6 Neighbor Solicitation packet (part of the RFC 4861 IPv6 Neighbor Discovery protocols) with Router Alert set. In a word, this is wrong. Neighbor Solicitation packets should never have Router Alert set. I could almost understand the mistake if the packet were a Router Solicitation (also part of RFC 4861), but even these should not have Router Alert set. Nothing in the Neighbor Discovery set should have a Router Alert.

Marcos was right to say that you should investigate... You have a significant Windows bug which should be reported to Microsoft.

marcosm

@dennypage Good detailed info, thanks!