How to Enable mDNS/Bonjour Service Discovery Across OpenVPN Tunnels

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.