Project

General

Profile

Actions

Bug #9168

closed

"LAN net" Does Not Include the IPv6 Addresses Like Link Local Addresses and Privacy Addresses

Added by David Lessnau about 6 years ago. Updated about 6 years ago.

Status:
Not a Bug
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
12/04/2018
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.4.4_1
Affected Architecture:

Description

The Default Allow rule that pfSense generates on the LAN for IPv6 traffic are supposed to allow all IPV6 traffic from "LAN net" (and I assume for the other Interface net macros) to everywhere on the LAN. That rule does not work for traffic using (at least) Link Local addresses and Privacy Addresses (these appear to be the first 4 hextets of the address with random stuff added). It seems that the "LAN net" macro does not include these various flavors of local IPv6 addresses. It only seems to include the actual IPv6 addresses noted in the DHCP6 server (not everything noted in the NDP table). This has resulted in my having to add a specific rule allowing traffic sourced from link local addresses to the IPv6 multicast address. I'm still seeing default deny blocks on privacy address sourced traffic to pfSense's LAN interface port 53. But, since I don't know where or how those privacy addresses are generated, I can't come up with an alias or rule that would let me allow the traffic on the LAN.

Each interface's "net" macro should include all IPv6 addresses local to that interface.

https://forum.netgate.com/topic/138293/default-deny-from-my-computer-to-multicast-log-entries-solved
https://forum.netgate.com/topic/138351/how-to-allow-privacy-addresses-on-the-lan

Actions #1

Updated by Jim Pingle about 6 years ago

  • Status changed from New to Not a Bug

fe80 is not "LAN Net". It's link-local traffic that can never leave the segment. It shouldn't be hitting the firewall at all, and if you must pass it to the firewall, you need to add rules to let that happen.

Including it in LAN Net could have unintended consequences, like pf attempting to policy route link-local traffic and causing problems. The potential for breakage is high, and it offers minimal benefit.

The firewall doesn't need this by default for anything I'm aware of. If a package like Avahi needs it for mDNS, then the package could insert rules to allow it.

Actions #2

Updated by David Lessnau about 6 years ago

How about the "privacy addresses?" I'm assuming pfSense is generating them as part of the Privacy Exentions to SLAAC:

https://tools.ietf.org/html/rfc4941#section-3.2

Those addresses ARE designed to leave the segment. Shouldn't they be included in LAN Net when they're generated?

Actions #3

Updated by Jim Pingle about 6 years ago

Clients self-generate those, not the firewall. The "LAN Net" Macro (really the interface name in pf) includes the configured (static or tracked) IPv6 prefix configured on the interface. Properly generated client SLAAC or privacy addresses would be inside that prefix and allowed. Unless someone did something unsupported like setup a static prefix on LAN that wasn't a /64 which might trip up SLAAC. That's all a topic for the forum, though, not here.

Actions

Also available in: Atom PDF