How to Enable mDNS/Bonjour Service Discovery Across OpenVPN Tunnels


2 views

When working with OpenVPN in routed mode (the default configuration), multicast DNS (mDNS) services like Apple's Bonjour won't automatically propagate across VPN tunnels. This occurs because:

  • mDNS uses UDP port 5353 with multicast addresses (224.0.0.251 for IPv4, FF02::FB for IPv6)
  • Multicast traffic isn't forwarded between subnets by default
  • OpenVPN's TUN (routed) mode creates separate broadcast domains

Here are three technical solutions to enable service discovery:

1. Implementing TAP Bridging

Replace TUN with TAP device to create a bridged network:

# In server.conf
dev tap
server-bridge 192.168.0.1 255.255.255.0 192.168.0.128 192.168.0.254

2. mDNS Reflector/Forwarder Setup

Install and configure avahi-daemon as a reflector:

# On the VPN server
apt install avahi-daemon

# /etc/avahi/avahi-daemon.conf
[server]
use-ipv4=yes
enable-reflector=yes

3. Client-Side Multicast Routing

For macOS clients, create a multicast route:

sudo route -nv add -net 224.0.0.0/4 -interface utun0

For a mixed environment with both TUN and Bonjour requirements:

# Install necessary packages
apt install avahi-daemon bridge-utils

# Create bridge configuration
auto br0
iface br0 inet static
    address 192.168.0.1
    netmask 255.255.255.0
    bridge_ports eth0 tap0

# OpenVPN config
dev tap0
server-bridge 192.168.0.1 255.255.255.0 192.168.0.128 192.168.0.254

After implementation, verify with:

# On macOS
dns-sd -B _afpovertcp._tcp

# On Linux
avahi-browse -a -r

The solution should now allow automatic discovery of AFP shares and other mDNS services through the VPN tunnel.

When connecting through OpenVPN's default routed configuration (TUN mode), macOS devices face a fundamental limitation: Bonjour/mDNS services don't propagate across different subnets. This occurs because:

  • mDNS uses UDP port 5353 with a TTL of 1 (never routed beyond local subnet)
  • OpenVPN's NAT creates separate broadcast domains
  • Apple's implementation filters remote mDNS responses

Option 1: Bridged Mode (TAP) Configuration

Modify your OpenVPN server configuration:

# /etc/openvpn/server.conf
dev tap0
server-bridge 192.168.0.1 255.255.255.0 192.168.0.100 192.168.0.200
push "route-gateway 192.168.0.1"

Key requirements:

  • Client must support TAP devices (Tunnelblick does)
  • Server must have bridge-utils installed
  • Requires Ethernet bridging on server:
# Create bridge on Debian
apt-get install bridge-utils
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 tap0
ifconfig eth0 0.0.0.0 up
ifconfig br0 192.168.0.1 netmask 255.255.255.0 up

Option 2: mDNS Reflector/Forwarder

For systems where bridging isn't feasible, implement Avahi:

# On OpenVPN server
apt-get install avahi-daemon
nano /etc/avahi/avahi-daemon.conf
# Set:
allow-interfaces=eth0,tun0
enable-reflector=yes

Add firewall rules to forward mDNS traffic:

iptables -A FORWARD -i tun0 -o eth0 -p udp --dport 5353 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -p udp --dport 5353 -j ACCEPT

For better discovery reliability, add these to client configuration:

# Add to OpenVPN client config
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Create custom mDNS responder configuration:

# /etc/mdnsresponder.conf
[Global]
BrowseDomains = local, 0.168.192.in-addr.arpa.

After implementation, verify with:

# On macOS terminal
dns-sd -B _afpovertcp._tcp
dns-sd -B _smb._tcp

For advanced debugging:

tcpdump -i tun0 port 5353 -vv
avahi-browse -a -r -t