pfSense

The 'default' ruleset on a CE 2.8.1-RELEASE system appears to pass inbound Neighbor Solicitation messages in accordance with RFC 6434, § 5.2 (i.e., "[ . . . ] all nodes MUST respond to unicast Neighbor Solicitation (NS) messages.) The relevant rules have ridentifiers 1000000107, 1000000110, and 1000000111 on the system I'm looking at. I can also see that this particular system is actually responding to inbound NS messages via a positive "State Creation" counter for ridentifier 1000000107.

The tunable net.inet6.icmp6.nd6_onlink_ns_rfc4861 on this same system is set to 0. A reason for the apparent default of 0 may be related to this (very old) Security Advisory: https://www.freebsd.org/security/advisories/FreeBSD-SA-08:10.nd6.asc.

Could you provide a trace showing this traffic so that the packets the Juniper devices are generating can be inspected? They might be utilizing a globally routable address as the source address, but destined for the pfSense WAN interface's link-local address—which the state-policy of the 'default' rules being set to if-bound may be interfering with.

Matt Dombrowski wrote in #note-2:

The 'default' ruleset on a CE 2.8.1-RELEASE system appears to pass inbound Neighbor Solicitation messages in accordance with RFC 6434, § 5.2 (i.e., "[ . . . ] all nodes MUST respond to unicast Neighbor Solicitation (NS) messages.) The relevant rules have ridentifiers 1000000107, 1000000110, and 1000000111 on the system I'm looking at. I can also see that this particular system is actually responding to inbound NS messages via a positive "State Creation" counter for ridentifier 1000000107.

The tunable net.inet6.icmp6.nd6_onlink_ns_rfc4861 on this same system is set to 0. A reason for the apparent default of 0 may be related to this (very old) Security Advisory: https://www.freebsd.org/security/advisories/FreeBSD-SA-08:10.nd6.asc.

Could you provide a trace showing this traffic so that the packets the Juniper devices are generating can be inspected? They might be utilizing a globally routable address as the source address, but destined for the pfSense WAN interface's link-local address—which the state-policy of the 'default' rules being set to if-bound may be interfering with.

Yes you are fully correct, the source address is a globally routable address and the destination is the link local address. I have a large PCAP that I can attach via Google Drive if that is allowed?
Let me know if there is any more info you need.

For the record, I have no affiliation with Netgate, so this is all merely advice from a fellow CE user. But my guess would be that the tunable net.inet6.icmp6.nd6_onlink_ns_rfc4861 being set to 1 is, in fact, one possible 'official' workaround and fix for this specific use case.

You might also alternatively be able to—instead of modifying the tunable—pass this traffic by crafting a firewall rule on the WAN interface, strictly permitting only the Juniper device/s' NS messages sent from its/their known global unicast addresses to the WAN interface's link-local address explicitly (as opposed to fe80::/10), and setting the state-policy to floating. If this works, it'd be a much more visible and 'least-privileged' approach.