Repeating mDNS/Bonjour requests from eth0 through a tunnel (tun0)

Question

To start off, I am quite new at both networking and Unix/Ubuntu/Linux distros. Just a warning, for any setup/code may look a bit ugly.

Basically, my end goal is to successfully AirPlay Mirror to a remote Ubuntu server from my iPhone on a different wifi network or on LTE.

TL;DR: With mdns-repeater/avahi-daemon and OpenVPN, I still cannot pass the mDNS requests from eth0 to tun0.

To start, I knew I needed an AirPlay receiver for Ubuntu/Linux/Unix based OS that supported mirroring (and hopefully open-source). I found a couple, most for Mac OS/Windows, or didn't support mirroring at all. After a little more searching I found Slave in the Magic Mirror, an open-source Linux AirPlay server/receiver that runs and works (based on my debugging, as I have no physical access to the server I ran it on).

Now, I knew AirPlay only ran over LAN (at the time not understanding how Bonjour only works on the same subnet) so I looked into some VPN options. OpenVPN seemed to be the most flexible and easiest to set up. To speed things up and to guarantee that I don't make any mistakes setting OpenVPN up I used a pre-made script from here. Tested and worked flawlessly, VPN connects without DNS leaks and all traffic routes successfully through VPN.

I have my VPN to act as if my device is on the LAN of my server now, and I have Slave in the Magic Mirror (AirPlay server) running successfully. So it should just work now, right? Not surprisingly, it did not, as I did not understand the AirPlay server actually sends out mDNS/Bonjour requests (or probes? The real term is slipping my mind right now..). As a home, conventional user, since these mDNS requests are zeroconf (zero configuration), this is amazing! But as an enterprise or business user, this is difficult to get working across VLAN's.

Through research I came up with the end result that I need some kind of mDNS repeater/proxy/bridge type setup. I ended up with the mDNS repeater. There were two programs I attempted to use.

avahi-daemon

Avahi seemed to be the most talked about and most documented, so I decided to use that. I edited the config file to allow Config location /etc/avahi/avahi-daemon.conf

[reflector]
enable-reflector=yes

and

[server]
allow-point-to-point=yes

As explained here and here.

Running the Avahi Daemon in debug mode (avahi-daemon --debug) seemed to work at first glance but as soon as Slave in the Magic Mirror (running on eth0 interface, OpenVPN running on tun0 interface) is ran it sees the mDNS packets somehow but always outputs a bunch of these:

Received packet from invalid interface.
Received packet from invalid interface.
Received packet from invalid interface.
Received packet from invalid interface.

Forcing Avahi to use only eth0 and tun0, upon many other changes and settings will always output this.

To verify it was not just an output bug I ran

tcpdump -i eth0 udp port 5353 and tcpdump -i tun0 udp port 5353 (port where mDNS requests go through) eth0 successfully receives packets from filter while tun0 receives none. So not an output bug. I even tried it on port 7000 (port that AirPlay server listens on for Mirroring)

With no success with Avahi, I suspected it might just be because it hasn't been updated since 2011.

mdns-repeater

With no config files or setup needed, mdns-repeater is the next option I took. And it seems this is working correctly. Run mdns-repeater with

mdns-repeater eth0 tun0 -f

Just add the interfaces you want to have the requests repeated over and -f for foreground/debugging. That's it! I ran Slave in the Magic Mirror and mdns-repeater successfully detected and repeated the requests (according to its' logs at least). But sadly, running the same tcpdump commands as seen above, the requests are still not going through the tunnel (tun0).

Now from my debugging I can only conclude it is either the cause of iptables/firewall or OpenVPN filtering the ports or requests somehow. Finding nothing in the config related to filtering in OpenVPN, I moved on to my iptables theory. But running iptables -L brings nothing, literally no rules are in iptables.

Knowing little about iptables, I do not know if this is the cause. For my own debugging I added every different iptables rule I could find related to anything with allowing mDNS / Bonjour / AirPlay. Nothing seems to be of help.

Any and all help is appreciated! I know this was a long read, I did not want any small issue falling through.

TL;DR: With mdns-repeater/avahi-daemon and OpenVPN, I still cannot pass the mDNS requests from eth0 to tun0.

Solution 1

You could, instead of repeating the mDNS requests, use dns-sd to create a proxy service record. If you run dns-sd -Z _raop._tcp on the network with the mDNS record available, you should get something like this:

Browsing for _raop._tcp
DATE: ---Mon 21 May 2018---
 1:29:38.528  ...STARTING...

