Wireless Access

Need some clarification on AirGroup in the controller.

 

We have a user-role that denies access to multicast (224.0.0.0 255.0.0.0), however, when I am in that role, I can discover and airplay to the AppleTV in the room. I check my datapath session table and I see the denied flag for 224.0.0.251, however, I am still able to do everything. Bluetooth is disabled on my device.

 

1. Does AirGroup override the user-role ACLs?

 

We added my user-role to the "Disallowed Roles" in the AirPlay service, deleted my session, and I was still able to AirPlay to the AppleTV.

 

2. How does Disallowed VLANs/Roles restrict or deny access to AirPlay? 

 

We have tried everything except block the Bonjour port in the user-role, but nothing seems to stop me from discoverying and airplaying to the AppleTV.

 

 

 

 

AirGroup does not control datapath, it only controls the proxying of advertisements.

 

Are the two devices in the same VLAN and/or same role?

Ok, is there any other IP addresses for mDNS/Bonjour or Airplay ports that may be used beyond 224.x.x.x? 

 

We are denying 224.0.0.0/8 and I see that traffic being denied in the controller, but I'm still able to AirPlay successfully and can't seem to figure out why it's allowing me access.

For kicks, try denying UDP 5353.

added entry of any any udp 5353 deny and I am still able to AirPlay. I am in a different user-role than the AppleTV. My user-role is the one I setup the deny for, the AppleTV is permitted to do AirGroup.

 

I'm not sure why the controller is showing Denied, but it's still working.

Wonder if the device has it cached somehow? mDNS is only used for discovery, not the actual content sharing.

So mDNS (224.0.0.251) is used for discovery and Bonjour UDP 5353 is used for the sharing? 

 

I read that the controller converts the advertisements or discovery to unicast with AirGroup. Is that true? If so where does the unicast source and destination - me to the controller?

224.0.0.251:5353 is mDNS advertisements. mDNS is only used for service discovery, just like SSDP (used with DLNA).

The controller really only proxies it in the case of it crossing a subnet/VLAN boundary. The “server” advertisement is sucked up from source VLAN and processed and added to the AirGroup table. When a client queries for a service, the controller processes the query and then depending on policy, responds back to the client with the IP address of “server”.

Ok I think i'm starting to understand this a little better. So what protocol / port is used for the content sharing between my apple iphone and apple tv? I think that's what I'm really trying to block, not necessarily the discovery, but the actual airplaying or casting.

It's going to be difficult to block since it uses standard RTP/RTSP. You'll end up blocking a lot of other things.

 

If you have drop broadcast multicast enabled, you shouldn't have to worry about anything. 

Thanks for your help and the clarification, I think I understand why things are not being blocked right now, discovered is another story but we will continue to review.

 

I also found this post on Apple explaining ports used by AirPlay and other apple services:

https://discussions.apple.com/thread/4849637?tstart=0

 

Thanks again.