Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Use caching server with multiple public Addresses?

According to the Apple documentation, to use the caching server, all clients need to share the same public address via nat. On my network with many macs, this would appear to make the caching service useless, as we have multiple public addresses to which our clients are nat'ed (a full class C, to be exact). Is there anyway around this restriction, or am I simply going to be unable to use what looks like it would be a highly usefull service?

Posted on Feb 13, 2013 10:35 AM

Reply
Question marked as Best reply

Posted on Feb 13, 2013 1:02 PM

As it stands, you are correct, with some minor caveats...


When the Caching Server starts up (and periodically while it's running), it checks in with Apple, and Apple tracks the public IP address of your server.

When a client checks for updates, Apple cross-reference the client's IP address with the list of known caching servers. If it finds one it redirects the client to their local cache server.


Since this mechanism is transparent - there's no configuration or interaction on the user's part, the IP address has to match since there's no other way for Apple to know if the caching server is on the same local network as the client (even IP addresses just one or two digits off could be entirely separate networks).


In your case, if you're using a pool of NAT addresses your benefit of this service is severely restricted.


There are two options that I can see, though.


One is to set a custom NAT rule (assuming your firewall supports it) so that all connections to Apple's update server are NATted via the same address.

The other is to run your own Software Update Server. However, this only caches OS updates, not App Store updates, and requires configuration on each client, so you do miss some of the advantages of the Caching Service.

28 replies
Question marked as Best reply

Feb 13, 2013 1:02 PM in response to Israel Brewster

As it stands, you are correct, with some minor caveats...


When the Caching Server starts up (and periodically while it's running), it checks in with Apple, and Apple tracks the public IP address of your server.

When a client checks for updates, Apple cross-reference the client's IP address with the list of known caching servers. If it finds one it redirects the client to their local cache server.


Since this mechanism is transparent - there's no configuration or interaction on the user's part, the IP address has to match since there's no other way for Apple to know if the caching server is on the same local network as the client (even IP addresses just one or two digits off could be entirely separate networks).


In your case, if you're using a pool of NAT addresses your benefit of this service is severely restricted.


There are two options that I can see, though.


One is to set a custom NAT rule (assuming your firewall supports it) so that all connections to Apple's update server are NATted via the same address.

The other is to run your own Software Update Server. However, this only caches OS updates, not App Store updates, and requires configuration on each client, so you do miss some of the advantages of the Caching Service.

Feb 13, 2013 1:08 PM in response to Camelot

Camelot wrote:


There are two options that I can see, though.


One is to set a custom NAT rule (assuming your firewall supports it) so that all connections to Apple's update server are NATted via the same address.

That sounds like an entierly workable solution for us. Do you know what the address of Apple's update/mac app store is? I might be able to dig it up...

Aug 26, 2013 3:13 PM in response to Camelot

What about 6 caching servers located on different subnets within a private network, but with the same public IP address?

I have caching servers at 10.65.0.11, 10.66.0.11, 10.67.0.11, 10.68.0.11, 10.9.128.11 & 10.9.128.12. They all have the same public IP of 65.121.184.1.


If a client on the 10.65.0.0 network tries to get an update, how does Apple know which of my caching servers to send the client to?


My caching servers are not working, and I think this is the problem ... Apple not knowing which of the 6 to send a client to. I don't think Apple is sending the client to the update server on the same subnet, so the client goes out to Apple for the updates.


Any thoughts?

Aug 26, 2013 9:01 PM in response to Mike Di Palma

If a client on the 10.65.0.0 network tries to get an update, how does Apple know which of my caching servers to send the client to?

I think this configuration is undocumented, at best. My guess would be that Apple simply sends the client to the most-recently-seen caching server. Apple has no knowledge of your internal network and would expect that any client coming from that NAT address would have access to any caching server that comes from the same address.


In this case, there's something like a 1-in-6 chance that any given client will be redirected to their local caching server.


As for solutions - well, I'm guessing there's a reason why multiple internal/private subnets map to a single public IP, and that it's not easy to configure different public IPs for the corresponding private subnet?

If that's the case then the next solution would probably hinge around internal routing - giving clients in one of your private subnets the ability to route to the caching server in any other subnet (although this might negate the value of the caching server, depending on geography/topography.

Aug 27, 2013 7:54 AM in response to Camelot

Yes, the multiple internal/private subnets mapping to a single public IP is very common in the education/enterprise arena. It is the basic hub-spoke topology:

User uploaded file where all spokes connect to needed resources at the hub, and only the hub is connected to the Internet. In the case of K-12 education, we need to run a content filter (by Federal rules) on student Internet connectivity. The most efficient way to do that is to locate the filter (along with other servers and resources) at the hub and then route all Internet traffic through the hub. Each spoke (and the hub) is a different internal/private network subnet ... 10.65.x.x, 10.66.x.x, etc. In my case I have 3M from each spoke to the hub, and then 45M from the hub to the Internet.


In the "old" days ... pre 10.8 ... we had (and still have for some of our oler 10.4 computers) a software update server at each spoke, and computers at each spoke were configured (with the Apple software update script) to get their updates from the update server at their spoke ... iApps as well as OS apps. This worked perfectly!


Now that Apple, in their Orwellian attempt to monitor and control iApps, has introduced this "either-or" attitude about using a local update server OR caching server (but not giving you the option to get iApps from the local update server) they have really hurt schools like mine. Without being able to serve all updates locally on each spoke, updating becomes impossible when you are tryiing to udpate a lab full of computers, and the iApp alone is 1.2G for EACH computer ...and now it must come from the Internet since the caching server is 'broken.'


I currently have case open with Apple Enterprise Support, and will now also get my K-12 Apple Support Tech invloved. I will share this info with them. Perhaps there is some solution that I do not know about, or perhaps there will be a solution created by Apple for situations like mine. I can't see being the only one with this problem, I just think that I may be one of the first to notice it due to my limiited bandwith situation.


Thanks for your insight. Your original post got me thinking and enabled me to identify what *I* feel is the problem. I will keep this thread updated.

M:>

Aug 28, 2013 10:31 AM in response to Mike Di Palma

I understand the hub-and-spoke model, and see that it makes a certain amount of sense, but there are still elements of it that I think could be improved.


Given the 3mpbs link to each school, inter-school/subnet routing is clearly not ideal (a user in school A could saturate the links of both its own school and that of the other school's server it downloads from).


However, maybe the 'single IP address for all traffic' is where you should focus. Even beyond the use of a caching update server I can see cases where it might be preferable to map each school to individual IP addresses, rather than bundle all schools into one (could make tracing traffic to/from an individual school easier).

I don't know what box is running at the hub, nor the number of available IP addresses to know if this is viable or not.


Other than that, it's hard to see a solution that doesn't involve some kind of engineering effort on Apple's part. The beauty of the caching update server is that it's completely transparent - no input required on the user's part, it just (mostly) works. The problem with changing the protocol to support this model is in how to keep it simple for the users (e.g. not have to walk through hundreds of host systems to tell them which update server to use, which was the problem with the original Software Update Server).


So I hear your pain, just can't see a simple solution to it. I'd be interested to hear what AES come up with (if anything).

Sep 16, 2013 12:36 PM in response to Camelot

One is to set a custom NAT rule (assuming your firewall supports it) so that all connections to Apple's update server are NATted via the same address.

How easy is this? say within a Local Education Authority (LEA) that support schools? All schools in the County have their internet provided by the LEA, I know that the LEA have a limited number of 'real world' IP's so they could theoretically do what you suggest!

Sep 16, 2013 1:25 PM in response to Camelot

My inside Apple Tech (we're a K-12 school) sent me info to modify the Advanced Configuration plist ...


http://support.apple.com/kb/HT5590?viewlocale=en_US


.... especially the ListenRanges & ListenOnly data settings.

My caching server now updates the OS updates BUT still does not supply updates of the iApps ... iPhoto, iMovie, GarageBand. The computers are still going out to Apple to get these ... and these babies are 1.2G+ each ... BIG bandwidth hogs.


My inside Apple Tech has escalated my case with AES and I am awaiting a call from them to pursue this futher ... hopefully to a solution.


I'll keep you updated.

M:>

Sep 16, 2013 2:55 PM in response to Taffy Apple_

Yes ... for iOS7 devices ... but according to Apple Enterprise Support and multiple web sites ... caching server manages apps served through the App store right now:


http://appleinsider.com/articles/12/12/06/os-x-server-updated-with-new-caching-s ervice-and-bug-fixes

======================================================================

December 06, 2012

"Two days following an update to its iWork line of products, Apple on Thursday released OS X Server v2.2 for Mountain Lion, bringing a new Caching service and numerous bug fixes to its server software for Mac.


The new software updates OS X Server v2.0 and v2.1 with a new feature called Caching service that, according to Apple, speeds up download and distribution process of apps managed through the Mac App Store. Among the issues resolved with the update is a problem that would cause the Messages service to not start, as well as overall "general enhancements."


From the release notes:

Caching service


Introduces a new feature called the Caching service, which speeds up the download of software distributed by Apple through the Mac App Store. It caches both software updates and purchased apps from the Mac App Store. For more information about the Caching service, choose Server Help in the Help menu."

Oct 8, 2013 1:06 PM in response to Mike Di Palma

Camelot ... I said I would follow-up when I heard back from AES, so I am.


The AES Confidentiality Agreement prevents me from sharing the Apple email, but I'm sure it doesn't prevent me from letting you know that the *party-line* is that there is a known issue with using ListenRanges and being able to obtain software updates. They plan to fix it in a future release.


So ... I am going back to obtaining updates from my local software update servers, and pointing my clients to them using scripts defined by Support Article # PH9486.


I hope this info helps someone else form pulling out their hair trying to get the caching server to work in this configuration.

Nov 4, 2013 9:34 AM in response to Israel Brewster

Same issue here. I work for a school district and we havea bout 50 different sites. Each site has their own external IP. However, we are all on the same network and can contact each other. So If we can set up the firewall NAT rule, we can get away with just 1 caching server (unless of course it gets overloaded and we need another).


So does anyone have the information needed to create a custom NAT in the firewall?

Use caching server with multiple public Addresses?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.