; To direct clients to browse a different domain, substitute that domain in place of '@'
lb._dns-sd._udp                                 PTR     @

; In the list of services below, the SRV records will typically reference dot-local Multicast DNS names.
; When transferring this zone file data to your unicast DNS server, you'll need to replace those dot-local
; names with the correct fully-qualified (unicast) domain name of the target host offering the service.


_raop._tcp                                      PTR     054D66DDCDBB@Gavin\032speakers._raop._tcp
054D66DDCDBB@Gavin\032speakers._raop._tcp       SRV     0 0 5000 boxen.local. ; Replace with unicast FQDN of target host
054D66DDCDBB@Gavin\032speakers._raop._tcp       TXT     "pw=false" "txtvers=1" "vn=3" "sr=44100" "ss=16" "ch=2" "cn=0,1" "et=0,1" "ek=1" "sm=false" "tp=UDP"

You can use this to craft a proxy record to direct AirPlay clients to your server. For my example connection, I would use...

dns-sd -P '054D66DDCDBB@Gavin speakers' '_raop._tcp' 'local.' 'boxen.local' '192.0.2.23' "pw=false" "txtvers=1" "vn=3" "sr=44100" "ss=16" "ch=2" "cn=0,1" "et=0,1" "ek=1" "sm=false" "tp=UDP"

...where 192.0.2.23 is replaced with the IP address of your airplay server and everything else is copied from what you get from dns-sd -Z. With this, AirPlay clients should be able to see your server.

Note: the dns-sd command that I'm using here comes with macOS. As far as I'm aware it isn't available for linux, but you could probably do something similar with avahi.

Solution 2

I hope you are well Gavin. Your answer is relevant for TimeMachine. If you want to backup over VPN, you’ll need to gather the information for the proxy advertisement like the following.

$ host JustinsTimeCapsule2
JustinsTimeCapsule2 has address 192.168.123.232
$ dns-sd -Z _smb._tcp
Browsing for _smb._tcp
DATE: ---Thu 12 Aug 2021---
15:14:25.561  ...STARTING...

; To direct clients to browse a different domain, substitute that domain in place of '@'
lb._dns-sd._udp                                 PTR     @

; In the list of services below, the SRV records will typically reference dot-local Multicast DNS names.
; When transferring this zone file data to your unicast DNS server, you'll need to replace those dot-local
; names with the correct fully-qualified (unicast) domain name of the target host offering the service.

_smb._tcp                                       PTR     JustinsTimeCapsule2._smb._tcp
JustinsTimeCapsule2._smb._tcp                   SRV     0 0 445 JustinsTimeCapsule2.local. ; Replace with unicast FQDN of target host
JustinsTimeCapsule2._smb._tcp                   TXT     “”
...

And create the relevant proxy advertisement on the host attached to VPN.

$ dns-sd -P 'JustinsTimeCapsule2' '_smb._tcp' 'local.' 445 JustinsTimeCapsule2.local 192.168.123.232
Registering Service JustinsTimeCapsule2._smb._tcp.local. host JustinsTimeCapsule2.local port 445
DATE: ---Thu 12 Aug 2021---
15:36:32.896  ...STARTING...
15:36:33.646  Got a reply for record JustinsTimeCapsule2.local: Name now registered and active
15:36:33.646  Got a reply for service JustinsTimeCapsule2._smb._tcp.local.: Name now registered and active

Click the Time Machine icon in the menu bar, then choose Back Up Now. Bob’s your uncle.

Comments

[Spiff]

The prescribed way to do DNS Service Discovery across separate broadcast domains is to use unicast, not multicast, DNS. Apple calls this "Wide Area Bonjour". dns-sd via unicast DNS requires the use on DNS Dynamic Update. Apple shipped (and open-sourced, I believe) a POSIX daemon called "dnsextd" to run alongside BIND's "named" DNS server and implement DNS Dynamic Update and the other things necessary for unicast dns-sd to work.

[Pyrology]

@Spiff would you be willing to get into contact and help me set this up? I would be highly grateful.

[Pyrology]

@Spiff as well, the couple sources that I mentioned actually have users having success with this exact method, did they perhaps not mention something else they are running?

[Spiff]

I'm sure people are having success with relaying mDNS beyond the intended multicast boundaries, but it's still kind of swimming upstream. For more information on setting up unicast dns-sd, see dns-sd.org. It's a site from Stuart Cheshire, who is both the creator of Bonjour (née Rendezvous) at Apple, and the IETF/IAB member who shepherded mDNS and DNS-SD into standards-track RFCs via the IETF ZeroConf working group.