Advanced mDNS Forwarding Between Subnets Using IPFW Rules on macOS Server


2 views

When dealing with multiple subnets on a macOS Server gateway, mDNS (multicast DNS) packets won't automatically traverse between interfaces due to their multicast nature. This creates visibility issues for services like Bonjour/Avahi across different network segments.

Typical mDNS traffic uses:

  • Destination IP: 224.0.0.251
  • UDP Port: 5353
  • TTL typically set to 1 (won't cross routers)

Here's a working configuration for Snow Leopard Server acting as a gateway between en1 (192.168.1.0/24) and fw0 (192.168.10.0/24):

# Enable multicast forwarding
sysctl -w net.inet.ip.forwarding=1
sysctl -w net.inet.ip.mforwarding=1

# IPFW rules for bidirectional mDNS forwarding
ipfw add 1000 fwd 192.168.10.1 udp from 192.168.1.0/24 to 224.0.0.251,5353 in recv en1
ipfw add 1001 fwd 192.168.1.1 udp from 192.168.10.0/24 to 224.0.0.251,5353 in recv fw0

After applying the rules:

  1. Run tcpdump -i fw0 -n udp port 5353 on the gateway
  2. From a client in 192.168.1.0/24, use dns-sd -B _services._dns-sd._udp
  3. Check for packets appearing on the opposite interface
  • Ensure no firewall rules are blocking the forwarded traffic
  • Verify interface names match your actual configuration (en1 vs en0)
  • Check that multicast routing is enabled at kernel level
  • Confirm IPFW logging shows rule hits with ipfw -a list

For more complex scenarios, consider compiling mdnsrepeater:

git clone https://github.com/nitmir/mdns-repeater
cd mdns-repeater
make
sudo ./mdns-repeater en1 fw0

This daemon specifically handles mDNS forwarding between interfaces and includes TTL manipulation for better multicast handling.

When working with multicast DNS (mDNS) across subnets, the default behavior prevents propagation beyond the local network segment. This becomes problematic when you need devices in different subnets to discover services via Bonjour/ZeroConf protocols.

In this specific scenario:

  • Gateway: Snow Leopard Server
  • Subnet A: 192.168.1.0/24 (interface en1)
  • Subnet B: 192.168.10.0/24 (interface fw0)
  • mDNS address: 224.0.0.251 port 5353

Basic routing is confirmed working through ping and traceroute tests.

The attempted rule:
fwd 192.168.10.1 log udp from 192.168.1.0/24 to 224.0.0.251 recv en1
fails because:

  1. Multicast forwarding requires special handling
  2. The fwd action doesn't properly handle multicast destinations
  3. Interface-bound forwarding needs additional configuration

Here's the correct approach using ipfw:


# Enable multicast forwarding globally
sysctl -w net.inet.ip.mforwarding=1

# Create forwarding rules for both directions
ipfw add 1000 allow udp from 192.168.1.0/24 to 224.0.0.251 dst-port 5353 recv en1
ipfw add 1001 fwd 192.168.10.1 udp from 192.168.1.0/24 to 224.0.0.251 dst-port 5353 recv en1
ipfw add 1002 allow udp from 192.168.10.0/24 to 224.0.0.251 dst-port 5353 recv fw0
ipfw add 1003 fwd 192.168.1.1 udp from 192.168.10.0/24 to 224.0.0.251 dst-port 5353 recv fw0

For complete mDNS forwarding:

  1. Ensure no firewall rules block the multicast traffic
  2. Check that IGMP snooping isn't interfering on switches
  3. Consider TTL values (ipfw can modify these if needed)

To confirm the solution works:


# On Subnet A:
tcpdump -i en1 host 224.0.0.251 and port 5353

# On Subnet B:
tcpdump -i fw0 host 224.0.0.251 and port 5353

# Test with dns-sd:
dns-sd -B _services._dns-sd._udp

For more complex environments, consider:

  • avahi-daemon with reflector enabled
  • Dedicated mDNS reflector services
  • VLAN configuration changes