Hi all. I'm trying to set up a VPN between two locations, with routing (not bridging) between the two networks (so I'm using openvpn on tun0, not tap0). Then I'd like to get mDNS forwarding across the VPN. This gives me a happy medium between routed and bridged subnets.

I had this working before under kamikaze, and liked the resulting behavior. I've upgraded everything to backfire, and am trying to get back to the same point.

At this point I've installed and configured openvpn, installed avahi-daemon, but I'm not seeing any mDNS traffic across the VPN link.

I know that I need to add "allow-point-to-point=yes" to the [server] section of /etc/avahi/avahi-daemon.conf; I've done that. And I've enabled avahi's reflector with "enable-reflector=yes".

If I start avahi-daemon from the command line as "avahi-daemon --debug" so I can see its debug output on the console, I see it start up and "joining mDNS multicast group" for the br-lan, eth1 and tun0 interfaces, as I'd expect.  (Without allow-point-to-point, it ignores tun0.)

However, if at this point I watch mDNS traffic on the VPN link with "tcpdump -i tun0 udp port 5353", and do mDNS lookups from another machine on my LAN, tcpdump sees no traffic.

Sanity checks:

If I do "tcpdump -i br-lan udp port 5353" on the router and do mDNS lookups from another machine, tcpdump sees the requests (on the lan, regardless of whether avahi-daemon is running or how it's configured).

If I do "tcpdump -i eth1 udp port 5353" on the router and do mDNS lookups from another machine, tcpdump sees the requests (only if avahi-daemon is running and the reflector is enabled and I haven't denied it from using eth1); this proves that avahi's reflector is active, and both necessary and sufficient for 5353 traffic on eth1.

However, nothing I've tried has resulted in any udp port 5353 traffic whatsoever on the vpn link.

I have a hunch, possibly wildly incorrect, that avahi doesn't like something about the tun0 interface, which ifconfig shows as

root@wormhole:/etc/avahi# ifconfig tun0
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

I don't remember the link having empty encap and hwaddr under kamikaze, though I could be misremembering.

Anyway. Anyone have this working, know what's wrong or what to change? Thanks in advance.

Any ideas on this? I'm still having the same problem, and can confirm the results above still hold (I can get avahi to forward mDNS from br-lan to eth1, but not from br-lan to tun0).

Of course I don't actually want it forwarding mDNS onto eth1, which is the WAN link to my ISP, so normally I run avahi configured with deny-interfaces=eth1.

Anyone using avahi to forward mDNS across a routed openvpn link, and/or know how I could get this to work?

Well, "tun0" sounds like its a routed tunnel and not a bridged one. mDNS is designed to operate with broadcasts which aren't propagated across P-t-P links. Establish a bridged (tap) OpenVPN tunnel instead and mDNS/Avahi should work.

I really don't want to bridge the networks, though -- the VPN is across a WAN link with limited throughput and higher latency compared to my LAN. I don't mind traffic intentionally crossing that link, but I don't want everything bridged.

That's where avahi comes in -- it's got mDNS reflector functionality to repeat mDNS across networks where broadcast doesn't reach. (If I was using OpenVPN in bridged/tap configuration, I wouldn't need avahi; mDNS would just work with its default broadcast nature.)

So with avahi running, and its reflector enabled (which it isn't by default), and told to use P-t-P networks (again, not the default but available as an option), I should be able to propagate mDNS across the routed tunnel.

I had this working fine with whiterussian a few years ago, but have been unable to get it working in backfire.

I tried strace on avahi-daemon and eventually just compiled it from source and started modifying the source to see what it's really doing.

The reflector does a bunch of sendmsg(), one per active interface, and the sendmsg() on eth0 and eth1 succeeds but the one for tun0 always returns EINVAL.

Turns out that's because it's using 192.168.255.2 as the source address (192.168.255.0/24 is the subnet associated with tun0, but the IP address of the router on that subnet is 192.168.255.1, not 192.168.255.2).

I didn't know that was the problem, but it turns out the clue is in the log messages from avahi-daemon at startup:

Joining mDNS multicast group on interface tun0.IPv4 with address 192.168.255.2.
New relevant interface tun0.IPv4 for mDNS.

So the problem is that avahi is picking the wrong address -- I'll take this up with the avahi project directly to see if this is configurable, a bug, etc.

Also, avahi-daemon --debug should print more debugging information to daemon_log(LOG_DEBUG), but that doesn't seem to go anywhere -- I had to hack up the source to see the messages printed that way.

Thread at http://lists.freedesktop.org/archives/a … 01969.html -- hopefully there's a good answer. (I tried on my x86 Debian box and got the same behavior, so this isn't peculiar to OpenWRT, but I did successfully use a setup like this under whiterussian a few years ago.)

(Last edited by metamatt on 10 Jan 2011, 18:54)

Well, I found what looks like an avahi bug and an easy fix -- http://lists.freedesktop.org/archives/a … 01970.html. Though it's a little hard to be sure since the offending code dates to the beginning of the avahi project, and it's hard to believe it's always been wrong.

The avahi bug tracker is down and nobody but me has posted to their mailing list in almost 3 weeks, so I'm not having much luck getting anyone over there to confirm the bug or accept/reject the patch.

metamatt,

I'm interested in this as well. I will follow your posts for updates.

Best Regards.

Good news -- avahi 0.6.29 was just released, and includes my patch for this problem.

Hopefully when openwrt backfire 10.03-1 is released, it'll use this version of avahi.

I updated the avahi package.

Great, thanks.

I have the same problem as you are describing in your first post metamatt, but I'm using tomato 1.28 and avahi 0.6.30-1

ipkg info avahi gives me:

Package: avahi
Version: 0.6.30-1
Depends: expat, libdaemon, dbus
Status: install user installed
Section: net
Architecture: mipsel
maintainer: NSLU2 Linux <nslu2-linux@yahoogroups.com>
MD5Sum: 98051af4c2f5a79a82298c905a805233
Size: 375308
Filename: avahi_0.6.30-1_mipsel.ipk
Source: http://avahi.org/download/avahi-0.6.30.tar.gz
Description: A system for multicast DNS service discovery, an implementation of Zeroconf.

Successfully terminated.

and this is my ipkg.conf file:

#Uncomment the following line for native packages feed (if any)
#src/gz native http://ipkg.nslu2-linux.org/feeds/optware/ddwrt/native/stable
src/gz optware http://ipkg.nslu2-linux.org/feeds/optware/ddwrt/cross/stable
dest /opt/ /
#option verbose-wget

Any suggestions?

(Last edited by erlis on 31 Aug 2011, 13:21)

Hmm, avahi is a zeroconf-implementation, here you find similar stuff:  http://wiki.openwrt.org/doc/howto/user.beginner.lazy

And some very little howto-content for avahi in this article:  http://wiki.openwrt.org/doc/howto/p910n … s.optional

I'd like to address security concerns in the first article and anytime you can write an own article on howto install and configure avahi

None of those guides addresses mirroring of mdns/bonjour/zeroconf from br0 (lan+wlan) to a pptp tunnel. That is what I'm trying to achieve (basically I want to access iTunes over 3G on my iPhone both for "home sharing" but also for the remote app and why not even my AirPort).

This post here seem interesting but I could not get either my iTunes lib nor my airport to show up in my iPhone: http://irq5.wordpress.com/2011/01/02/md … s-subnets/

(Last edited by erlis on 31 Aug 2011, 14:36)

Yes. Today I found yet another bug in Avahi. Or rather, it seems that Matt's bug does not work in combination with IPv6 (which we're running), and to fix the IPv6-part they, unfortunately, mixed up two variables so that now Matt's patch was reversed.

See http://avahi.org/ticket/355 for a quick fix.

For myself, I patched a - rather old - Avahi 0.6.25 in Ubuntu 10.04 LTS, which, after patching, seems to work perfectly on my OpenVPN ptp link. (If anyone wants the patch, please drop me a line - preferrably through the e-mail interface; I'll try to get the patch for 10.04 somewhere on the web).