Apple Caching and Zscaler Internet Access


#1

Apple devices (macOS X, & iOS) periodically retrieve updates from Apple and to reduce load on multi-user networks, Apple offers a caching service that can be run on Apple servers. This is Apple’s description of the service: https://support.apple.com/guide/mac-help/about-content-caching-mchleaf1e61d/mac. In summary when an Apple device looks to the cloud for software it will first check in with Apple to see if there is a caching server on the local network that can be used. If there is a caching server then the Apple device in question will contact that caching server for software rather than reaching out to the cloud. The key in this decision is the source IP that the Apple device is using when it first contacts Apple.

When Zscaler Internet Access cloud is used to protect a multi-user network the source IP that devices use will be a Zscaler IP address rather than the true public source IP of the client network. Therefore, if Apple caching is a desired function within a network there is some configuration required to facilitate this service.

As of the date of this post two hostnames are used to detect the client source IP address, and they resolve to the respective IP addresses as shown below:
lcdn-locator.apple.com
17.164.1.38
17.164.1.41
17.146.232.38
17.146.232.42

serverstatus.apple.com
17.171.49.71
17.171.49.180
17.146.1.21
17.146.1.147
17.146.6.10

These IP addresses may change or differ around the world as you can see by using a tool like www.whatsmydns.net or dns.google.com.

To enable Apple caching we need to ensure that requests from clients to these two hostnames will reach the Internet from the true client source IP. There are a few options:

  • If explicitly forwarding traffic via PAC file as the only way to reach Zscaler these hostnames can be exempted within the PAC file. This strategy could also work in a Zscaler App deployment where a PAC file is used.
  • If Zscaler Enforcement Nodes (ZENs) have been deployed on premise, PAC files can be used to direct these specific hostnames to the local PZEN or VZEN clusters so that sessions will be sourced from those local nodes.
  • If sessions are forwarded transparently at a router or SD-WAN appliance the above IP addresses (or whatever the current IP addresses are) should be exempted from forwarding. If the specific IP addresses are entered into a configuration it is recommended that a script or other systematic method is implemented to monitor for change in the future.