Strange entries in the LAN f/w blocked log

NogBadTheBad

@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 !

lohphat

@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

@lohphat

It won’t forward anything to the WAN.

You don’t enable AVAHI on the WAN interface do you?

lohphat

@nogbadthebad No. But I'm seeing link local addresses not in the NDP table. I'm concerned where they're coming from.

johnpoz

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.

NogBadTheBad

You’ll see them on every segment with IPv6 enabled.

lohphat

@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.

NogBadTheBad

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.

lohphat

@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?

NogBadTheBad

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.

IsaacFL

@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.

lohphat

@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?

IsaacFL

@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 Transient

Scope is:
1 interface-local
2 link-local
4 admin-local
5 site-local
8 organization-local
E Global

What 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

@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 )