fe80::/16 not included in interface networks?

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.

bmeeks

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

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

Yeah on the NAT.

Likely "no" on shopping for a new ISP for now. My only other choice is a local wireless ISP operator.

But it's a small town, so I will drop by the office and see if the tech will accomodate me. I knew the former tech (he grew up two houses down from me and was friends with my kids), and he moved me off CGNAT when I originally ordered the service. But he has moved on to something else at a bank.

JKnott

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

My firewall WAN IP is now a 100.64.x.x address

Yep, that's definitely CGNAT.

Do they also provide IPv6? Some ISPs provide IPv4 over IPv6.

bmeeks

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

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

My firewall WAN IP is now a 100.64.x.x address

Yep, that's definitely CGNAT.

Do they also provide IPv6? Some ISPs provide IPv4 over IPv6.

Nope, no IPv6 here yet. I have a Hurricane Electric setup, but I've had that tunnel out of service for the last year and a half. I have not gone to the trouble of working around the Netflix IPv6 issues caused by HE tunnels, so I just disabled the tunnel for a while during visits by my grandkids. Their iOS devices were trying to use IPv6 when I had it set up on my LAN and on the WAN via the HE tunnel. Took the expedient way out of that and just turned off IPv6. Really don't need it for now.

jimp

Back to the original question here:

fe80:: link-local addresses are NOT a part of "<interface> Net" because they shouldn't need to hit the firewall except for services on the firewall which must respond to requests from those addresses. pfSense also doesn't allow IPv4 link-local addresses for similar reasons, though IPv6 uses them more effectively.

Link-local traffic doesn't get routed so it shouldn't get a free pass through the firewall rules.

Services on the firewall which use IPv6 link-local traffic add their own rules to pass it internally.

Avahi is an add-on package, not a part of the base system, and does not create its own rules. This is partly for security reasons, and partly because nobody has submitted code to do so.

So there are a few ways around it:

Add your own rules narrow enough to only allow Avahi traffic on the interfaces you want (most secure)
Add your own rules to pass link-local traffic willy-nilly (not secure but maybe also not too harmful, but not a best practice)
Find someone who will add an optional feature to the Avahi package to add its own automatic firewall rules to pass in the traffic it wants to see.

bmeeks

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

Back to the original question here:

fe80:: link-local addresses are NOT a part of "<interface> Net" because they shouldn't need to hit the firewall except for services on the firewall which must respond to requests from those addresses. pfSense also doesn't allow IPv4 link-local addresses for similar reasons, though IPv6 uses them more effectively.

Link-local traffic doesn't get routed so it shouldn't get a free pass through the firewall rules.

Services on the firewall which use IPv6 link-local traffic add their own rules to pass it internally.

Avahi is an add-on package, not a part of the base system, and does not create its own rules. This is partly for security reasons, and partly because nobody has submitted code to do so.

So there are a few ways around it:

Add your own rules narrow enough to only allow Avahi traffic on the interfaces you want (most secure)

Add your own rules to pass link-local traffic willy-nilly (not secure but maybe also not too harmful, but not a best practice)

Find someone who will add an optional feature to the Avahi package to add its own automatic firewall rules to pass in the traffic it wants to see.

The third option sounds best to me. Maybe as a checkbox in the package that defaults to "on". That way a really paranoid security admin can disable automatic rules and create their own.

And @jimp stated it best. It's not really a case of routing said traffic, but rather of allowing it into the interface so the avahi daemon, or any other service that wants it, can see it. Having the packages/services that need to see such traffic create their own rules sounds the most logical. The idea in my mind being to make it reasonably secure, but at the same time somewhat "works out of the box".

In the majority of consumer households, we would be talking about just a huge flat network with IoT and everything else on one Layer 2. More security conscious folks use pfSense and try to isolate IoT and similar things using VLANs or physically separate interfaces. But then you run into trouble trying to make some modern technology work because it expects a flat L2 network. Enter tools such as Avahi to help out. But depending on the skill level of the admin, there's a little under-the-hood magic required to get it working.

OffstageRoller

@bmeeks

The third option sounds good to me as well. That would work similar to the pfBlockerNG package where you select the interfaces, and it creates floating roles for those.

This is no longer a problem for me, since I saw the traffic blocked and created these rules. But I imagine for most users that enable avahi on pfSense, and don't disable support for IPv6, assume it "just works." Avahi will probably work fine for them since it will use/revert to IPv4, but they'll assume both IPv4 and IPv6 are both working, where IPv6 is getting rejected.

I think a little more hand holding for this package would be helpful. Might even be worth creating default rules for IPv4 as well to allow the "* net" to communicate to 224.0.0.0/3 over port 5353.

I can create a feature ticket in Redmine for the Avahi package and reference this thread if we think that would be best?

bmeeks

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

@bmeeks
I think a little more hand holding for this package would be helpful. Might even be worth creating default rules for IPv4 as well to allow the "* net" to communicate to 224.0.0.0/3 over port 5353.

I can create a feature ticket in Redmine for the Avahi package and reference this thread if we think that would be best?

I think a Redmine Feature Request is a good idea. Perhaps someone will pick it up and submit the necessary change.

OffstageRoller

A ticket has been created!

https://redmine.pfsense.org/issues/12329

johnpoz

@offstageroller Your networks and destinations listed in that redmine are way off..

Source: fe80::/64 not going to work.. that would be only this network

fe80:0000:0000:0000:0000:0000:0000:0000/64

fe80:0000:0000:0000:0000:0000:0000:0000 - fe80:0000:0000:0000:ffff:ffff:ffff:ffff

What link local would fall into that? If goal is to allow any link-local the range would be fe80::/10

And your destination of 224.0.0.0/3 is not very good idea.. Why would you allow all of that space when mdns ipv4 is only ever going to go to 224.0.0.251.

No offense meant but is it possible your issues just stem from a lack of understanding of address space both in the ipv4 and ipv6 area? Where did you come up with 224.0.0.0/3? That includes a shit ton of actual unicast space..

OffstageRoller

@johnpoz

I originally used fe80::/16, which you told me was incorrect (which is true... it should be fe80::/10 like you mentioned). But then you said this:

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?

The way I interpreted that, was that using /10 also wasn't ideal, and using a /64 would use less space (and would be closer to a * net). Both /64 and /10 both work, so I can update the Redmine ticket if you think /10 should be the correct default.

224.0.0.0/3 is the multicast address space. Originally I created individual rules for each specific address, but decided to "simplify" doing that and instead creating an alias that included the entire multicast address space. My alias is called MULTICAST_SUBNET, and includes the network of 224.0.0.0/3 which is technically correct right? I use more then just mDNS requests fall into that subnet. But you are 100% correct that I should update that ticket and make it 224.0.0.251, since that is unique to mDNS and is the only destination required for Avahi.

Something else related to this thread... some of my devices on some VLANS make requests for SSDP. They have an IPv4 destination of 239.255.255.250. However, IPv6 traffic is blocked by default unless this rule is created:

source: fe80::/10
destination: ff02::c
Port: 1900

Another example would be the same source and destination above, but for port 3702 which is WSDD (used by a Windows 10 device).

These are examples of traffic where I would assume (incorrectly based on your feedback) the * net source rule to cover when IPv6 is enabled on on a network.

And no offense taken. I'm far from an expert here. I've already solved this myself, although you may see the way I've done it is less then ideal. I created this post to hopefully help others.