I’m using the new 8.4 firmware (build 5396) on a Peplink MAX Transit Duo Pro (MAX-TST-D6A4), and under SFC Protect → Optimize Cloud Application, I added FaceTime to the list of applications to route of SFC. After this, iOS/iPadOS devices on my WiFi network could no longer connect to Apple for software updates (error message is “Unable to Check for Update: An error occurred while checking for a software update”). Mac computers on my WiFi network also started having a different problem: although the Macs could connect to Apple’s software update servers, the Macs downloaded (large!) system updates over SFC, which rapidly consumed my SFC data allocation. I’ve confirmed this with iPadOS 16.6, 17.1.1, and 17.1.2; iOS 17.1.1; and MacOS 14.1.1.
When I removed FaceTime from the list of SFC Protect’s Cloud Applications, everything went back to normal. iOS and iPadOS devices could both download system updates, and Mac computers stopped downloading system updates over SFC.
Can you please fix this, so that when FaceTime is included in the list of optimized cloud applications, only FaceTime traffic is routed over SFC, and system updates and other apple traffic are left alone?
We have reproduced this situation quite a number of times. I don’t think the issue is with 8.4 or SFC per se. Rather, Apple is among the many firms which block the ASN (autonomous system number) associated with the SFC endpoint – a data center. This has been a topic of discussion here several times, as I recall. I’m betting FaceTime will work very well over SFC but updates will not, although I think over time we found a couple of SFC endpoints which Apple had not blocked for updates.
Hello, ASN blocking should only be a problem when accessing Apple updates through SFC. The main bug I’m reporting is that I have not configured Apple updates to route over SFC, but Apple updates are being routed over SFC anyway. I’m trying to have only FaceTime traffic routed over SFC, with all other Apple traffic routing normally (without SFC).
The problem is that apple reuses many of their endpoints across protocols. I suspect that a key domain required for facetime, is also used for updates, and peplink has err’ed on the side of caution of putting all of the Domains that it saw during a facetime session in the rule.
To counteract this, you can analyze an apple update via DNS lookups+rules and then put them at a higher priority to the SF facetime rule. I remember seeing this a couple of years ago when I ran all of my traffic through SF… I had to exempt *.apple.com to receive updates.
If Peplink did include a wide swath of Apple domains in Peplink’s FaceTime rule for SFC, then maybe the rule should be renamed as a warning, maybe something like “FaceTime and related Apple traffic”? In any case, it seems that providing a “click and go” rule to route FaceTime over SFC is probably broken if it prevents phones and iPads from receiving software updates. At the very least, there should be a pop-up disclaimer warning sysadmins that including FaceTime in the SFC list might affect Apple security updates.