mDNS on tap0 (bridged openvpn)

[zmousm]

I have a bridged openvpn service at work. Occasionally I have two macs
on the same LAN connecting at the same time to this openvpn. I then
notice that MacOS runs mDNS on tap0 and discovers, among other things,
the other mac and its' services, which it has already discovered on
the LAN. This can also happen if, for example, you have both Airport
and Ethernet connected at the same time (to different broadcast
domains, in order to emulate the previous case). In that case,
interface priority (as set through network prefpane, service order) or
some default/built-in prioritization seems to kick in so that
mDNSResponder will prefer the address discovered through en0 for
resolving the other mac's .local hostname. However that doesn't seem
to be the case with tap0: it is usually the last address discovered
(because tap0 went up after en0 or en1) and it overrides the
previously discovered address, therefore when you try to ping this
host or use the advertised services, all the traffic will go through
the openvpn connection. This is probably not what you want.

I know this is rather off-topic for Tunnelblick, since the issue at
hand affects openvpn or more precisely the tap driver and the way it
is handled by MacOS (mDNSResponder). However I wanted to ask anyway if
anyone else has noticed this and if, by any chance, anyone knows if
there is a way to configure MacOS so that it assigns a lower priority
to tap0 or completely excludes it from mDNS. One solution which comes
to mind (a static route for 224.0.0.251/32) would not work nicely
(since this is a link-local group).

This issue has been observed on two macs running 10.5.8 and 10.6.5,
both using Tunnelblick 3.1.2/OpenVPN 2.1.4. Here are the steps to
verify it:

zmac:~ zmousm$ dscacheutil -q host -a name zmac2.local
name: zmac2.local
ipv6_address: fe80:5::cabc:c8ff:fed4:a471

name: zmac2.local
ip_address: v.p.n.91
ip_address: 192.168.1.93

zmac:~ zmousm$ ping zmac2.local
PING zmac2.local (v.p.n.91): 56 data bytes
64 bytes from v.p.n.91: icmp_seq=0 ttl=64 time=134.248 ms
[...]

zmac2:~ zmousm$ dscacheutil -q host -a name zmac.local
name: zmac.local
ipv6_address: fe80:5::21b:63ff:fe08:b7fa

name: zmac.local
ip_address: v.p.n.96
ip_address: 192.168.1.84

zmac2:~ zmousm$ ping zmac.local
PING zmac.local (v.p.n.96): 56 data bytes
64 bytes from v.p.n.96: icmp_seq=0 ttl=64 time=68.900 ms

[zmousm]

Answering my own question:

On Dec 27 2010, 2:40 pm, zmousm <zmo...@gmail.com> wrote:
> [...]

> I know this is rather off-topic for Tunnelblick, since the issue at
> hand affects openvpn or more precisely the tap driver and the way it
> is handled by MacOS (mDNSResponder). However I wanted to ask anyway if
> anyone else has noticed this and if, by any chance, anyone knows if
> there is a way to configure MacOS so that it assigns a lower priority
> to tap0 or completely excludes it from mDNS. One solution which comes
> to mind (a static route for 224.0.0.251/32) would not work nicely
> (since this is a link-local group).

mDNSResponder does not sort/prioritize records, it rather returns them
in the order they were discovered. In such a multi-homed environment
this usually means the first link to come up will prevail with regards
to name resolution.

What seems to make the difference in this case is that mDNSResponder
cache purge is triggered by Tunnelblick when tap0 comes up, after
which records previously discovered on other interfaces are re-added
to the cache most often (but not always) after records discovered on
tap0. These records are consequently returned first and this leads to
the observed behavior.

See this thread about mDNSResponder behavior:
http://lists.apple.com/archives/bonjour-dev//2011//Jan/msg00004.html

I have also posted a comment to the relevant RFE issue:
http://code.google.com/p/tunnelblick/issues/detail?id=154#c10

Best regards,
Z.