I've got a situation with Facetime and iPhone 4. The problem is that a user from the inside on our corp wireless can initiate a facetime session with someone outside of our network with no problems. The same user can't call a user on the inside of the network and a user from outside the company can't initiate a session to someone from the inside.
I've got hairpinning configured for the wireless subnet and I'm natting to a particular address for these addresses. The call will fail if the user is initiating a call to another user inside. It almost looks like the traffic will have to be allowed back on on the outside interface. Is this the case? Does Apple initiate a new connection for Facetime requests?
Doing a quick Google search, I see that Facetime is using SIP, ICE, RTP, and H264. I'm not sure how accurate it is, but here's the link I used:
With that being said, the first thing that I would confirm is that you have 'inspect sip' within your policy-map and applied to the appropriate interfaces. If that is there, the only thing that I can offer is some basic troubleshooting guidance:
1.) Enable 'logging buffered debug' and increase the buffer-size substantially. I usually use 'logging buffer-size 512000' or '1024000'.
2.) Enable packet captures on the relevant interfaces for the relevant traffic:
3.) Create the issue by trying a call that doesn't work.
4.) Immediately after reproducing the issue, do a 'show log | inc
5.) If #3 doesn't give you all of the information, try a call that DOES work and do a comparative study of the two.
In either case, the information from #2 and #4 above will give you alot of good information - and the syslogs will give us a better understanding as to how the ASA is handling the connections.
My initial suspicion is that you have an asymmetric route issue. Since the ASA is a stateful firewall, it needs to see every packet of a TCP flow. If you see a number of syslogs of 'Deny TCP (no connection)', this is a tell-tale sign of exactly that. The possible solutions for you, if that is the case, would be to adjust the routing on your network to ensure that this doesn't happen or enable TCP State Bypass for the relevant traffic (supported in 8.2):
Good Luck! Let me know if this helps!
object-group service Facetime tcp
port-object eq 16402
port-object eq 2483
port-object eq 51663
access-list in2out extended permit tcp any any object-group Facetime
access-list out2in extended permit tcp any any object-group Facetime
You can probably secure this more by designating only the ports that are requred specifically for in and out and further by limited the IP ranges that are accessed, but I needed to call my dauighter quick.