Bug #10251
closed
Avahi-daemon choosing VIP instead of interface IP
0%
Description
I have pfblockerng-devel installed and configured with DNSBL on most of my interfaces and VLANs. I also have avahi-daemon working as a mDNS reflector between a few VLANs and it works well, when the issue below is not occuring.
For those who are not aware, pfblockerng creates a VIP address on the LAN interface for sending black listed DNS entries to, it's the sinkhole that returns an error back to the requestor, web browser usually, that what they want is not available. This allows a fast reply to the requestor so it does not have to timeout.
The issue is that when avahi-daemon is configured for mdns reflection, it chooses the IP of the VIP for a selected interface instead of the primary interface IP address. Obviously this defeats the purpose of reflecting mdns traffic to the LAN network and instead it reflects the mdns traffic to the VIP network, which by definition, goes no where. The work around was to bind the VIP to another VLAN interface, one which I do not want mdns reflection to occur and thus have not selected for avahi-daemon usage.
This works as a work around, but it would preferred that avahi-daemon config generation would check if an IP it attempts to use is a VIP and if so, alert or have a check box on the web gui to select use VIP if available for the interface, this way avahi-daemon can rely on the user to make the determination of which bound IP to use.
Updated by Jim Pingle about 4 years ago
- Status changed from New to Not a Bug
- Affected Version deleted (
2.1)
Avahi operates using interfaces and selects the addresses automatically. All the config can do is tell it to use or not use an interface. There is no config directive available for Avahi which would influence which addresses it uses on an interface. Thus, there is nothing actionable here as a bug or missing feature for pfSense.
Ideally, pfBlocker should bind its VIP to localhost, not a user interface, which would avoid these problems entirely. It's not the first time that default pfBlocker behavior has caused a problem with other services.
Updated by Chris Roadfeldt about 4 years ago
Jim Pingle wrote:
Avahi operates using interfaces and selects the addresses automatically. All the config can do is tell it to use or not use an interface. There is no config directive available for Avahi which would influence which addresses it uses on an interface. Thus, there is nothing actionable here as a bug or missing feature for pfSense.
Ideally, pfBlocker should bind its VIP to localhost, not a user interface, which would avoid these problems entirely. It's not the first time that default pfBlocker behavior has caused a problem with other services.
That was quick! :)
Thanks Jim, fair point, as it is I've done that in my config as well. Can this be moved s over to pfblockerng?
Updated by Chris Roadfeldt about 4 years ago
Chris Roadfeldt wrote:
Jim Pingle wrote:
Avahi operates using interfaces and selects the addresses automatically. All the config can do is tell it to use or not use an interface. There is no config directive available for Avahi which would influence which addresses it uses on an interface. Thus, there is nothing actionable here as a bug or missing feature for pfSense.
Ideally, pfBlocker should bind its VIP to localhost, not a user interface, which would avoid these problems entirely. It's not the first time that default pfBlocker behavior has caused a problem with other services.
That was quick! :)
Thanks Jim, fair point, as it is I've done that in my config as well. Can this be moved s over to pfblockerng?
Opened https://redmine.pfsense.org/issues/10253
Thanks again Jim.