# What, exactly, is required to make Airplay work across VLANs? [closed]

It seems like AirPlay works out-of-the-box, vaguely speaking, only within a LAN. It's not clear to me exactly why, but it looks like at least discovery relies on broadcasts. Wikipedia states that Airplay is a proprietary protocol which probably explains why the only documentation I've found is unofficial like this spec at github.

So, my questions are:

1. Can a network be configured such that Airplay works across VLANs?
2. If so, what, exactly, must be allowed to pass between the VLANs to make this work?
3. Is this a bad idea in a production environment given the unavailability of official protocol documentation?

## closed as off-topic by Ron Maupin♦Apr 25 '18 at 3:03

This question appears to be off-topic. The users who voted to close gave this specific reason:

• "NE is a site for to ask and provide answers about professionally managed networks in a business environment. Your question falls outside the areas our community decided are on topic. Please visit the help center for more details. If you disagree with this closure, please ask on Network Engineering Meta." – Ron Maupin
If this question can be reworded to fit the rules in the help center, please edit the question.

• The application is an office where there are trusted devices on a 'trusted' network and other devices on a 'visitor' wireless networks. Devices from both networks ought to be able to Airplay to the boardroom TV. – alx9r Jan 21 '14 at 21:41
• Can you add more detail about your environment? For example what brand of wireless equipment are you utilizing? This will greatly affect your ability to do this. – Brett Lykins Jan 22 '14 at 2:34
• Why not create an SSID/VLAN per conference room with the Apple TV for that conference room on that vlan? Or put them directly on the guest SSID and have employees connect to that during presentations. Then anyone in the room using it can hop on that network for presentations. Internal employees can VPN into the internal network from there for access to internal resources (depending on your setup). – some_guy_long_gone Jan 25 '14 at 4:10
• @legioxi That's the leading plan at this point: All bonjour devices live on guest networks and trusted users RA-VPN into trusted network from there if/as needed. There is still the issue of making printers available on both networks, but so far it seems to be the least worst strategy. – alx9r Jan 26 '14 at 0:03
• This is called 'Service Discovery Gateway' in Cisco products - cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dns/configuration/… – cpt_fink Dec 24 '15 at 2:36

There is two different things in term "Airplay".

The first one is about service discovery and it's the way how devices capable of receiving Airplay streams announce to the network "Hey! I can receive Airplay!". It's done normally via service called Bonjour (at least Apple calls it so) or DNS-SD. It's using multicast and that's the point if someone is telling to you that "Airplay is for local LAN only" or something. The streaming itself is "normal" UDP unicast.

Now the main problem is how you get the info about Airplay receiver to the potential senders in another network. There is two theoretical options:

1. You can forward multicast. It might be tricky though, but there are routers/firewalls capable of this. RTFM how exactly, but the idea is that you have to forward multicast traffic with destination address 224.0.0.251 to another network and you have to do it without decrementing TTL.

2. Another option is to use unicast DNS-SD. You can use normal DNS to announce the very same info normally distributed automatically via multicast DNS-SD and you can use a little help from dns-sd(1) utility on your MacOSX to get an info what exactly to write into your DNS zone file. Execute this command in the LAN with Airplay receiver and this should give to you all the info you need:

\$ dns-sd -Z _airplay._tcp
Browsing for _airplay._tcp
...

3. There is also DNS-SD proxies (for example avahi can be used as such).

Now, I said "theoretically", because I haven't tested it and whatever you do with protocols, forwarding and so on, there MIGHT be some roadblocks beyond your control - it's the Apple after all. You could get all info correctly to the potential sender, but iOS/MacOSX might still reject it because it just doesn't like it for some reason and so on.

There is one more (again theoretical though ;) brute force option - create a DNS-SD entry for your router address as an Airplay receiver for the network with Airplay senders and forward (NAT) the UDP stream to the real Airplay receiver. But even with this there are some possibilities (for Apple engineers) to break it.

• Ugh. So based on your assessment getting this working basically boils down to an experiment. – alx9r Jan 21 '14 at 22:09
• You are on undocumented ground, so it will always be about experimentation. Apple doesn't support it, so it might break any moment (with any update etc) as well. But learn about stuff you'll do, understand it and you are able to make it securely and will be able to make it work again if it breaks. Or at least understand why exactly you can't make it work ;). – Thom Jan 21 '14 at 22:30
• To the final point in your penultimate paragraph: This post seems to indicate that "...AppleTV will not connect from outside of it's own subnet..." even though discovery works. – alx9r Jan 25 '14 at 1:04

This is a common problem in educational environments. Apple has done an excellent job of selling iPads and Macs to students/staff and they want to utilize Airplay/Airprint/other Bonjour functionality. However, as you pointed out, these features rely upon a single broadcast domain for service discovery. Enterprise/educational networks just aren't structured that way.

