Avahi with IPv6 bug
-
@isaacfl said in Avahi with IPv6 bug:
Without my added firewall rule, the pfsense router does not respond on ipv6, and the device has to use ipv4 to get a DNS response.
Had you added a firewall rule that allowed the IPv4 traffic?
-
@dennypage said in Avahi with IPv6 bug:
@isaacfl said in Avahi with IPv6 bug:
Without my added firewall rule, the pfsense router does not respond on ipv6, and the device has to use ipv4 to get a DNS response.
Had you added a firewall rule that allowed the IPv4 traffic?
No, the ipv4 does not need a firewall rule. It passes it by default rules in the router. I would assume probably that is because normally in ipv4 the source address will be the same as the rest of the subnet.
In ipv6 the source address for multicast is almost always the link local address (fe80::) and there does not seem to be a default rule to allow link local addresses into the router.
-
@isaacfl said in Avahi with IPv6 bug:
@dennypage said in Avahi with IPv6 bug:
@isaacfl said in Avahi with IPv6 bug:
Without my added firewall rule, the pfsense router does not respond on ipv6, and the device has to use ipv4 to get a DNS response.
Had you added a firewall rule that allowed the IPv4 traffic?
No, the ipv4 does not need a firewall rule. It passes it by default rules in the router. I would assume probably that is because normally in ipv4 the source address will be the same as the rest of the subnet.
In ipv6 the source address for multicast is almost always the link local address (fe80::) and there does not seem to be a default rule to allow link local addresses into the router.
My main focus is ipv6, but I may have to look closer at my answer for ipv4. So it could be that I did have to write a rule for ipv4, but didn't realize I had.
The typical rule ipv4 , Pass "Lan Net" to "Any", would pass multicast also. The same rule in ipv6 would not, since the source address for multicast is not "Lan Net" but is Link Local.
I guess my question is, in a package such as Avahi, should the package make sure the correct firewall rules are in place to allow the required traffic into the router?
-
@isaacfl said in Avahi with IPv6 bug:
No, the ipv4 does not need a firewall rule. It passes it by default rules in the router. I would assume probably that is because normally in ipv4 the source address will be the same as the rest of the subnet.
In ipv6 the source address for multicast is almost always the link local address (fe80::) and there does not seem to be a default rule to allow link local addresses into the router.
My main focus is ipv6, but I may have to look closer at my answer for ipv4. So it could be that I did have to write a rule for ipv4, but didn't realize I had.
The typical rule ipv4 , Pass "Lan Net" to "Any", would pass multicast also. The same rule in ipv6 would not, since the source address for multicast is not "Lan Net" but is Link Local.
I think a typical rule would be a pass on the lan interface rather than on the lan net. If you have an interface allow rule with src of any and dst of any, it doesn't matter if it's a link local address. @jimp, please correct me if I'm wrong. My default allow rule for lan interfaces is protocol IPv4+IPv6, src any, dst any. I am not receiving errors in my firewall logs for link local packets and I am functional with IPv6 across subnets using reflection.
I'm a bit curious as to why your devices are only advertising via the link local address. My devices, both Apple and Linux (also Avahi), conduct discovery via their global addresses. The apple devices also send link local packets, but of course that should not cross subnets and could only be used to discover the firewall itself.
-
Having a rule on your LAN interfaces tab pass with a source of "any" is a bit dangerous. You don't want to allow anything in from your LAN that isn't supposed to be on your LAN. Using "LAN Net" is the safest way to allow things in general for all clients on the interface. Otherwise, someone could plugin a badly misconfigured device and cause problems, or you might unintentionally break things badly like attempting to policy route unrouteable traffic.
Technically speaking, link-local is not a part of "LAN Net", since every segment has its own link local and you may not want the same behavior for each segment. We do allow the basics for link local that IPv6 requires for normal operation but nothing beyond that automatically.
-
@jimp said in Avahi with IPv6 bug:
Having a rule on your LAN interfaces tab pass with a source of "any" is a bit dangerous. You don't want to allow anything in from your LAN that isn't supposed to be on your LAN. Using "LAN Net" is the safest way to allow things in general for all clients on the interface.
Using a source of LAN Net doesn't allow for routed infrastructure in the LAN, correct?
-
@dennypage said in Avahi with IPv6 bug:
@jimp said in Avahi with IPv6 bug:
Using a source of LAN Net doesn't allow for routed infrastructure in the LAN, correct?No, because that isn't a part of the subnet on the LAN interface. It does account for VIP networks that differ from from actual LAN subnet but that's as far as it goes.
The "<blah> Net" macros are "The subnet(s) directly configured on this interface", not "all networks reachable by this interface".
-
@jimp said in Avahi with IPv6 bug:
Having a rule on your LAN interfaces tab pass with a source of "any" is a bit dangerous. You don't want to allow anything in from your LAN that isn't supposed to be on your LAN. Using "LAN Net" is the safest way to allow things in general for all clients on the interface. Otherwise, someone could plugin a badly misconfigured device and cause problems, or you might unintentionally break things badly like attempting to policy route unrouteable traffic.
Technically speaking, link-local is not a part of "LAN Net", since every segment has its own link local and you may not want the same behavior for each segment. We do allow the basics for link local that IPv6 requires for normal operation but nothing beyond that automatically.
That is what I was getting at.
"LAN net" is the usual source address for pass rules to allow traffic in ipv4. As a side affect that allows ipv4 multicast into the router for Avahi to act on, since the source address in ipv4 multicast is a normal address.
In ipv6, "LAN net" does not include link local addresses. So the side affect is that multicast in pfsense gets blocked by the default rule, unless you explicitly write a rule to pass source (Link Local) Dest (multicast) for Avahi to act on.
I have a combination of Windows PCs, Apple iphones, ipads, and Apple TV, HP printers, and some thermostats, and garage door opener that always use link local for mDNS in ipv6.
This from watching on wireshark. I only see that multicast in ipv6 will use its link local address as the source. The global address multicast, I haven't seen any cases of it, other than the pfsense router itself.So on wire shark I see an iPhone send a mDNS multicast both on ipv4 and ipv6. pfsense will only respond on the ipv4 side. So pfsense avahi never saw the request via ipv6. If I write a rule to pass link local to multicast, then I see pfsense respond on both ipv4 and ipv6.
-
I guess it is sort of a philosophy on how the rules should work, but to me, if I am writing a "pass" rule, I think it may be going out to the WAN or to one of the other OPT1, etc. interfaces. I don't think of it being only into the router itself.
So most users, having a concern that they are going to be sending multicasts out into their other nets from link local (which is not allowed) are not going to write a pass rule to allow it. So Avahi in ipv6 will be broke for them.
-
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.