What's new

How to make mDNS work with openVPN site to site connection?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

evlo

Regular Contributor
My goal is to be able to pass mDNS trough open VPN connection.

additional questions:
how can I see mDNS devices on the network?
what mDNS routing is on the router and is there configuration regarding mDNS?

I know almost nothing about this stuff and multicast in general.
 
You could use a bridged (TAP) tunnel. That will let anything through, to the point you'd have to block DHCP to prevent configuration by the wrong server between the two sites.

Of course, there may be other issues if both sides are using different IP networks (I assume that's the case), such as a lack of security if both sides don't fully trust each other.
 
What router? What firmware version?


Install avahi-browse on one of your LAN clients.
ax68u 386.7_2

You could use a bridged (TAP) tunnel. That will let anything through, to the point you'd have to block DHCP to prevent configuration by the wrong server between the two sites.

Of course, there may be other issues if both sides are using different IP networks (I assume that's the case), such as a lack of security if both sides don't fully trust each other.
I was wondering if setup with tun and maybe smcreoute would be possible, but if not, how can i block DHCP to stay on each site? On the gateway I disabled firewalld so everything can go trough.

This is what i found on the gateway regarding the multicast stuff, again, i do not understand it :(

IP networks, i guess this is what you mean by that, are
192.168.50.* one site
192.168.51.* other site
or like both are connected to the internet? :)

Code:
[root@openvpn ~]# netstat -g
IPv6/IPv4 Group Memberships
Interface       RefCnt Group
--------------- ------ ---------------------
lo              1      all-systems.mcast.net
enp0s3          1      all-systems.mcast.net
tun0            1      all-systems.mcast.net
lo              1      ff02::1
lo              1      ff01::1
enp0s3          1      ff02::1
enp0s3          1      ff01::1
tun0            1      ff02::1
tun0            1      ff01::1

maybe - it makes sense I can block both incoming and outgoing on that interface on asus side and don't care about the other, now to make the TAP thing work.
Code:
Jul 26 09:11:10 openvpn systemd-udevd[126604]: Could not generate persistent MAC address for tap0: No such file or directory
Jul 26 09:11:10 openvpn openvpn[126603]: /sbin/ip addr add dev tap0 10.200.0.1/-1 broadcast 255.255.255.253
Jul 26 09:11:10 openvpn openvpn[126607]: Error: any valid prefix is expected rather than "10.200.0.1/-1".
Jul 26 09:11:10 openvpn openvpn[126603]: Linux ip addr add failed: external program exited with error status: 1
....
Code:
Options error: --server-bridge and --secret cannot be used together (you must use SSL/TLS keys)
guess that means I would need to set up CA chain etc.

Getting it work over TUN certainly seems like a way to go now.
 
Last edited:
So I did setup CA and VPN does connect using TAP, but now the routing does not work, i guess because of the bridge mode, should i just remove the route to my network on the site other then my home?

also in web ui of the router it says
Connected (Local: 0.0.0.0 - Internet not redirected)

0.0.0.0 seems a tiny bit weird :)
 
99% of the time, you should be using a routed (TUN) tunnel, NOT a bridged (TAP) tunnel. And that's because you typically are connecting to another site you either don't control and fully trust, or perhaps you do, but it's impractical to deal w/ having the same IP network on each side. You now need to make sure you don't duplicate IP assignments. A routed tunnel is much easier to manage if you need to filter out access. You just define appropriate IP rules on each side.

Of course, the problem for me at this point is we have ZERO knowledge of the big picture here. I was just trying to think a bit outside the box here in case a bridged tunnel *might* be easier. But again, I have NO CLUE of the purpose of the tunnel, the parties involved, etc. It could be utterly impractical for many reasons. But in a vacuum of information, it's at least worth mentioning.

Years ago I owned two homes, each of which was managing its own private IP network (e.g., 192.168.99.0/24 and 10.0.10.0/24). It wasn't practical for me to manage the two sides using the same IP network and a bridged tunnel, so I used a site-to-site routed tunnel. But there were times where having a bridged tunnel was still useful. I was using FT (FreshTomato) at the time, so I created a new bridge w/ single port VLAN + VAP (virtual AP) that managed a bridged (TAP) tunnel to the other home. Anytime I connected a device to that wired port or VAP, it effectively became part of the remote IP network, as if it was actually connected directly to its switch/AP. Yet the rest of the network had access to the other over the routed (TUN) tunnel.

IOW, I could *selectively* places devices on the bridged (TAP) tunnel as needed. Those devices could still access their own local private network, but it would be *remotely* via the routed tunnel on the other side!! As I said, those devices behaved exactly as if they were *physically* located on the other network.

Problem w/ ASUS firmware (stock or Merlin) is it doesn't natively support user-defined VLANs, bridges, etc. For all practical purposes, you'd have to use additional routers and daisy-chained them behind their respective primary routers to manage that OpenVPN bridged tunnel, ideally using something that *does* offer those features.

But again, all these ideas may be impractical in certain circumstances.

The problem I see w/ your current approach is that you have a bridged tunnel that still requires routing. That sort of defeats the purpose. You'd have to multihome the primary router on each side w/ the other's IP network, so the traffic could be routed between them, except it would be over the same logical ethernet network. Again, sort of defeats the purpose since you still end up being routed wrt each other. But at least ethernet (layer 2) broadcasts (if NOT IP broadcasts) would be accessible between each side. But mDNS is a layer 3 (IP) broadcast, so you end up right back where you started, basically needing something like the Avahi replicator.
 
The problem I see w/ your current approach is that you have a bridged tunnel that still requires routing.
exactly and as you wrote above - same subnet = pains (even if having

so did anyone succeded with smcroute / routed / avahi reflector - or some other thing to route mDNS? After this TAP ordal I kinda thinking that i should gave up on mDNS trough VPN.

1658839141940.png
 
Last edited:
Why bother with mDNS at all (even on the LAN). It's just an unnecessary pain in the a$$ as far as I'm concerned and the first thing I disable/remove on my network devices.
 
This is typically a case of wanting your cake and eat it too. You want isolation of IOT devices, but only sometimes. For example, you want your Chromecast-enabled devices on IOT to still work and be accessible from the private network. Out comes the Avahi replicator to the rescue. But I never attempted it over the VPN.
 
Last edited:

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top