Does anyone know how to enable Guest access to Airplay?

  • 2
  • Question
  • Updated 4 years ago
  • Answered
I have students and guests on separate VLANS with limited functionality on our network. I was hoping to see if there are firewall rules or a setting to allow guests and students to mirror their iOS device.
Photo of Bob Ogden

Bob Ogden

  • 11 Posts
  • 0 Reply Likes

Posted 4 years ago

  • 2
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
Bob,
Airplay from Apple uses their Bonjour technology for service advertisement, and by design they are limited to a broadcast domain (in your case, a VLAN). You will need a gateway of some sort to take advertisements from one network and re-broadcast them onto one or more other networks. 

The Bonjour Gateway functionality within our APs does that. Once an OSX or iOS device sees the service advertisements, it will use normal routing and switching to connect to the service providing device and use those services (i.e. play music or mirror your display). 

Get this much going first before you start looking at using firewall rules to selectively prevent successful connections from students and guests to your Airplay devices.
Photo of Bob Ogden

Bob Ogden

  • 11 Posts
  • 0 Reply Likes
Hi Mike,

Thanks for the feedback. I just installed Aerohive in our school. We have 73 APs for a high density setup in preparation for BYOD. I have the Bonjour Gateway working really well across the two vlans I have setup for Faculty and Students.

When there is no firewall policy in place it works like a charm, but once I put a firewall policy up it breaks down. The firewall policy I have built has all of the ports I believe Airplay needs. Below I have put a screenshot of the policy.



Facutly VLAN 201
Students VLAN 202
Airplay Devices are on 201

Any advice would be appreciated. What does a typical student access to Airplay look like in an Aerohive setup? Am I going about it the wrong way?


Photo of Tim Ruda

Tim Ruda, Official Rep

  • 40 Posts
  • 56 Reply Likes
Hi Bob,

Can I assume that the screen shot in your last comment was your FROM-ACCESS policy in the user profile?

If so, do you happen to have the default action below the policy selection set to "Deny"?

This is a common misconfiguration I thought I would mention. If the traffic coming back from the Bonjour devices with a destination of the clients is hitting a user profile that does not have a TO-ACCESS policy configured, the traffic will inherit only the default action.
Meaning that if only a from-access is configured with no to-access and a default action of deny, the default rule for return traffic TO the clients would result in a Deny rule.


Additionally, here is a list of commonly used ports for Apple's Bonjour services to double check you have the applicable channels opened up....
http://support.apple.com/kb/HT6175?viewlocale=en_US

Photo of Sam Doran

Sam Doran

  • 5 Posts
  • 0 Reply Likes

I just spent all day troubleshooting this. I racked my brain all day, pouring over the HiveManager Help on the difference between the From-Access and To-Access policies and the different behavior when the Default policy is set to Permit vs Deny. If only I had done this tomorrow, your response, Tim, would have saved me many hours of testing and deduction. :) But I learned quite a bit and finally managed to solve my problem. Thank you for pointing out this potential configuration pitfall.

My first problem was a default Deny with no To-Access policy defined (as Tim pointed out).


And here are the firewall rules:


I didn't think this would be a problem because the rules are stateful and the connection should only be from the client to the Apple TV. And that part worked fine: I was able to create a TCP socket from a client in the Guest network to port 7100 on the Apple TV in a non-public network. But the Airplay session still failed to initialize. A PIN shows up on the Apple TV, the client prompts me to enter it, then a few moments later I got a failure message.

The missing piece of information I didn't find documented anywhere, including in that article Tim linked, is that the Apple TV sends a UDP packet back to the client on port 7010. I was able to determine this by removing all the firewall rules so Airplay was working, then using tcpdump on the client interface. I saw the TCP 7100 socket but also packets from the Apple TV to the client on UDP 7010. I have not been able to find this port documented anywhere so I'm not sure if it's a range of ports on just this single port. In my limited testing, I've only seen the Apple TV send to the client on UDP 7010. If you run netstat on the client when Airplay is working or trying to initialize, you'll see the client starts listening on UDP 7010 as well. 


.19 is the Apple TV and .23 is the client in this packet capture.

With this knowledge, I was able to create a new Network Service called Airplay with UDP 7010 (Configuration > Advanced Configuration > Common Objects > Network Services). I then created a new firewall rule to be applied to the To-Access policy. This rule has the Apple TV internal network in the source ip field and only allows the Airplay network service, which is UDP 7010. With this rule in place, I can keep the default Deny policy and Airplay works fine from the Guest network to an Apple TV on an internal network.



To answer the OP, I suspect you need to allow UDP 7010 from your Guest network. Without seeing your IP Firewall Policy to know for sure, that's my best guess. I hope this is helpful and saves someone some time.

Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Don't forget that there is now Bluetooth discovery of AppleTVs in iOS 7.1 and the latest Apple TV software. This negates the need for a Bonjour gateway to cross L2 broadcast domains if the only requirement for Bonjour is AppleTVs and you can mandate that the clients be up-to-date.

(This does not yet work with OS X Mavericks, but we can be hopeful that we will see the feature added in the 10.9.3 update when it ships, or soon after.)

UPDATE: I have just been informed that this also requires Bluetooth 4.0 support, which would limit the scope of this feature to newer devices. For example, it apparently does not work with an iPad 2.
(Edited)
Photo of Sam Doran

Sam Doran

  • 5 Posts
  • 0 Reply Likes
I just found an unofficial AirPlay protocol document that explains UDP port 7010 is used for NTP from the Apple TV to the client. It appears that this is the only port used, so allowing this port from the private network to the Guest network is all that is required.
Photo of Sam Doran

Sam Doran

  • 5 Posts
  • 0 Reply Likes
One last hiccup I've run into. The packet captures I did were with clients running AirParrot and not using the built in Display Mirroring capabilities on OS X. While the built in Display Mirroring does use UDP port 7010 from the Apple TV to the client, there is an additional UDP listener created on the client. As far as I can tell both the source port from the Apple TV and the destination port to the client are random, making it infeasible to write specific firewall for the Apple TV to client communication.

The two remaining options are:

  1. Apply From-Access rules, no To-Access rules, with a default policy of Permit.
  2. Apply From-Access rules and To-Access rules with a default policy of Allow. The To-Access rules would be from a specific network or hosts (Apple TVs with static IPs) to any network and any service.
I went with option two since we have a specific network for Apple TVs and Printers (we call in "peripherals") so I trust the return traffic from the hosts on that network to get to any of my wireless clients.

About the best you could do is group the Apple TVs together in a /27 block on a subnet so you don't have to allow more hosts than necessary in the To-Access policy since services can't be limited accurately.
Photo of Tim Ruda

Tim Ruda, Official Rep

  • 40 Posts
  • 56 Reply Likes
Hi Sam

Thanks for sharing your solution with us! I believe you've made the choice which is more easily manageable in the future.