Apple’s Private Relay can cause the system to ignore firewall rules

Apple’s Private Relay (Beta) feature calls home to Apple servers without respecting the firewall rules of the system, creating a leak that neither we, nor you, can stop without disabling the entire Private Relay feature.

The Private Relay functionality is almost like a VPN tunnel, or somewhat similar to how Tor works. It routes your network traffic in encrypted form via relay servers before it reaches the internet. The feature is still in beta and only available in certain regions, and you need a paid iCloud+ subscription to enable it.

When we at Mullvad monitored our network connections while doing development on our app, we saw something that should not be there: QUIC traffic leaving the computer outside the VPN tunnel! This is a leak! We tracked the sending down to the Private Relay feature, and disabling the Private Relay made the leaks stop. We do not know for sure that the traffic belongs to Private Relay, but it sure does trigger it.

It is worth noting that Private Relay (mostly) disables itself as soon as any firewall rule is added to PF (the system firewall on macOS devices). The Mullvad VPN app does add firewall rules. Once you connect the Mullvad app, Private Relay announces that it has disabled itself. We see no correlation between user traffic and the leaking packets. We believe they are just some heartbeat signal calling home to Apple. We do not know what information is transmitted to Apple, but since the destination is Apple servers, it is a strong signal to your local network and ISP that you might be a macOS user.

How to reproduce the leak

If you have an iCloud+ subscription you can easily test this yourself. Follow these steps and observe Private Relay not respecting your firewall rules:

1. Set up monitoring of all QUIC traffic via sudo tcpdump udp port 443.
2. Enable private relay and verify that it works (It should show a notification saying “Private Relay is Active”). The Mullvad VPN app will prevent it from working if it connects during boot. If the private relay is unavailable, remove our app or any other offending VPN client, reboot, and start again.
3. Confirm that QUIC traffic can be observed. Before applying the firewall rule, you should also be able to see traffic in tcpdump if you just send some bytes over nc -u apple.com 443
4. Append a PF rule to block QUIC traffic in /etc/pf.conf, reload the rules and enable the firewall.
   1. Append block return out quick proto udp from any to any port 443 to /etc/pf.conf
   2. Reload rules via sudo pfctl -f /etc/pf.conf.
   3. Flush any firewall state via sudo pfctl -F states
   4. Enable PF via sudo pfctl -e.
   5. Verify that you can no longer send traffic over nc -u apple.com 443
5. Now, you may verify that a trickle of QUIC traffic still flows out from your computer as per the output of tcpdump, yet you would not be able to make new QUIC connections over UDP to hosts on port 443. This means that Private Relay does not play by the same rules as nc.

It is also worth noting that these QUIC leaks happen on the physical network interface even if you connect a VPN and set up the routing table to route everything through the VPN interface. So it is not only circumventing the firewall rules, it is also not respecting the routing table.

To restore your computer and the firewall again, just remove the rule from /etc/pf.conf and run sudo pfctl -f /etc/pf.conf again.

What to do now?

We are not aware of any way to prevent Private Relay from leaking this traffic, other than disabling the feature altogether. This is done in the same place where it is turned on. See Apple’s instructions.

It is hard to speculate about the severity of this leak since the traffic is encrypted, meaning we cannot really know what it contains. This does however signal to your local network and ISP that you are using a macOS device. If your threat model forbids this, you should disable the Private Relay.