APNS

APNs with Always-On IKEv2 VPN

RDowson's picture
Your rating: None (4 votes)

We have an always-on IKEv2 VPN with a Global HTTP Proxy profile pointing to our internal proxy server.

We are using AirWatch in the cloud to manage the devices.

When the VPN is on APNs doesn't seem to be connecting the devices.

We have opened up the full 17.0.0.0/8 address block into our environment for TCP ports 5523, 2195, 2196 and 443 as described in this apple document - https://support.apple.com/en-gb/HT203609

Do we also need to apply the rule the other way so that the devices can connect back to APNs?

AirWatch seem to suggest that the devices don'e connect back to APNs and instead connect straight back to the console.

Can someone help with this please?

APNS on a PCI network

bevo_79's picture
No votes yet

Does use iOS devices on a secure PCI network? If so, can you tell me what you have done to allow APNS to communicate with those devices? Did you open your firewalls to allow communication to Apple's entire 17.0.0.0/8 network as many MDM providers suggest? Or did you only open it to Apple's APNS URLs?

1-courier.push.apple.com 5223
gateway.sandbox.push.apple.com 2195
gateway.push.apple.com 2195

i cannot fathom opening our firewall to the entire 17.0.0.0 class A network - even if it is all owned by Apple. That's over 16.5 million IP addresses!

How bad is the OpenSSL "Heartbleed" vulnerability for MDM?

No votes yet

Yesterday a vulnerability came to light in OpenSSL, which underpins much of the security infrastructure on web servers and application servers around the Internet. Today the technology world is on fire about the bug. Basically, any server running OpenSSL versions 1.0.1 through 1.0.1f is at risk to a simple query. There is an online tool available to check your servers.

The bug, however, doesn't only affect SSL. OpenSSL is also commonly used for generating the asymmetric encryption keys that are the foundation of, oh, the Apple Push Notification Service. And APNS is the foundation for MDM.

If your MDM service happens to be vulnerable, or was vulnerable any time in the last two years the bug has been available, then it is possible someone has stolen your server's private APNS key. And if they do that then your MDM is compromised. But since the attack leaves no trace, well it may be better to err on the safe side.

The "safe side" for MDM means revoking your APNS certificate, and re-enrolling all devices. By hand. That is going to be a huge a bucket of pain.

So here is hoping your particular MDM service is not and was not vulnerable. I've heard from a few already, but will wait for official statements to become available before posting. Watch this thread for more as this develops.

Recent Activity