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?
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 ' where ip_addr is the relevant host that is failing. In some cases, it is equally easy to just do a 'show log' and use other PC/Linux tools (Notepad or Grep) to parse through the traffic.
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):
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.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :