Viscosity, OpenVPN, utun Interfaces and Bonjour/mDNS Fun

[peckrob]

Hi! Long time Viscosity user and love the program.

I recently switched from using tap interfaces on my pfSense OpenVPN server to using tun. The reasons are complex, but basically come down to something breaking in pfSsense 2.3 which made my older setup not work and wanting to add VPN support for my various iDevices which won't support tap interfaces.

Anyways, I've bee struggling to get Bonjour/mDNS to work over the utun interface. I already have avahi set up in pfSense to reflect traffic across the VPN and I can verify using tcpdump that this is working. I can see the packets arriving from the VPN locally so everything should be working, but isn't. I don't see any of my home network LAN machines when I'm remote.

I think the problem is that mDNSResponder is silently dropping these packets. You can see in the source code for mDNSResponsder that, at around line 792, Apple specifically excludes point-to-point links from mDNSResponder, which is what utun is.

There's a VPN client for jailbroken iDevices out there that does something interesting to solve this problem. They have a patch for OpenVPN that uses pcap to reinject those packets to the local interface so that mDNSResponder picks them up.

It would be really neat if Viscosity had similar functionality. Alternatively, if there's another way to solve this I would love to know about it.

Thanks!

[James]

Hi peckrob,

You're correct in that Bonjour/mDNS will not work over a uTun interface. Multicast traffic such as this isn't typically sent over routed tunnels, but it could be made to work with the old-style tun interface. Unfortunately in this case OS X is explicitly dropping it for utun interfaces, which Viscosity switched to using in 1.6.

We have played around in the past with re-injecting the multicast packets into the primary or loopback network interfaces when Viscosity made the switch to utun. But we found intercepting these, and rewriting the headers accordingly, had a performance penalty and required loading an additional kext. As TAP style connections are available for desktop platforms we decided it was unnecessary anyway (mobile platforms do not support TAP, which is why things like TAP emulation on TUN devices exist).

If you stick with a tun setup your only option is to run a Bonjour/mDNS proxy instead. This means running the client on your computer, and the server on the VPN server. There are server-side only solutions too, such as "mdns-proxy", that remap the .local domain to a unicast domain (such as .vpn) that can be resolved using normal DNS lookups (but not for discovery).

However there should be no reason why you can't run a TAP server in addition to a TUN server on your pfSense box. We have a number of pfSense setups for testing that run both simultaneously. Your mobile devices can connect to the tun-based server (say, running on port 1194), while your desktop connections could connect to a tap-based server (running on port 1195).

Cheers,
James