Avahi with IPv6 bug
-
But on IPv4, multicast is sourced from the IPv4 address on the client, which is a part of the LAN subnet configured on the firewall. We do not allow link-local IPv4 (APIPA, 169.254.x.x) traffic either as a part of "LAN net".
There is an argument either way here but by default, in my opinion, link-local can't exit the LAN net so it shouldn't be passed off its segment. It should not be allowed by "LAN Net to any" rules since the destination would be too permissive for local traffic. That is more consistent to me than suddenly allowing anything from fe80 when it was not explicitly passed before. The only time this actually matters is when a service on the firewall needs to receive this multicast traffic. Other hosts on the segment already receive it.
Trying to argue that a firewall should be even more permissive by default is a bad stance. We allow what the base protocols need to function, beyond that is up to the user. In the Avahi case, I still hold that it is the responsibility of the Avahi package to automatically handle the rule to pass to Avahi from link-local to multicast on the ports it needs. Avahi is not a part of the base system, so it doesn't make sense that the base system should pass traffic to its destination or allow traffic to any multicast destination other than what IPv6 itself and firewall services need to function.
-
@jimp said in Avahi with IPv6 bug:
But on IPv4, multicast is sourced from the IPv4 address on the client, which is a part of the LAN subnet configured on the firewall. We do not allow link-local IPv4 (APIPA, 169.254.x.x) traffic either as a part of "LAN net".
There is an argument either way here but by default, in my opinion, link-local can't exit the LAN net so it shouldn't be passed off its segment. It should not be allowed by "LAN Net to any" rules since the destination would be too permissive for local traffic. That is more consistent to me than suddenly allowing anything from fe80 when it was not explicitly passed before. The only time this actually matters is when a service on the firewall needs to receive this multicast traffic. Other hosts on the segment already receive it.
Trying to argue that a firewall should be even more permissive by default is a bad stance. We allow what the base protocols need to function, beyond that is up to the user. In the Avahi case, I still hold that it is the responsibility of the Avahi package to automatically handle the rule to pass to Avahi from link-local to multicast on the ports it needs. Avahi is not a part of the base system, so it doesn't make sense that the base system should pass traffic to its destination or allow traffic to any multicast destination other than what IPv6 itself and firewall services need to function.
Ideally, there would be a mechanism to have a rule that says:
Pass -- Source:Link Local ---> Dest:AvahiDaemonBut if you can't do that then you are right, it should be limited.
However, if I as a user write a pass rule, to explicitly allow Source:LinkLocal --> Multicast, how do I know that it doesn't get pushed out to WAN, OPT1, etc? I would assume the router itself will stop it, but it is an assumption.
-
I agree that it should not be permissive by default. I also agree that by definition nothing should be allowed to go out another interface that arrived on a link local address.
What this means with regard to Avahi is that link local messages can only be used to discover the firewall itself. Specifically, it allows dynamic discovery of the following:
- LAN host name <--> IP address mapping of the firewall, which is of very marginal value given that is fixed information and available via DNS.
- IP address list and host name mapping for all other interfaces on the firewall. Ill advised from a security pov.
- Host OS info for the firewall. Also ill advised from a security pov.
- Presence of the ssh/sftp service. Note that Avahi advertises this even if the ssh service is not enabled/reachable.
When you delve into what Avahi actually discloses, I think most folk would disable local publish on the firewall. If you do that, link local really offers no value.
-
@isaacfl said in Avahi with IPv6 bug:
Ideally, there would be a mechanism to have a rule that says:
Pass -- Source:Link Local ---> Dest:AvahiDaemonThere could be a "Link Local" macro (for IPv6 anyhow) but it's only mildly more useful than making an alias or using the fe80 block directly.
As for that destination, there is no concept of a macro for a specific protocol+address+port combination.
And that's a ton of work for what could be handled by Avahi internally with its own rule, where it's most relevant. All packages can setup a hook to insert their own rules. It's perfectly suited for this and the intent of that mechanism.
However, if I as a user write a pass rule, to explicitly allow Source:LinkLocal --> Multicast, how do I know that it doesn't get pushed out to WAN, OPT1, etc? I would assume the router itself will stop it, but it is an assumption.
Unless you set a gateway on a rule, nothing gets "pushed" anywhere. And you'd have the same problem, only worse because it's easier to set automatically without intending to if fe80 was a part of "LAN Net". Do you know how many people have a gateway group set on the default LAN to any rule? Tons. The potential for breakage is huge with a change like that.
The choices really are:
- Someone could manually make a rule on their own as-is with minimal risk aside from maybe shooting their own foot with setting a gateway (what we have now).
- Avahi can make its own safe and proper rules easily in the package using built-in features (ideal)
- Break thousands of installations and allow far too much traffic through by changing the meaning of "LAN net".
-
@jimp said in Avahi with IPv6 bug:
The choices really are:
- Someone could manually make a rule on their own as-is with minimal risk aside from maybe shooting their own foot with setting a gateway (what we have now).
- Avahi can make its own safe and proper rules easily in the package using built-in features (ideal)
- Break thousands of installations and allow far too much traffic through by changing the meaning of "LAN net".
My opinion would be that each package, in this case Avahi, should have its own very explicit rule as the package developer should know exactly which port etc is needed for the package to function.
I would also say pfsense should NOT include link local in the "LAN net" even though at first glance it seems like the easy answer and would maybe be ok, since the router should silently drop the packets anyway, but there are always unintended consequences.
There will probably be more issues found as people start to use ipv6 exclusively since I am finding that ipv6 uses link local addresses for a lot of things, especially multicast. Dual stack hides a lot of implantation errors in ipv6, since it can fall back to ipv4 now.
-
@jimp Just brainstorming, but one idea I was thinking of was including the appropriate multicast into "This firewall (self)".
So you could have a rule such that:
Pass -- Source:LinkLocal -> Dest:This firewall -- port:5353You wouldn't have to include every well known multicast, but just the ones that are actively serviced by the router. For Avahi, I think it is ff02::fb.
-
But "multicast" is not "this firewall", it's multicast.
Also "This Firewall (self)" is a pf macro, not a list we craft in pfSense code. We can't alter what it covers.
-
@jimp said in Avahi with IPv6 bug:
But "multicast" is not "this firewall", it's multicast.
Also "This Firewall (self)" is a pf macro, not a list we craft in pfSense code. We can't alter what it covers.
I think I agree with what you are saying but technically, if the firewall has "subscribed" to a multicast address, then it kind of is a "firewall" address.
So the question is how is the best way to allow the packet into the firewall, so that it still makes sense that it isn't going anywhere else.
Right now, I have a rule that passes ipv6 Link_Local_Address to Multicast. If someone else were to come in and see this, they would think "That's not legal. You can't pass Link Local addresses, out of the subnet" so I put a comment, required by Avahi on the rule. Maybe that is only way.
-
It's more broken to reappropriate existing macros and terms to include things they should not.
Anyone who saw a rule with a destination of "multicast" and actually thought it would leave the segment needs reeducated. That's not confusing at all. (And in the future with something like PIM might actually be allowed)
-
@isaacfl said in Avahi with IPv6 bug:
Right now, I have a rule that passes ipv6 Link_Local_Address to Multicast. If someone else were to come in and see this, they would think "That's not legal. You can't pass Link Local addresses, out of the subnet" so I put a comment, required by Avahi on the rule. Maybe that is only way.
Let's pop up a level. Can you explain what it is you are trying to accomplish with using Avahi? Is it providing information about the firewall itself? Or is it allowing dns-sd to function across subnets?
-
@dennypage said in Avahi with IPv6 bug:
@isaacfl said in Avahi with IPv6 bug:
Right now, I have a rule that passes ipv6 Link_Local_Address to Multicast. If someone else were to come in and see this, they would think "That's not legal. You can't pass Link Local addresses, out of the subnet" so I put a comment, required by Avahi on the rule. Maybe that is only way.
Let's pop up a level. Can you explain what it is you are trying to accomplish with using Avahi? Is it providing information about the firewall itself? Or is it allowing dns-sd to function across subnets?
I think it is just dns across subnets, but not sure. I am trying to get all of the Apple based home automation type things to work across the subnets. I have my iphones, ipads, appletvs wirelessly connected to one subnet. I have my thermostats, garage door openers, smart switches etc. in a different subnet. My windows pcs and printers in a 3rd subnet.
So with Avahi working properly I can print something from the iPhone in one subnet to printer in a different subnet. Also Apple TV can play a movie from a PC which is running iTunes.
It does seem to be working with Avahi, but I notice it is falling back to ipv4 a lot. Whereas before I subnetted the devices it was ipv6 exclusively. So trying to isolate the issues.
-
@jimp said in Avahi with IPv6 bug:
It's more broken to reappropriate existing macros and terms to include things they should not.
Anyone who saw a rule with a destination of "multicast" and actually thought it would leave the segment needs reeducated. That's not confusing at all. (And in the future with something like PIM might actually be allowed)
I guess it is possible using a global address to multicast across the internet using ipv6. Beyond my skills on how to do that though.
-
I stand corrected. I do have some devices that are using link local addresses only even though global addresses have been assigned.
-
@jimp said in Avahi with IPv6 bug:
The choices really are:
Someone could manually make a rule on their own as-is with minimal risk aside from maybe shooting their own foot with setting a gateway (what we have now).
So, is this how one would manually make a rule to address this? I created this on each subnet that Avahi has set under interfaces.
-
@costanzo That's about what I made mine but also added source fe80:: as /10 with port 5353