Disable mdns on management interface

[Sigurd]

Hi,

I have a pretty standard network setup with one interface (lagg0, 192.168.1.3) being used as the main interface for serving clients and a management interface (em0, 192.168.2.5), which is only used for some remote management work.

The issue I have is that the default interface registered in mdns is the management interface. So whenever you do ping server.local or ping6 server.local, it would ping the management interface instead. The same goes for ssh server.local. Now I know I could use the IP addresses or whatever, but my need is to be able to allow clients to simply use server.local to connect to the server.

I tried changing the avahi-daemon.config and adding 'deny-interfaces=em0', but that didn't do anything. In fact, I don't think FreeNAS is using avahi at all anymore.

Is there no simple way to remove the management interface from mdns? So that instead of:

# ping server.local
PING server.local (192.168.2.5): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1

It would resolve to 192.168.1.3 on the other interface?

Thanks very much!

 

[Sigurd]

Just to give a little explanation of why it's such a big issue for me. I have many Mac clients and they use Time Machine for backup. Now the network backup disk on FreeNAS gets resolved via mdns and I noticed the management (em0) interface gets boggled with Time Machine traffic.

I tried setting the interface options in the Services of AFP, but they don't seem to do a thing - the clients still connect through the management interface instead of the faster lagg0 dedicated to this.

How do people get around this? Does no one have separate management interfaces anymore? How do you set up Link Aggregation or troubleshoot network issues remotely? Thanks.

 

[dlavigne]

Please create a feature request at bugs.freenas.org and post the issue number here.

 

[anodos]

Just to give a little explanation of why it's such a big issue for me. I have many Mac clients and they use Time Machine for backup. Now the network backup disk on FreeNAS gets resolved via mdns and I noticed the management (em0) interface gets boggled with Time Machine traffic.

I tried setting the interface options in the Services of AFP, but they don't seem to do a thing - the clients still connect through the management interface instead of the faster lagg0 dedicated to this.

How do people get around this? Does no one have separate management interfaces anymore? How do you set up Link Aggregation or troubleshoot network issues remotely? Thanks.

I personally put the management interface on a separate network from client computers. This can be accomplished by doing something as simple as buying a $20 netgear switch from amazon. If you're running pfsense, you can connect the management switch to a different port on the firewall than your client network and then configure firewall rules to control access to the management interface.

 

[Sigurd]

I personally put the management interface on a separate network from client computers. This can be accomplished by doing something as simple as buying a $20 netgear switch from amazon. If you're running pfsense, you can connect the management switch to a different port on the firewall than your client network and then configure firewall rules to control access to the management interface.

Interesting how you did this... Would this solve the mdns issue? Is it "smart" enough to not advertise the IP address of the different network? How would the FreeNAS box know whether it was on a separate network or not?

Thanks!

 

[anodos]

Interesting how you did this... Would this solve the mdns issue? Is it "smart" enough to not advertise the IP address of the different network? How would the FreeNAS box know whether it was on a separate network or not?

Thanks!

Broadcast traffic only stays on the local network. The firewall also ensures that regular clients cannot access the management interface. It give a way to segment off the more sensitive parts of your network (ipmi, managenent NICs, etc). The network design is slightly more complex than just plugging everything into a single switch (another option is to put the management traffic on another VLAN). There will probably still be some mdns broadcast traffic on the management LAN, but it will be inconsequential. Having multiple NICs on the same LAN without lagging them is a somewhat broken configuration and so it's not terribly surprising you're having some problems.

 

[Sigurd]

Broadcast traffic only stays on the local network. The firewall also ensures that regular clients cannot access the management interface. It give a way to segment off the more sensitive parts of your network (ipmi, managenent NICs, etc). The network design is slightly more complex than just plugging everything into a single switch (another option is to put the management traffic on another VLAN). There will probably still be some mdns broadcast traffic on the management LAN, but it will be inconsequential. Having multiple NICs on the same LAN without lagging them is a somewhat broken configuration and so it's not terribly surprising you're having some problems.

Thanks, but I still don't quite see how that will solve this issue. Even if I unplug the management interface (and plug into a separate, unconnected switch just to keep the link up) and configure it not just on a different subnet but totally different ip, eg. 10.x.x.x, the mdns daemon still advertises the management interface, even though it's not accessible to anyone at this point.

