Messages

1

General Discussion / Re: Guide to mDNS/Apple Bonjour with udpbroadcastrelay

« on: January 22, 2023, 05:05:30 am »

Glad this was helpful to someone! I haven't tried homekit myself but I'd imagine this approach of tracing what traffic reaches where should help iron out any extra configuration that needs to be layered on. In any case, I'd be interested to hear your findings.

2

General Discussion / Guide to mDNS/Apple Bonjour with udpbroadcastrelay

« on: December 23, 2022, 10:20:14 pm »

I *finally* got Bonjour working across vlans and thought I'd share my findings. There's no shortage of discussion on this but I hope that pulling together a bunch of context into one place will help others debug their setup.

Install the os-udpbroadcastrelay plugin via System > Firewall > Plugins. (I had no luck with mdns-repeater btw.)

Before configuring udpbroadcastrelay in the UI, it helps to first run it in debug mode on the command line. Visibility on what's happening is key. After it's all working, it's easy to translate this to the UI. ssh into your opnsense box and run this (substituting in your vlan interfaces of course):

Code: [Select]

udpbroadcastrelay --id 1 --port 5353 --dev igb0_vlan10 --dev igb0_vlan50 --multicast 224.0.0.251 -d
In my case, I'm trying to use atvremote (from pyatv) to connect to my Apple TV 4K. For debugging purposes, on my laptop I'd run this:

Code: [Select]

atvremote scan
After the scan (or whatever discovery process you're using), flip back to your opnsense shell and you should see the mdns requests logged on both the requesting vlan (atvremote at 192.168.10.102) and the responding vlan (apple tv at 192.168.50.:

Code: [Select]

<- [ 192.168.10.102:5353 -> 224.0.0.251:5353 (iface=9 len=156 tos=0x00 DSCP=0 ttl=10)
-> [ 192.168.10.102:5353 -> 224.0.0.251:5353 (iface=11 len=156 tos=0x10 DSCP=4 ttl=10)

[..snip..]

<- [ 192.168.50.8:5353 -> 224.0.0.251:5353 (iface=11 len=1312 tos=0x00 DSCP=0 ttl=255)
-> [ 192.168.50.8:5353 -> 224.0.0.251:5353 (iface=9 len=1312 tos=0x10 DSCP=4 ttl=255)

I've attached a screenshot of wireshark showing the *working* mdns requests and responses captured when the atvremote scan runs. Notice that the responder sends the mdns response directly to the requesting ip, in my example that's 192.168.50.8 -> 192.168.10.102.

If the packets aren't showing up in udpbroadcastrelay, assuming you have the right interfaces set, the problem should be the firewall. Each host that should be able to initiate requests needs to allow udp to 224.0.0.251 on port 5353.

If the packets show up in udpbroadcastrelay but the responses aren't reaching your machine, the problem is again likely the firewall. Ensure you allow udp from the responder to your requester on any port.

Remember your machine's firewall will also need to allow the udp packet from 192.168.50.8 to reach the python process. On macos this can manifest as seeing the mdns response in wireshark but not in atvremote (or whatever app you're using for discovery).

Note that for mdns, udpbroadcastrelay should not have a 'source address' set: leave it blank. Otherwise the mdns responses will be sent to 224.0.0.251 instead of the requester's ip, and even though your machine may see them in wireshark, they don't seem to be recognized as responses to our queries.

Finally for anyone else with Unifi APs and switches, you've probably seen advice for enabling Multicast Management and IGMP Snooping. I found these made no difference.

Hope that helps!