The problem is so prevalent that many educational institution IT staff got together a few years ago, and petitioned Apple to fix Bonjour to work better in these environments.

To directly address your questions, it will usually require very specialized configurations to accomplish the spanning of Airplay services across your network. And the specific configuraition will depend heavily on your current wireless solution (Cisco, Aerohive, Ubiquity, etc). In general, if you search for your wireless vendor and Bonjour, you should find documentation to at least point you in the right direction.

I have had mixed success deploying Cisco's Avahi Bonjour gateway solution, and wouldn't recommend looking into it unless you absolutely have to.

The bottom line to me is, as you pointed out in your third question, you'll always be at Apple's mercy because this is a closed, proprietary, undocumented service* intended for home network environments. So, unless Apple decides to change that, I would avoid implementing it in an Enterprise network wherever possible.

*The underlying code for mDNSResponder is open, non-proprietary, and available under the Apache license. However, Apple's implementations of this internal to their iDevices and MacOS are all outside your control and could change at anytime.

• Thanks for this great answer. When you say "the specific configuration will depend heavily on your current wireless solution" do you mean that they each employ different techniques to make Airplay services work across VLANs, or that they each have different admin interfaces for configuring what amounts to the same technique on the wires? – alx9r Jan 22 '14 at 2:58
• A little bit of both actually. Different vendors will handle the snooping and retransmitting of the Bonjour multicast packets differently, and different vendors will have vastly different ways of configuring it in my experience. – Brett Lykins Jan 22 '14 at 3:02
• Can you go into details about your findings with the bonjour gateway solution? – Robert Siemer Oct 29 '17 at 0:12

Avahi can help you here. There are lots of options but this should get the traffic across the subnets. You should be able to get it on a ddwrt box or use a Raspberry Pi and dot1q interfaces.

 enable-reflector= Takes a boolean value ("yes"  or  "no").  If  set  to
"yes"  avahi-daemon  will  reflect  incoming mDNS requests to all local
network interfaces, effectively allowing clients to browse  mDNS/DNS-SD
services  on  all  networks  connected  to  the gateway. The gateway is
somewhat intelligent and should work with all kinds  of  mDNS  traffic,
though  some functionality is lost (specifically the unicast reply bit,
which is used rarely anyway). Make sure to not run multiple  reflectors
between the same networks, this might cause them to play Ping Pong with
mDNS packets. Defaults to "no".

reflect-ipv= Takes a boolean value ("yes" or "no"). If set to "yes" and
enable-reflector  is  enabled,  avahi-daemon  will forward mDNS traffic
between IPv4 and IPv6, which is usually not  recommended.  Defaults  to
"no".

• I am pretty sure I set up a ping pong table :) – Jonathan Komar May 28 '18 at 16:43

It doesn't work because it's a broadcast (multicast) technology. (see also: Bonjour) Crossing a broadcast domain (i.e. VLAN) requires a proxy. I'm not a Mac person, but I've seen such a proxy setup before -- so iDevices could get to a printer where wireless and wired were different lans. I don't remember the program that was used, but it was not free.

• Thank you. It looks like I was using the wrong search terms. Searching Airplay proxy yields this and this which seem fairly comprehensive. – alx9r Jan 21 '14 at 22:02
• Technically it's a multicast technology. – bahamat Jan 23 '14 at 19:22
• @bahamat, true, but local-scope so it might as well be broadcast. It will not naturally leave a single broadcast domain. – Ricky Beam Jan 23 '14 at 19:45
• This is Network Engineering. Not Ask Different. There's a significant difference between broadcast and multicast. On a discussion site for network engineering professionals that's not a distinction to disregard. mDNS is multicast (thus the "m") and by default will be limited to a single broadcast domain. – bahamat Jan 24 '14 at 18:32

Airplay travels over IP, so normal routing applies. You need a router to route traffic from one VLAN to another. Unless you start messing with Multicast, Bonjour will stay on the local VLAN, however.

Is this a bad idea? It depends ;-). You have to tell us a lot more about your production environment to make an educated guess.

As others have noted, there is a free, open source solution called Avahi (http://www.avahi.org) that can work as a mDNS/Bonjour proxy. The machine this software runs on must have network interfaces to each VLAN/subnet you would like mDNS services to be advertised to/from. For the actual services to work, however, you must have inter VLAN routing enabled or allow TCP/UDP connections to the mDNS enabled device in your access lists or firewall. Other options include Cisco or Ubiquiti wifi controllers which can also serve as mDNS proxies, or if using a Mac you can create a proxy for each service (https://kb.acronis.com/sites/default/files/content/2013/01/39490/wanbonjour_1.pdf). The problem with this last solution is you have to create a proxy for each individual service, and you have to redo it every time the machine reboots.