Anyone have a guide for getting Airplay working across subnets with avahi?
-
Recently locked down my home LAN and created a guest wireless LAN with a separate SSID. pfSense is doing the routing. I have two Airport Express devices in the LAN that I use to stream audio around the house. I'm looking to have these devices available to guests to stream audio. It's not an uncommon occurrence that I have an impromptu get-together and a guest wants to DJ. It's easy with iPhones, etc, when they're on the same subnet. But I don't want my guests on my LAN, hence the guest network.
So I installed avahi, and that has at least enabled me to see (via Airport Utility and Airfoil) the Airport Express devices. I have (for now) all traffic to the Airport Express devices allowed in the pfSense firewall rules. But that's as far as the connectivity appears to go. With Airfoil, when I try to stream, I eventually get a connection timeout. With Airport Utility, I can see the devices but can't configure them.
Wondering who might have this working and what you had to do to get there.
-
"Recently locked down my home LAN and created a guest wireless LAN with a separate SSID. pfSense is doing the routing"
So how exactly did you do this? So your SSID on their own vlan with vlan capable AP and switches? You have the AP with different ssid connected direct to a interface in pfsense? Something else?
What exactly are you rules on what interfaces? What are the networks in play?
-
"Recently locked down my home LAN and created a guest wireless LAN with a separate SSID. pfSense is doing the routing"
So how exactly did you do this? So your SSID on their own vlan with vlan capable AP and switches? You have the AP with different ssid connected direct to a interface in pfsense? Something else?
What exactly are you rules on what interfaces? What are the networks in play?
Yes. I have two private networks, each in its own VLAN. I'm using managed switches and a Ubituiti AP. Private LAN is 10.22.44.0/24 and guest lan is 10.22.11.0/26.
The specific rule I mentioned is on the guest interface and allows all ipv4 traffic from the 10.22.11.0/26 to an alias that contains the ip addresses of the two airport express devices. It's placed higher in the ruleset than a later rule that blocks all traffic from the guest network to the private network.
-
So, more experimentation. I've found that I can indeed discover and manage the devices using Airport Utility on my mac from the guest network but not reliably. I can ping them. Looking at a pcap of an attempted connection from Airfoil I see what appears to me to be an authentication attempt.
And then I found this:
"Bonjour (and mDNS) work perfectly well across multiple subnets so long as your router is configured to support (i.e. route) multicast traffic. I use Bonjour on a constant basis across three subnets with both Mac and Windows platforms for a variety of service location purposes (printing, file sharing, streaming media) and have no problems whatsoever.
The AirTunes limitation you're referring to is an Apple policy decision, not a technical issue. It appears they've restricted iTunes<–>Airport streaming media connectivity to connections that originate and terminate on the same subnet. I assume they feel it's a mechanism to help enforce digital rights management.
Just to summarize: I routinely print to my Airport Express units across subnets, and share my iTunes music library to non-AirPort devices on different subnets; I just don't (can't) share my iTunes music library to an Airport Express on a different subnet."
So perhaps it's simply not going to work and I need to look for another solution.
-
"Bonjour (and mDNS) work perfectly well across multiple subnets so long as your router is configured to support (i.e. route) multicast traffic."
I've ran into something similar when trying to use my child's tablet (on a KidsNet VLAN) to stream videos on a WDTV or Chromecast (Main VLAN). I was able to get it to work using the IGMP Proxy but only tried it as a proof of concept. I do recall it fills the system log with a ton of messages.
-
Thanks. I'll look into it. Regardless, this topic is probably not suited for the packages forum since avahi appears to be doing its job. I think it's just the Apple devices throwing some of their proprietary nonsense in to play. Absolute worst case I can connect them both via wireless (right now one is wired and one is wireless) and just switch them to the guest network when needed, so that they are hanging out in the same subnet as my guest devices.
Thanks for the help, everyone.
-
Apple chose to send airplay packets with a TTL of 2. That limits airplay to one hop no matter what you do with avahi.
-
Has anyone had success in this kind of scenario using out-of-the-box pfSense, and if so, could they post the exact rules/setup they used to successfully get this situation to work by routing multicast correctly (and modding the TTL if applicable).
As an aside, I've been playing with a different approach and had some success. To save repetition the details are at https://redmine.pfsense.org/issues/2170 , in a nutshell there's a tiny but active port called "mdns-repeater" which relays mDNS multicasts (used for Airplay discovery) across a set of interfaces, and is ideal for Airplay. Because pfSense reworks the FreeBSD pkg repo system (see release notes) I couldn't install it with pkg install, but it turns out you only need one file from it, so I manually put the file on my router in the correct folder, modified the rules to allow both IFs to receive UDP on 224.0.0.251:5353 (and IPv6 equivalent if needed), and it works fine - all multicasts received on one are sent out from the other. So now I can see friends' iPhones/iPads connected to WLAN/OPT1 seeking printers via Airplay multicast, and getting valid data back from printers on the LAN interface, although they aren't get completing their dialog (TTL issues?). So I am hopeful that with a little more work it'll be fully working. if anyone seeing this can figure out the last part of the puzzle, let me know!
-
I opened the UDP ports 49152-65535 and I was able to get audio (music and podcasts) working from my iphone on network 1 to my AppleTV on network 2. Unfortunately I was not able to play a video podcast from my iPhone to my Apple TV. Any suggestions?
I found this on https://community.ui.com/questions/Airplay-across-VLAN-How-to-do/0362cb7f-f38c-43ba-b10e-c2e5cc9dbe16. In particular in addition to the suggestions on the Netgate Forums I found this on https://community.ui.com/questions/Airplay-across-VLAN-How-to-do/0362cb7f-f38c-43ba-b10e-c2e5cc9dbe16
******morganelevates
a year ago
(Solution below)
I was having all sorts of issues with Airplay across VLAN's.
My topology is two VLAN's, one for privilieged devices called LAN, and another for IOT, called MISC.
I have my airport express and apple TV on MISC.
I had set up the mDNS repeater, and opened port for mDNS to go both ways. Opened established/related both ways. Other than that, traffic from MISC is blocked to LAN.
Playing from a device on MISC to either audio output device works.
Playing from a device on LAN to one on MISC did not work.
It does see the devices on MISC, but initiating an airplay stream always failed after a 20s pause.
I opened all the standard airplay ports (listed in the prior post) from MISC to LAN.
Still not working.
Then I experimented with various port ranges.
When I opened the private port range 49152-65535 to both tcp and udp traffic, it worked.
The only 3 rules I ended up needing to keep it working were:- allow established/related back into LAN from MISC
- allow mDNS traffic into LAN from MISC
- allow TCP/UDP traffic from MISC to LAN ports 49152-65535
I wanted to share this solution because after hours of reading posts here, multiple times, I never saw this range of callback ports mentioned.******
I hope it helps someone save some time and frustration!
-
@derelict Thanks for this interesting piece of information. I guess I'm going to do some packet capturing
I'm a bit puzzled though as my AirPlay capable SmartTV works just fine as playback device for the iOS Podcast App, for example. However, I'm not able to do a full screen cast onto the TV. The TV screen goes dark for a moment, the iOS device reports a connection issue to the TV and the original TV screen/content is back again. The iOS device is on the
LAN
subnet and the SmartTV is on theIOT
subnet.Here's my
Avahi
configuration (active on both theLAN
andIOT
subnet):
Here are my
LAN
rules:
And here are my
IOT
rules:
As mentioned above, I don't understand why a Podcast playback works and a full screen cast does not.
BR
-
Selected interfaces should be selected, it looks likes you haven't selected them, for me it looks like you have selected DMZ and SERVER
-
@ciscox That's a side effect of the screenshot. The interfaces
LAN
andIOT
are indeed selected and I seemDNS
traffic on theIOT
interface andTCP
traffic between the iOS device and the TV. If I deactivate theAvahi
service the iOS device cannot detect the TV as AirPlay target. Re-activating the service makes the TV detectable again.Unfortunately my packet capture did not reveal anything useful. The
mDNS
TTLs are 255 and the minimum TTL of theTCP
traffic between the iOS device and the TV is 63. Other than a singleICMP
destination port59536
unreachable message (which makes sense as traffic originating from theIOT
subnet to theLAN
subnet is blocked) I don't see anything pointing to the issue causing the failing connectionWhen the iOS device is in the same subnet as the TV the AirPlay screen cast works as expected of course (without
Avahi
). -
@CyBiS Hi, the IOT rule must be on top of the 53 DNS rule. Since it is blocking it as you have it. Check it out!
TPC/UPS O= IOT * <---a --> D= LAN *
-
Please see the screen shot. I have installed Avahi. My audio devices (such as TVs and devices such has Google smart speakers, Nest doorbell, etc are connected to the IOT network and my iphone and computers are on my LAN network. I can play my music on my iPhone on the LAN network with this configuration.
-
@munson Hi, I'm not saying it's wrong but in short it works like this, without creating so many rules.
I allow the ITO Network to have access to the Lan Network OPT1 ect ect ect ....