Strange entries in the LAN f/w blocked log
-
I started seeing entries like these in the LAN f/w logs as blocked despite having the default allow IPv6 any any any rule:
[fe80::e102:xxxx:yyyy:zzzz]:56943 [ff02::c]:3702
and
[fe80::5548:xxxx:yyyy:zzzz]:54184 [ff02::1:3]:5355
and
[fe80::6a54:xxxx:yyyy:zzzz]:5353 [ff02::fb]:5353Only one of these local link addresses are in the NDP table the other's are not from the local LAN. But if they're not, where are they coming from? The 6to4 pass-through tunnel? If that's the case, why aren't these being blocked on the WAN interface?
When I traceroute the addresses they are 1 hop away.
-
Whelp, I found this thread from a while back:
https://forum.netgate.com/topic/36262/ipv6-multicast-being-blocked-on-lan
But it's still not explained why the default permit IPv6 LAN any any any traffic is not allowing it. Doesn't allow "any" mean "any"?
-
They are Link-local unicast addresses fe80::/10, if you have multiple LANS add the following rules to each interface if you want to pass multicast traffic:-
-
@nogbadthebad That's the thing, I only have one LAN i/f.
-
@lohphat said in Strange entries in the LAN f/w blocked log:
@nogbadthebad That's the thing, I only have one LAN i/f.
Then just add the above rule and set it to block and not log if you don't want to see the entries in your firewall log :)If your running AVAHI on the router you'll still need the rule regardless.
-
@nogbadthebad So, for my IPv6-fu why weren't the fe80::/10 addresses local to the LAN segment not permitted by the IPv6 allow any any any rule in the first place?
-
@lohphat said in Strange entries in the LAN f/w blocked log:
@nogbadthebad So, for my IPv6-fu why weren't the fe80::/10 addresses local to the LAN segment not permitted by the IPv6 allow any any any rule in the first place?
Because it's IPv6 local link rather than the IPv6 subnet you've defined on the LAN interface.
From my Mac:-
mac-pro:~ andy$ ifconfig en0
en0: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
options=10b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV>
ether 00:3e:e1:c1:af:07
inet 172.16.2.20 netmask 0xffffff00 broadcast 172.16.2.255
inet6 fe80::1cf1:d55:da78:975%en0 prefixlen 64 secured scopeid 0x6
inet6 2a02:xxxx:yyyy:2::14 prefixlen 64 dynamic
nd6 options=201<PERFORMNUD,DAD>
media: autoselect (1000baseT <full-duplex,energy-efficient-ethernet>)
status: active
mac-pro:~ andy$2a02:xxxx:yyyy:2::14 is via DHCP
fe80::1cf1:d55:da78:975%en0 is set by the host
-
@nogbadthebad So that raises an additional question: How does pfSense determine from a security perspective which link local addresses belong to which interface? Shouldn't it keep track as to which fe80:: addresses correspond to their associated i/f so that the rulebase can act accordingly? Or is the best practice to just block all fe80:: addresses and force the host to use their assigned real addressing? From my limited IPv6-fu I thought that the fe80:: addresses perform critical operations to keep multicast groups (e.g. NDP) working, so they need to be permitted.
-
Link local are only needed on the local lan segment till you want multicast from one lan segment to another.
-
@nogbadthebad So I modified the rule so that the FE80::%mvneta2/10 now includes the scope ID of the LAN.
So why aren't FE80:: addresses included in the LAN Segment and WAN Segment definitions by their scope ID so that they are covered by the rulebase for the segment since those packets originate there?
-
@lohphat And THAT was a FAIL as the UI accepted adding the scope but the rule processor choked on it.
-
@lohphat said in Strange entries in the LAN f/w blocked log:
@lohphat And THAT was a FAIL as the UI accepted adding the scope but the rule processor choked on it.
So what exactly did you put in ?
-
@nogbadthebad allow IPv6(any) from-network fe80::%mvneta2 /10 to-network ff02:: /16
-
@lohphat said in Strange entries in the LAN f/w blocked log:
@nogbadthebad allow IPv6(any) from-network fe80::%mvneta2 /10 to-network ff02:: /16
Look at my screenshot, it's fe80:: /10 -> ff02:: /16 and they're Networks !
-
@nogbadthebad I saw that but the concern I have is that there are fe80 addresses on the WAN too. If I just want to permit fe80 traffic originating from the LAN i/f how do is that restricted? It seems your example permits any fe80 traffic no matter the origin.
-
-
@nogbadthebad No. But I'm seeing link local addresses not in the NDP table. I'm concerned where they're coming from.
-
Then sniff and get the mac so you can track it down. link local is layer 2 only.. So if your seeing it on your lan - then it has to be from a device on the layer 2 your lan is connected to.
-
You’ll see them on every segment with IPv6 enabled.
-
@nogbadthebad That's my point. They're on every segment so how can I restrict source fe80 address which only exist on the LAN segment? I only have WAN adn LAN and I'm concerned about how to separate them instead of fe80 addresses being flat and not associated with an i/f in the ruleset.
-
If you don’t enable AVAHI on the WAN interface they won’t be seen on the WAN interface.
You probably need to read up on mDNS and AVAHI.
-
@nogbadthebad Well you CAN'T enable avahi on the WAN interface. It says so on the config page. I understand about mDNS and it's need to have multicast enabled.
This questions I have are more broad at this point.
-
I'm seeing fe80 addresses not in the NDP table. Where are they coming from?
-
If the fe80 packets are coming from the LAN interface then why isn't the LAN allow rule for IPv6(any) from-LAN to-any allowing them? Why aren't they included?
-
-
-
Do a packet capture on the LAN interface, download it to wireshark and look at the MAC addresses, if you only have a LAN interface they are coming from devices on your LAN.
-
They aren’t included in the LAN network macro, maybe one of the developers might be able to tell you.
-
-
@nogbadthebad said in Strange entries in the LAN f/w blocked log:
They are Link-local unicast addresses fe80::/10, if you have multiple LANS add the following rules to each interface if you want to pass multicast traffic:-
This is what you need to do.
The short answer is there needs to be a rule to pass multicast, so that the router daemon inside pfsense can act on them. I don't know why the default is to reject all multicast to the router. The router daemon is bedhind the firewall filter, so doesn't see the multicasts.
IPv6 needs multicast to work, and sometimes, the router needs to be the one to respond to the multicasts. So you need a rule to pass to Multicast (ff00::/12).
For instance the [ff02::1:3]:5355 is a Link-Local Multicast Name Resolution (LLMNR) request. It probably came from a windows machine.
If the firewall rule allows it to pass, then the router dns will respond. No rule, the router doesn't know about the request and doesn't provide dns response.
The short answer is I always have a rule (except WAN) to pass multicast, so that the router daemon inside pfsense can act on them. I don't know why the default is to reject all multicast to the router.
-
@isaacfl Thank you!
This is what I was looking for. I knew it had to do with multicast needing access but couldn't understand why it isn't automatic as part of IPv6 support -- or at least a warning indicating that it needs to be enabled.
We're all on an IPv6 learning curve and as it percolates into more configs these "obvious" functional settings should become more straight forward. e.g. would it become best-practice to include fe80:: addresses as part of any interface firewall rule as a checkbox to allow link-local as part of the rule, or force it into its own rule duplicating the rule? To me "LAN network" would include both the designated routable 2xxx:: network AND the fe80 from that interface but perhaps that's fundamentally a "Bad Idea[tm]" from an IPv6 architectural decision.
BTW, I enabled ff00::/8 for good measure as per https://en.wikipedia.org/wiki/Multicast_address#IPv6 what's your take?
-
@lohphat You are probably ok using ff00::/8 as your Multicast, currently I am using ff00::12.
The format of multicast address is:
FF (8 bits) Flags (4) Scope (4)Flags are:
0000 Well known
0001 TransientScope is:
1 interface-local
2 link-local
4 admin-local
5 site-local
8 organization-local
E GlobalWhat I have done is defined an Alias called Link_Multicast that I use in my rules, and I have changed it from ff00:8 to ff02::16, and now I am at ff00:12 since I am not sure what "Transient" is used for. ff02::16 seemed to work for everything I have been able to test so far. ff02:: is well known, link-local.
I understand the philosophy of not including the fe80 in the "Lan network" addresses as it should be left up to the user to decide whether they want it to pass or not. But there probably needs to be more knowledge put out about the uses for multicast in ipv6. Same as for ICMPv6. pfsense does already have a default rule to pass the DHCP multicast.
-
@isaacfl actually, I just went and checked and my "cheat sheet" for multicast is obsolete
See https://en.m.wikipedia.org/wiki/Multicast_address
For updated multicast (go down to IPv6 )
