Bridging mDNS between networks connected via VPN

I have 2 subnets (remote_network and home_network) connected via VPN (openvpn).
I would like to bridge mDNS between those 2 subnets.

Rationale:

In my home network I have several servers running docker. It is setup in a such a way that I can access several of those docker services through a specific hostname (e.g. portainer1.local) that is resolved via mDNS.

FYI: I am using container docker-mdns-helper that is automatically publishing CNAME records pointing to the local host over multicast DNS using the Avahi daemon.

The problem is that those .local hostnames are not resolved when in the other subnet as mDNS traffic is not crossing subnets.

Request:
So what do I need to do to assure that those .local hostnames are also resolved in the other subnet.
This subnet is connected to my home LAN via a site-2-site VPN where

  • the openVPN client in my remote_network is running on an openWrt router and
  • the openVPN server in my home_network is running on an ubuntu server (intel nuc device).

Proposal
My proposal is to run smcroute both on my:

  • my openWrt router (= where the OpenVPN client is running) where it should route all mDNS traffic between interfaces br-lan and tun0
  • my ubuntu server (= where the OpenVPN server is running) where it should route all mDNS traffic between interfaces enp3s0 and tun0 (and maybe also wlp2s0 in both directions)

I guess I also need to add firewall rules to increase the TTL so that those mDNS packets are allowed to be forwarded.

Does this proposal makes sense and is complete ?
Are there any issues with this proposal ?

It looks like smcroute will not route mDNS packets.

see:

So the proposed approach is not viable.

Have a look at umds or avahi

https://blog.christophersmart.com/2020/03/30/resolving-mdns-across-vlans-with-avahi-on-openwrt/

Thanks I tried configuring avahi-daemon with reflector but when using tcpdump I don't see any traffic replicated on tun0 interface.

Here below the changes I made to my /etc/avahi/avahi-daemon.conf file:

root@nuc2:/etc/avahi# diff avahi-daemon.conf avahi-daemon.conf.20240126 
26,27c26,27
< use-ipv6=no
< allow-interfaces=enp3s0,tun0
---
> use-ipv6=yes
> #allow-interfaces=eth0
58,59c58,59
< enable-reflector=yes
< reflect-ipv=no
---
> #enable-reflector=no
> #reflect-ipv=no
root@nuc2:/etc/avahi# 

FYI this is the command tcpdump -v -i tun0 host 224.0.0.251 to sniff my tun0 interface. It is working when I directly ping on my tun0 interface using command ping -t 4 -I tun0 224.0.0.251 -p 5353 as you can see below:

root@nuc2:~# tcpdump -v -i tun0 host 224.0.0.251
tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
15:25:21.277838 IP (tos 0x0, ttl 4, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    nuc2.lan > mdns.mcast.net: ICMP echo request, id 54298, seq 1, length 64
15:25:22.293461 IP (tos 0x0, ttl 4, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    nuc2.lan > mdns.mcast.net: ICMP echo request, id 54298, seq 2, length 64
15:25:23.317441 IP (tos 0x0, ttl 4, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    nuc2.lan > mdns.mcast.net: ICMP echo request, id 54298, seq 3, length 64
15:25:24.341460 IP (tos 0x0, ttl 4, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    nuc2.lan > mdns.mcast.net: ICMP echo request, id 54298, seq 4, length 64
15:25:25.365443 IP (tos 0x0, ttl 4, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    nuc2.lan > mdns.mcast.net: ICMP echo request, id 54298, seq 5, length 64

but using the same tcpdump I don't see any real mDNS traffic replicated from enp3s0 interface. I have verified that there is mDNS traffic on that interface using similar tcpdump command.

Note that my openvpn / avahi-daemon server is running on an ubuntu server where the firewall doesn't seem to be active. So I don't think I need to set any firewall rules:

root@nuc2:/etc/avahi# ufw status
Status: inactive
root@nuc2:/etc/avahi# 

I think it is time to give up. :slight_smile:

So my conclusion:

  • If I want mDNS to work then I should configure OpenVPN in bridged mode instead of routed mode.