Nitemice

So, the week before last Apple released its new iPhone, along with an update to its IOS operating system. On the same day, Mr Chief finally, after months of trial and error, worked out how to get Apple Push Notifications to work from within the House’s network. And now, I’m going to give you the information he would have loved to have had at the start of all this trouble.

Push notifications are a method that a device, specifically an Apple device in this case, can receive updates, alerts and the like from a server. However, what makes this method special is that the server starts the communication, rather than the device going to the server for information. This means there has to be a constantly open connection between the device and the server, so that it can “push” a notification whenever necessary. This sort of setup isn’t something firewalls and networks are normally arranged to work with, as they are potentially really insecure. If a hacker disguised themselves and tried to get into the network through this opening, it could be very bad. However, the House needed to get Apple Push Notifications, or APNs, working due to the fact that “Find My iPad” was useless without them and many people were losing their iPads within the House. It turns out that in IOS 6, authentication certificates are issued using push notifications too, so it’s a good thing we got it working when we did, otherwise no-one who updated would be able to connect to the House’s wireless.

If you want to just get to the point, scroll down to the bottom where I’ve got a summery of what had to be done.

As I’ve mentioned before, the House has a parent company(who I will refer to, from now on, as “the Kingdom”) who provides various technological services to the House, including its super-fast internet connection, along with an external firewall. All traffic to and from the House’s network must go through the Kingdom’s firewall, which is totally out of Mr Chief’s control. On top of that, the House, of course, has its own firewall. Furthermore, the iPads use a proxy to connect to the House’s network, which puts them in a subnet, so they’re effectively three networks deep…

Needless to say, Mr Chief had a big job on his hands getting this all to work, and initially he hadn’t the faintest idea. After scouring the documentation, he still didn’t know, so he consulted with a “Apple Genius” who informed him the first step, and hopefully the only step, would be to get the ports that the APN service uses opened up. This meant putting rules on both firewalls to allow all traffic to Apple servers (which are actually the entire 17.0.0.0/8 range or 17.0.0.0 to 17.255.255.255 with a subnet mask of 255.0.0.0) through the specified ports, which are 5223, and 2195 – 2196. It also needed port 443 to be open, but this is the port used by HTTPS, so it was already open. It was easy enough for Mr Chief to open these on the House’s firewall, but it took a lot of nagging to get the Kingdom to open up the ports on theirs.

But that didn’t make it work. For weeks, Mr Chief ran tests, watching the packets go back and forth to Apple’s servers from his iPad, trying to work out why it wasn’t communicating. It turned out that, while the server was receiving the message to establish a connection from the iPad, it had no idea who the message was coming from because it had to negotiate so many networks and changes of address to get there.

What happens is each iPad has a local IP address within a particular range for communicating  in the House’s network. When it wants to reach something out on the net, it has to send out packets (little bundles of data) which first reach the House’s firewall, where their IP is swapped out for a random one from a different range so that it can travel through the Kingdom’s network. Then it gets to the Kingdom’s firewall, where it is given a different IP again. This time, the IP is an external IP, and from here the packets can go directly to the server they’re looking for, in this case, Apple’s servers. When the server replies, the packets it sends have to do the whole thing in reverse. To establish a connection with Apple’s servers to receive push notifications, the iPad has to do a multi-part handshake with the server . This involves sending multiple messages back and forth between the two of them. However, because the messages that the iPad sends are getting a random IP each time it enters the Kingdom’s network, the server never recognises the iPad, and denies the connection. Somehow, this isn’t a problem for the replies coming back from the server. So when the iPad sends its second message, it is given a different random IP to use in the Kingdom’s network which  totally confuses Apple’s server as to where this message is coming from, or who is sending it.

With this realisation, Mr Chief was able to find a solution. He simply had to stop the randomness of the IPs being assigned by the House’s firewall. The same IP couldn’t be used in the House’s and the Kingdom’s networks, and each iPad couldn’t be given a exclusive static IP to use when travelling through the Kingdom’s network. His solution was to put a rule in the House’s firewall to give messages coming from each iPad a specific static IP to use in the Kingdom’s network, depending on the user. This way, any messages from an iPad by UserA would always get StaticIP_A when entering the Kingdom’s network, and any messages from an iPad by UserB would always get StaticIP_B when entering the Kingdom’s network. This way, the message was traceable back to the iPad, just like Apple’s servers needed it to be.

So, in summery, we had to:

• Open ports 5223, 2195 and 2196, (and 443, if you don’t already have it open (it’s also the port for HTTPS)) for traffic going to Apple’s servers (the entire 17.0.0.0/8 range or 17.0.0.0 to 17.255.255.255 with a subnet mask of 255.0.0.0)
• Make sure all traffic going to these servers from a device always uses the same IPs, by using Network Address Translation when entering a new network. Route all traffic through static IP

I think that’s all there was to it, in the end. I hope this has helped you out, if you were having trouble getting Apple Push Notifications to work. For more information on how push notifications work, and how to troubleshoot them, I have some links below. If there’s anything I’ve missed, or if this solution didn’t work for you, or you just have something to say, Feel free to drop me a line on the Contact page, or in the comments below↓.

Helpful Links:

• Apple Support on APNs – http://support.apple.com/kb/TS4264?viewlocale=en_AU
• Apple Business Deployment Brochure – http://images.apple.com/iphone/business/docs/iOS_Business_Mar12.pdf  – page 21
• About TSL/SSL Handshakes – http://publib.boulder.ibm.com/infocenter/wmqv7/v7r1/index.jsp?topic=%2Fcom.ibm.mq.doc%2Fsy10660_.htm
• More Apple Support about ports etc. – http://support.apple.com/kb/TS1629
• Apple Push Notification Service developer information – http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html

To Infinity and Beyond,

Nitemice