Try this - https://support.apple.com/en-us/HT203609

Since Apple owns the entire range, and use load balancing, their services can skip around the range daily. That's why they only as you to open certain ports. It's also a security precaution because if Apple published what ranges, for example, APNS lived on, they'd be much more open to attacks trying to down the service.

Here you go...

https://support.apple.com/en-us/HT201999

Get started using Apple Business Manager or Apple School Manager with Mobile Device Management is one you'll need to pay attention to for Device Enrollment

@cbrewer Thanks for pointing that out, but not remotely close to what I am looking for... If you check the excellent https://www.richard-purves.com/2017/07/21/apple-17-0-0-08-services-redux/, its what im referring to.

I also believe that Apple have now out grown the 17.0.0.0/8 range, so even if you were happy opening up the entire range of IPs it’s likely to not cover everything you’ll need.

We first noticed this with DEP enrolments. If you’ve used the ‘services test’ iOS app it gives you a small list of servers that are used, rather than just *.apple.com but I can’t imagine that’s anything like all that going on.

The best thing I can suggest, if you want an extensive list, is to plug an iOS device into AC2 with the console window open and active a device. The console should show you all the URLs it hits during enrolment and setup

@gpalau You really can't rely solely on @franton's Apple 17.0.0.0/8 Services Redux article. Note the comment he added to the top of the original Apple 17.0.0.0/8 Services article last year:

3rd September 2018: I keep this blog post as a historical document. Over the last two years it’s become more and more apparent that the “whack-a-mole” approach is more work than it’s worth. There’s a variety of new Apple URL’s appearing all the time and the maintenance work simply isn’t worth it.

My recommendation is to allow *.apple.com URL free passage to/from your network on 80 and 443. In particular it has to be the URL and I’ve other posts that explain why.

It'd be nice if that were actually possible, but it's definitely not an option for some, so keep asking Apple to make the information on the server addresses and roles less opaque. Who knows, one of these days they might listen. The fact that HT207516 and HT201999 exist are small steps in the right direction.

Hey y’all, not to toot my own horn but I covered this in depth during my presentation at JNUC 2017:

https://www.jamf.com/resources/videos/a-push-odyssey-journey-to-the-center-of-apns/

It is an outbound connection to Apple on 443 and 5223 for managed devices, and 443+2195-2196 for Jamf Pro servers.

You do not need to create an inbound rule from Apple into your network; however, this doesn’t mean that you treat APNS like a “drop box” where packets go and never return. What it means is that devices will open a connection to APNS and expect to keep it open. You do not need to accept unsolicited connections from Apple because it will never make them.

Apple devices will make every effort to keep the socket connection open to APNS. Don’t shut it down prematurely. They need to be connected to listen for push notifications.

What @bradtchapman said. It's an unmanageable problem that comes from a Windows centric perimeter security way of thinking that is slowly going the way of the dodo.

I was engaged at a financial institution trying to maintain this. Lots of people contributed various items and it was getting to the point where it was distracting from my main tasks. Add to that the convoluted multi-month change process in high security environments like financial and maintaining a list like mine becomes a full time job in itself and you'll never be current with it . Ever.

That's why @sdagley correctly points out my addition as to why I retired the list. Sure it was handy, but it was mutating all the time. And then comes my discovery (from Brad's APNS talk) that Apple's download CDN's don't even reside in 17/8 !. https://www.richard-purves.com/2017/11/17/apple-now-it-hurts-when-ip-address/

On a different note, I'm never going for a punny title like that again :)

So yeah, you can't rely on just opening 17/8 and expecting to hit everything as stuff for downloads exist outside of it. It has to be *.apple.com on 80 and increasingly 443, HTTP HTTPS and HTTP/2 protocols.

Oh and hey @bradtchapman ... APNS is coming under changes too. See https://www.richard-purves.com/2018/06/26/2018-apns-changes/. I even have a feature request on this too at https://www.jamf.com/jamf-nation/feature-requests/7612/apns-api-change