Auto-generated firewall rules block IPv6 link local (fe80::/10) to multicast traffic (ff02::/16)

[jonathonwiebe]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• [ x ] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [ x ] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

The auto-generated firewall rules allow for all IPv4+6 traffic from LAN net to *, but as fe80::/10 isn't part of LAN net, IPv6 link-local multicast traffic is blocked as per the example from the firewall log:
LAN Dec 31 09:16:25 [fe80::199b:4bd7:2e6f:441c]:65055 [ff02::c]:3702 udp Default deny rule

Similar (but not identical) problems have been fixed under issue #4028.

Blocking this traffic may also cause issues for Apple mDNS clients as there is no allowed traffic from fe80::/10 to ff02::FB, but I do not have a device to reproduce.

To Reproduce

Steps to reproduce the behavior:

1. From a Windows device, open File Explorer (triggers WSD discovery multicast)
2. Check firewall logs for blocked traffic

Expected behavior

An auto-generated rule for LAN interface for fe80::/10 <> ff02::/16 traffic should be added, without this rule, devices fail over to IPv4 multicast instead of using IPv6.

Describe alternatives you considered

Specific ports could be allowed (like the DHCPv6 allow rule) vs allowing * link-local multicast, but this doesn't match the expected behavior compared to local multicast in the current IPv4 rules.

fe80::/10 packets should never route past the local link so there should be no additional security risk.

Screenshots

If applicable, add screenshots to help explain your problem.

Relevant log files

If applicable, information from log files supporting your claim.

Additional context

Add any other context about the problem here.

Environment

Software version used and hardware type if relevant, e.g.:

OPNsense 21.7.7-amd64
FreeBSD 12.1-RELEASE-p21-HBSD
OpenSSL 1.1.1l 24 Aug 2021

[fichtner]

Thanks for the analysis. This is a bit strange since LAN networks „:network“ metric should include link-local but apparently it doesn’t. I’ll need to check the OS code on this…

Cheers,
Franco

[fichtner]

PS: can you grab the rule in question for me from /tmp/rules.debug ?

[fichtner]

Hmm, so (xxx:network) excludes Link local which for from and to doesn’t make any sense. We do have issues with these on NAT targets, but the pf code doesn’t distinguish between from/to and target use cases in the first place, unfortunately.
https://github.com/opnsense/src/blob/e7c2aea3c4788d11ff3c60a1a98cd6aa8f9c96df/sys/netpfil/pf/pf_if.c#L560-L564

[fichtner]

I traced this back to 2003 where a large blob appeared in OpenBSD that added the link-local exclusion but it doesn’t mention why…

openbsd/src@ec359bd

[fichtner]

opnsense/src@4c8d17ed0c1e is sort of an experiment. According to OpenBSD work back in 2002 and 2003 link-local seems to be considered irrelevant for pf operation and the same holds true to this day. The link-local to multicast, however, is indeed an issue that fails to take into account the relevancy of the traffic for the host itself.

[fichtner]

One more caveat: it seems all of this :network link-local exclusion magic is tied to the fact that "antispoof" keyword uses it internally and can't handle link-local expansion correctly ... looks like spoofing when including this network since it doesn't take the scope into account).

[fichtner]

This is too much effort to unclog in pf(4) so we will add an automatic rule for the firewall.

[fichtner]

c7e67c6 includes link-local via network selector on IPv6 rules which should fix this for all use cases, even existing default pass rules.

Cheers,
Franco