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.
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?
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....
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.
(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.
The two remaining options are:
- Apply From-Access rules, no To-Access rules, with a default policy of Permit.
- 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.
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.