fe80::/16 not included in interface networks?
-
I think there is some confusion with responses in this thread maybe due to incomplete reading of the original post.
The OP is using
avahito distribute multicast traffic across several local VLANs. Theavahidaemon runs on pfSense itself in this setup. So link local packets must hit the firewall on one VLAN and then get allowed in soavahican "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
avahithat 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 theavahidaemon. At least that's what he needs in his case withavahi, 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
avahipackage needs to be modifed such that it adds its own firewall rule to cover this situation, so the user doesn't have to. -
@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.
-
@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.
-
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
avahidaemon 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 theavahipackage. He says the IPv4 version of that alias does include those addresses (but I have not checked to verify that). -
@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 0x4Now 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..
-
@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 ...
. -
@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??
-
@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.
-
@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..
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.11 | Lab VMs 2.8, 24.11 -
@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.
-
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.
-
@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.
-
@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.
-
@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.
-
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.
Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
@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
avahidaemon, 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.
-
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/3over 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?
-
@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 to224.0.0.0/3over 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.
-
A ticket has been created!
-
@offstageroller Your networks and destinations listed in that redmine are way off..
Source:
fe80::/64not going to work.. that would be only this networkfe80: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..
