Skip to main content

A company-wide proxy server was enabled yesterday and the proxy settings have been applied to all existing Macs. The problem is that if I'm setting up a brand new Mac, I can't get any config profiles to push because it appears that the proxy is blocking the communication between the client and Apple's server that handles the MDM push process. Our network guys are asking for specific URLs that need to be whitelisted to allow the communication to happen so the Macs can get all the config profiles that contain the computer certs and proxy certs required to get out on the internet. The only thing I've been able to find on Apple's site is a list of port numbers that need to be open but no server addresses. The network guys are insistent to have server addresses and not just ports.



Does anyone know what the server address is that the MDM stuff is trying to talk to?



It is a horrible catch-22. Can't get on the internet without certs, can't get certs without internet access.

APNS does not work via a proxy. This threat (https://jamfnation.jamfsoftware.com/discussion.html?id=9264) is still relevant.



EDIT: "Thread" Nobody is making threats here.. Easy boys...

@AVmcclint just +1 to what @thoule said, & a link to my post in that thread.



I now work for an MSP, but we have to get customers to whitelist those IP's for APNS to work. No worky via a proxy, nothing has changed.

On iOS, WPAD and DHCP proxy auto detection is working for us. After connecting to an open wifi for config we go into "More Settings" and select auto proxy leaving the pac file url blank.



All of our sites have a local proxy that is chained to an upstream proxy. Originally we had lots of problems because of the way our upstream proxy farm was configured would cause different parts of the same action to come from different IP addresses. Originally bypassing the upstream proxy for gs.apple.com solved many issues and lately intermittent issues have been reported by others to be much better now the upstream proxy is bypassing the whole 17.0.0.0/8 address space. The local proxy is still in operation for all requests.



At my specific site we have implemented a separate local proxy (squid) with its own internet connection that the proxy.pac (and wpad.dat) files are pointing all apple traffic too. This proxy will drop all traffic other than *.apple.com, 17.0.0.0/8 or a couple of other specific sites.



Regards
Graeme

The pushback that I am getting from our InfoSec team is that they don't want to make the entire Apple Class A network range 17.0.0.0/8 available without going through the proxy. "That opens us up for attack from 16 million addresses!" "leave it to Apple to make something not work through the proxy." I really hate working with teams who have so much hostility toward all things Apple.

Hey @AVmcclint : if you're coming to JNUC 2017, please consider attending my presentation called "A Push Odyssey: Journey to the Center of APNS." I will be covering APNS in great detail with a focus on MDM, the protocol, and the network infrastructure. I hope to resolve a lot of misconceptions and (mostly unfounded) concerns that InfoSec might have about the push notification service.

@bradtchapman I wish I was going to JNUC. Unfortunately I'm not the one who needs to be convinced of the necessity of APNS and all it entails. This problem also extends to the MBP with TouchBar's ability to install/update the embeddedOS. If your presentation is going to be recorded, maybe I can send the video to our InfoSec team.

Reply


Terms & ConditionsCookie settings