fe80::/16 not included in interface networks?

JKnott

@offstageroller

Link local addresses are on all interfaces and fe80 doesn't denote any particular network. Why do you think it does?

OffstageRoller

@jknott With IPv6 and Avahi enabled on an interface, these requests get caught by the default IPv6 deny rule.

JKnott

@offstageroller

Link local addresses are not routeable, so they don't need a rule to block them.

OffstageRoller

@jknott

Perhaps I'm asking the wrong question.

Why, when I enable IPv6 and Avahi, is pfSense blocking these link local addresses? If they're not routable, why does pfSense see them as being routed and then block them with the default reject rule?

johnpoz

@offstageroller said in fe80::/16 not included in interface networks?:

but that interface name does not include fe80::/16, and therefore I need to create an

Why would you think your "net" address should include fe80::/16? The interfaces link local would be only a /64..

look on your interfaces with ifconfig to see your link local addresses..

example here is my lan interface

inet6 fe80::208:a2ff:fe0c:e624%igb0 prefixlen 64 scopeid 0x1

if the source of the traffic was using the same prefix then it should be part of your "net" alias..

An alias for any specific "net" using the space of /16 wouldn't be a specific net, it would be a huge chuck of the whole space FE80::/10, where did you come up with using /16 anyway?

edit: not sure where you came up with the ff00::/8 prefix for mdns it would only ever use "ff02::fb" not sure why you would allow ff00::/8

OffstageRoller

@johnpoz

You're right... I'm communicating this poorly.

When I say fe80::/16, I really mean the actual /64. I guess in this case my rule should actually be fe80::/64, since that's what my addresses end up being.

I will also update my rule for the destinations to be ff02::fb.

I'm still confused though. Here's what I see for the link local addresses on my VL30_KIDS interface:

	inet6 fe80::208:a2ff:fe0d:153f%lagg0.30 prefixlen 64 scopeid 0xe
	inet6 fe80::1:1%lagg0.30 prefixlen 64 scopeid 0xe

However, when I see the current states on the interface, it shows these as the sources and destinations:

fe80::ce5:190d:b990:d6e7[5353] -> ff02::fb[5353]
fe80::1c5f:ab8a:c0d:d49[5353] -> ff02::fb[5353]

Those don't match the address of the link local address on my interface, so I'm confused on where those are coming from then?

JKnott

@offstageroller

As I mentioned, every IPv6 capable device has a link local address, so that narrows it down to any device on your LAN. The ff02 means multicast to the local link only.

OffstageRoller

@jknott

iOS doesn't show their link local addresses in the settings. But it's safe to assume those two link local addresses are my two kid's iPads then.

iOS does show the IPv6 gateway is a link local address, and I assume that's expected as well.

So having my iOS devices use their link local addresses to communicate with ff02::fb over port 5353 is expected for mDNS correct?

pfSense blocks that be default. pfSense blocks everything by default, but when I create a rule to allow that interface to communicate over port 5353, I expect that would work for IPv6.

The default interface network names do not include the link local addresses on them, but that's why I created this post... shouldn't they? Aren't link local addresses on that interface part of that network?

JKnott

@offstageroller said in fe80::/16 not included in interface networks?:

So having my iOS devices use their link local addresses to communicate with ff02::fb over port 5353 is expected for mDNS correct?

Yes. mDNS uses multicast and is intended for the local LAN only. If you examine a packet capture, you will likely find the hop limit is 255, which is another way to ensure it doesn't leave the local link. If you're getting errors a rule to allow those packets should be OK, as it's allowing something that will never happen.

bmeeks

I think there is some confusion with responses in this thread maybe due to incomplete reading of the original post.

The OP is using avahi to distribute multicast traffic across several local VLANs. The avahi daemon runs on pfSense itself in this setup. So link local packets must hit the firewall on one VLAN and then get allowed in so avahi can "see" them to copy them over to other VLANs (or "route them" if you will).

What @JKnott is saying about link local IPs not normally being routed elsewhere is technically true, but in this particular setup with avahi that the OP is using, he does in fact need to "route" that traffic to other subnets. So he needs the "*NET" built-in alias to include the IPv6 link local addresses as part of the alias so the default IPv6 rules don't drop the multicast traffic and thus hide it from the avahi daemon. At least that's what he needs in his case with avahi, but normally this is not needed since link-local traffic is, by definition, restricted to just the local subnet.

So I can see the point of not including that address space in the default definition, but perhaps the avahi package needs to be modifed such that it adds its own firewall rule to cover this situation, so the user doesn't have to.

johnpoz

@bmeeks said in fe80::/16 not included in interface networks?:

he does in fact need to "route" that traffic to other subnets.

Not sure route is the correct term in this context to be honest ;) Repeated prob better term.

JKnott

@bmeeks said in fe80::/16 not included in interface networks?:

What @JKnott is saying about link local IPs not normally being routed elsewhere is technically true, but in this particular setup with avahi that the OP is using, he does in fact need to "route" that traffic to other subnets.

No, he does not need to route. He needs to have multicast enabled on all relevant interfaces. Link local packets are by definition on one local LAN only.

BTW, I just checked Wireshark, which I left running overnight. The MDNS packets show a hop limit of 1, which would prevent passing through a router. When it tries to route the hop limit would be decremented to 0, which would cause it to be discarded.

bmeeks

Guys, I put the term "route" in quotes for a reason. I fully understand you don't actually route link-local traffic. I think you are getting too excited trying to be technically correct, and forgetting the root issue in this case.

Yes, "repeat" is a more apt description. The point remains that link-local traffic on one local subnet needs to get repeated over into another local subnet to solve the problem. The evidence of that is that the devices work when he creates the rule to allow link-local traffic into the interface. The avahi daemon running on pfSense does that "repeating" across subnets for you. The real issue here is not "routing" in the pure sense of the term. The issue is that the default definition of the *NET built-in alias does not include some IPv6 multicast related addresses needed for the avahi package. He says the IPv4 version of that alias does include those addresses (but I have not checked to verify that).

johnpoz

@bmeeks said in fe80::/16 not included in interface networks?:

He says the IPv4 version of that alias does include those addresses (but I have not checked to verify that).

I don't think that is true to be honest.. The destination of mdns for IPv4 would be 224.0.0.251, that is not going to be included in the "net" alias for any interface. But if he has an any that would be ok.. The source of that traffic from a IPv4 client would be its IPv4 address.. So source would included in typical interface net alias listing the "net" as source..

The destination being multicast would be allowed in the default any rule on lan, which is prob duplicated on other interfaces creating..

To be honest does he really even need IPv6 mdns resolution.. IPv4 would normally work in your typical users setup without having to do any special rules.. Because the default rules would allow for the source net, and the dest via any..

Where you run into problems with source net for link-local, is client A is going to be in a different prefix anyway from client B - even if they are in the same L2..

Here is client of mine

inet6 fe80::3bc8:c970:a732:ac17  prefixlen 64  scopeid 0x20<link>

That is connected to pfsense interface but it has

inet6 fe80::208:a2ff:fe0c:e621%igb3 prefixlen 64 scopeid 0x4

Now if the client sent the mdns query from its GUA address - you don't have this problem.. But this whole discovery protocol is only meant for L2 anyway.. So other than a firewall/router you wouldn't normally run into the problems say client finding the printer..

I would think a "note" on the package on what rules you "might" want to add or edit if using avahi would be a way better idea then auto creation of rules..

bmeeks

@johnpoz said in fe80::/16 not included in interface networks?:

I would think a "note" on the package on what rules you "might" want to add or edit if using avahi would be a way better idea then auto creation of rules..

Yeah, my thought as well. Either include the subnet via a checkbox on the Advanced Setup page (like exists for enabling or blocking Bogons and such), or put it as a visible note in the package configuration for avahi. Maybe a checkbox selectable option in the package that would auto-create the rule for you and then remove it when the package is uninstalled.

I just think the thread got a bit derailed by the "routing" arguments and lost track of the original problem.

P.S. -- just saw this morning that my cable ISP (which was recently purchased by Vyve Broadband) moved my account to damn CGNAT overnight. Argh! I had avoided that for several years. So now I have that to bitch about and can forget "routing" of link-local stuff ... .

johnpoz

@bmeeks said in fe80::/16 not included in interface networks?:

my account to damn CGNAT overnight

Did they send out any notification that was "going" to happen??

bmeeks

@johnpoz said in fe80::/16 not included in interface networks?:

@bmeeks said in fe80::/16 not included in interface networks?:

my account to damn CGNAT overnight

Did they send out any notification that was "going" to happen??

Nope. Was surfing late last night around midnight and noticed external connectivity was lost. Happens once in a blue moon when they do maintenance, and I was about to retire for the night anyway. Got up this morning and saw new WAN IP notice emails in my Inbox from pfSense. Am now in a 24.49.195.0 subnet, while previously I was in a 38.x.x.x (if I am remembering that right). My firewall WAN IP is now a 100.64.x.x address.

johnpoz

@bmeeks said in fe80::/16 not included in interface networks?:

Am now in a 24.49.195.0 subnet

huh? So which is it you your 24.49.x.x or 100.x ?

So you got email from pfsense saying you switched to 24.49, and then later it switched to 100.x?

Oh - 24 is what your public is, they are natting you -- DUH!!! ;) heheeeh

Sucks dude - guess someone be shopping for new isp today... That's what I would be doing..

bmeeks

@johnpoz said in fe80::/16 not included in interface networks?:

@bmeeks said in fe80::/16 not included in interface networks?:

Am now in a 24.49.195.0 subnet

huh? So which is it you your 24.49.x.x or 100.x ?

So you got email from pfsense saying you switched to 24.49, and then later it switched to 100.x?

I got the email from the Dynamic DNS agent. The 100.64 address is on my WAN interface now on the firewall. So I assume the 24.49 is the real public IP in front of the CGNAT. Not sure what magic they pulled for that. I have my own domain (themeeks.net). I assume that is now resolving externally to the 24.49 IP, since that's what the Dynamic DNS agent reports.

johnpoz

Well maybe you find a better/cheaper ISP.. Bastards!

Little heads up would of been nice - give users time to leave, or maybe pay for public, etc.. Douche Baggy move to just do it without notice that is for sure.