With the migration to our new McAfee webgateway solution in place (and the advent of SSL scanning to our traffic now) the crash course of all things McAfee has begun (and well) made my brain go on overload.
One of my more recent issues have come into play when it comes to SSL based traffic, and namely - Apples 'Facetime' application. I dhelved through logs, pulled reports and the lot - even contacted plat support but even they were 'stumped' and had me submit a new 'Product Enhancement Request'.
Here is the transscript of (our) conversation and the disconnect that Apple (aka the Devil) and McAfee seem to be having.
"Unfortunately, Ican't see a way to make this work due to the way Apple has this setup. Theapplepushserviced first does a DNS TXT query for "push.apple.com" [nslookup -query=txt push.apple.com] . This will return "count=50" orsome number XX. The daemon then creates a name using a number between 1..XX andcreates DNS name X-courier.push.apple.com. This DNS name is then handle byAkamai DNS to return an ipaddress in the 17.X netblock that belongs to Apple.The iPad then attempts to make the connection to that IP which is thetransparently re-directed to the Web Gateway in your environment. The problemis that the CLIENT HELLO includes SNI (server name indication) which lists thehost as simply 'courier.push.apple.com'. This causes the Web Gateway to do aDNS lookup for 'courier.push.apple.com', which will not resolve to an IPaddress but instead will only return a CNAME record:courier-push-apple.com.akadns.net. Without an IP address to connect to the WebGateway sends back the '502 not resolvable' error page. The only workaroundthat I can think of that includes the Web Gateway would be an option to havethe proxy ignore the SNI and connect directly to the IP address as requested bythe client. Unfortunately, we do not currently have an option to do so."
Am I missing something here, or is there a ruleset/change that can be made/modified to help alleviate this issue?
Or should we start looking for another solution to (PunchMeInThe)Facetime for iPads?
We are currently building a lab to better understand what you are describing.
Looking into the data and analysis might take a while. We'll keep you posted.
As additional quick question, where does the transcript come from? Apple to McAfee Support?
We just setup an MWG in brdige mode and had Facetimesessions running over it, even with a MWG rule in place that blokcs all MWG can see.
Can you as well specify your environment in more details, please?
Here is what we tested:
- Apple iPhone 4 with Facetime connected to Access Point via Wifi
- MWG in transparent bridge mode between Access Point and upstream network
- A Mac with Facetime in a different network
What we can see is that communication seems to be mainly UDP based. MWG running in transparent bridge mode only intercepts port 80/443 TCP, so all other traffic is simply passed on to the remote server.
We tried inbound/outbound Facetime calls succesfully. Please share some more information about your test environment, so that we can probably adjust our test here to better understand what you are doing.
Thank you for the replies
We are currently set up in proxy.pac mode (with WCCP) amongst 2 appliances. The transcript came from my call to the 'plat hotline' after I captured a feedback/tcpdump for their review.
Im still a bit noobish to the MWG world, so pardon my intermittent 'McAfee Meltdown Moments' - it might have made sense yesterday, but today its all gibberish and will make sense again here in short order.
What other sort of information would help out here?
proxy.pac with WCCP ? WCCP is a network based redirection to avoid the need of proxy.pac
I think the info we need is - how does traffic from your device gets onto Web Gateway? Have you set a proxy.pac on the iOS device, or are you redirecting via WCCP in your wireless network?
Gotcha - Proxy.pac is for the users on our network who are authenticated against the AD database (and get it via group policy)
The WCCP connectivity is for our iOS (and other) devices who are not a part of the domain but still need access to the outside world.
Interestingly enough, I have add this iOS device to our whitelist to ensure that it wasn't something on the WG that was stopping it. In parsing the logfiles, I am seeing the traffic of where it is 'attempting' to go out -
10.5.89.89 200 "GET http://init.ess.apple.com/WebObjects/VCInit.woa/wa/getBag?ix=1 HTTP/1.1" "" "-" "" 12940 229 "server-bag [iPhone OS,5.1.1,9B206,iPad2,4]" "" "0" ""
Awesome, I am getting a 200 (OK) for the initial request. The problem comes into play when it tries to make its connection after this-
10.5.89.89 502 "CONNECT courier.push.apple.com.:443 HTTP/1.0" "" "-" "" 3079 0 "" "" "0" ""
Im getting a 502 (overloaded) error...
With the fact that this client (10.5.89.89) is outside of the filtering scope of the WG, this tells me that the disconnect is somewhere else. Anyone shed some light on this?
*Edit* I think I just said the same thing I did in my initial post
Message was edited by: shaneg on 8/24/12 10:53:16 AM CDT
Yet another thought crossed my overflowing McAfee mind - In seeing that the WG is having the issues with courier.push.apple.com Would it then make sense to craft a custom proxy.pac file to have the iOS devices to use that bypasses/ignores this URL host? (At least as far as the gateway is concerned)