So now it just looks like the host is down. I really believe this does need a new feature added. I don't see any way around this, unfortunately. :(

If there was a way to somehow change priority? The em0 interface is listed first in ifconfig so I assume it advertises that. But really, for example, it shouldn't advertise on interfaces where the service is explicitly not listening on in the service settings

 

[Sigurd]

Please create a feature request at bugs.freenas.org and post the issue number here.

I added a feature request here: https://bugs.freenas.org/issues/24941

There is also a bug related to this, where mdns continues to advertise services explicitly set to not listen on those interfaces: https://bugs.freenas.org/issues/24942

 

[Sigurd]

Broadcast traffic only stays on the local network.

Basically I mean that the broadcast traffic is transmitted on the local network, but the destination is not in the same subnet - which is in itself weird.

Imagine the server hostname 'fserve' has mgmt port of 10.10.10.1 and lagg0 is 192.168.1.1. It will advertise mdsn on 192.168.1.0/24 that fserve.local is 10.10.10.1, even though it's a completely different network. It should be advertising 192.168.1.1 on lagg0 and 10.10.10.1 on mgmt port. Doesn't that make more sense? Thanks.

 

[Ericloewe]

Basically I mean that the broadcast traffic is transmitted on the local network, but the destination is not in the same subnet - which is in itself weird.

Broadcast traffic can't have a destination, or rather, it's the broadcast address.

 

[anodos]

Basically I mean that the broadcast traffic is transmitted on the local network, but the destination is not in the same subnet - which is in itself weird.

Imagine the server hostname 'fserve' has mgmt port of 10.10.10.1 and lagg0 is 192.168.1.1. It will advertise mdsn on 192.168.1.0/24 that fserve.local is 10.10.10.1, even though it's a completely different network. It should be advertising 192.168.1.1 on lagg0 and 10.10.10.1 on mgmt port. Doesn't that make more sense? Thanks.

Perhaps try editing /etc/local/avahi/avahi-daemon.conf, adding the parameter allow-interfaces=lagg0 under the [ server ] heading, then restart mdnsd service mdnsd restart.

 

[Sigurd]

Broadcast traffic can't have a destination, or rather, it's the broadcast address.

Of course it doesn't. It was my attempt at getting the point across without having to type a lot of "formalities". Maybe it's because I work in the network business and design network protocols, so I jump around in slightly non-literal talk we do at work. Sorry if that's the case.

What I meant by that is that mdns is a resolution protocol that broadcasts the destination of a particular host (e.g. Host "myserver.local" destination is "10.10.10.1"). So m question is shouldn't the advertisement of the destination align to the interface netmask of that interface the broadcasts are sent from? What's the point of telling every interface on a system (maybe the system is part of 10 networks on 10 different interfaces) that it resolves only to 1 IP that will work on only 1 of those interfaces.

Shouldn't mdns send broadcasts that resolve to the IP set to the interface the broadcast is sent from? I believe the mDNSResponser on OS X does this. But on FreeNAS it just picks the first interface and advertises that. Sure it works if you only have one network, interface, or subnet you care about resolution. But otherwise mdns is not usable in other scenarios; basically anyone with multiple interfaces could have issues.

Does anyone understand my issue? I can't be the only one with it. Or perhaps I'm not explaining I well? I just want users on my network who see the server in the Finder just click and connect (while still having 2 interfaces enabled). Like any Linux server I had before that ran Avahi...

 

[Sigurd]

Perhaps try editing /etc/local/avahi/avahi-daemon.conf, adding the parameter allow-interfaces=lagg0 under the [ server ] heading, then restart mdnsd service mdnsd restart.

Thanks for the answer. If you read my OP, you'll see that I tried this already. It appears avahi is no longer used in FreeNAS. Can anyone confirm this? Thanks!

 

[Sigurd]

Does a moderator mind moving this thread to networking perhaps? I'm not really getting much answers here. The issue seems to be a bug/implementation restriction than a simple configuration/newbie problem.

Thanks mods! :)

 

[anodos]

Does a moderator mind moving this thread to networking perhaps? I'm not really getting much answers here. The issue seems to be a bug/implementation restriction than a simple configuration/newbie problem.

Thanks mods! :)

Sorry for not reading your initial post carefully. It does appear to be an implementation issue. I believe that libavahi is still used for mdns broadcasts, but actual config is handled by pybonjour / FreeNAS middleware. https://github.com/freenas/freenas/blob/master/src/freenas/usr/local/libexec/nas/register_mdns.py

The right place for this is on the bugtracker since there isn't an easy fix for a non-developer. Basically, I believe register_mdns.py needs to add the "interfaceIndex" flag with an appropriate value to the register command. Some gui component / database entry probably needs to be made for it too. You could probably manually edit the python script, but this would be rather hack-ish. I see you've already done that (create a bug report) and so you'll have to see how the dev team responds. :) https://bugs.freenas.org/issues/24942

 

[Ericloewe]

Does a moderator mind moving this thread to networking perhaps? I'm not really getting much answers here. The issue seems to be a bug/implementation restriction than a simple configuration/newbie problem.

Thanks mods! :)

Done.

 

[Sigurd]

Sorry for not reading your initial post carefully. It does appear to be an implementation issue. I believe that libavahi is still used for mdns broadcasts, but actual config is handled by pybonjour / FreeNAS middleware. https://github.com/freenas/freenas/blob/master/src/freenas/usr/local/libexec/nas/register_mdns.py

The right place for this is on the bugtracker since there isn't an easy fix for a non-developer. Basically, I believe register_mdns.py needs to add the "interfaceIndex" flag with an appropriate value to the register command. Some gui component / database entry probably needs to be made for it too. You could probably manually edit the python script, but this would be rather hack-ish. I see you've already done that (create a bug report) and so you'll have to see how the dev team responds. :) https://bugs.freenas.org/issues/24942

Thanks for pointing me in the right direction. That FreeNAS script seems to be responsible for registering the services. I think I'll wait for a proper fix, but it's good to know what file I can hack in case I need a workaround sooner. Thanks! :)

 

[rogerh]

Thanks, but I still don't quite see how that will solve this issue. Even if I unplug the management interface (and plug into a separate, unconnected switch just to keep the link up) and configure it not just on a different subnet but totally different ip, eg. 10.x.x.x, the mdns daemon still advertises the management interface, even though it's not accessible to anyone at this point.

So now it just looks like the host is down. I really believe this does need a new feature added. I don't see any way around this, unfortunately. :(

If there was a way to somehow change priority? The em0 interface is listed first in ifconfig so I assume it advertises that. But really, for example, it shouldn't advertise on interfaces where the service is explicitly not listening on in the service settings

But how does mdns know that there is no routing between these networks? If there was, then perhaps advertising the single interface on which it is supposed to be listening across other subnets might be exactly what you wanted it to do?

 

[tobiasbp]

I'm also bit by this bug. mdns brodcasts only on my iSCSI-network. Also, what is being broadcast is, that the AFP-server is on the iSCSI NIC, even though the AFP-server does not listen on that interface. You really need to be able to choose what IS is being broadcast.

I testet out the latest varsion of register_mdns.py (Aug. 30th 2017) here:
https://github.com/freenas/freenas/...8f0ab8c#diff-5761fd01ace9069b52e570d958fd77a8

This will broadcast on all NICs, but the IP being broadcast is still the"first" NIC (In my case the iSCSI NIC. So that update does not help me much.

 

[tobiasbp]

Is there no simple way to remove the management interface from mdns?

I have been playing around with dns-sd.

Broadcast that the AFP server called TimeMachine is on IP_OF_CHOICE:

Code:

dns-sd -P TimeMachine _afpovertcp._tcp "" 548 TimeMachine.local IP_OF_CHOICE

Broadcast that the Apple time machine enabled share called "TimeMachine (USER)" is available on the server TimeMachine:

Code:

dns-sd -R "TimeMachine" "_adisk._tcp." "local" "9" "dk0=adVF=0x81,adVN=TimeMachine (BJ)"

Is there a way to announce more shares with a single command, or do I need to run one of these commands for each share I wonder?

My sources:
https://developer.apple.com/library...hineRequirements/TimeMachineRequirements.html
https://dreness.com/blog/archives/48