Should I upgrade to macOS Sequoia now?

The short answer is: We don’t recommend upgrading now because there are several bugs related to networking and firewalls in the 15.0 release. We expect most of them to be fixed in 15.1.

If you have already upgraded or if you want to upgrade for other reasons, here is a list of issues related to Little Snitch or networking in general:

Data corruption in TCP connections

As far as we can tell, this bug is rare and primarily affects ssh connections. Users report various protocol violation errors from ssh and that they are no longer able to connect to servers when a network extension (any network extension) is active.

The error messages are either “Connection corrupted” or complaints about wrong key size. We experienced that problem only once, but in a more severe way: A file transferred via ssh arrived corrupted.

There are individual reports of websites aborting loading midway. We believe this is a general problem with TCP connections, not only ssh, but ssh seems to trigger it most frequently.

Apple’s built-in App Firewall blocks DNS lookups and Firefox

This bug is not related to Little Snitch, but since it’s a firewall topic, we include it here. If you have configured Apple’s firewall to block incoming connections, it blocks all incoming UDP packets, even if they are responses to requests, e.g. responses to DNS name lookups.

macOS performs name lookups in different ways, depending on the programming interface used by the process. Safari and Chrome will still work when blocking incoming connections, but Firefox will not.

On Sequoia 15.0, we recommend that you disable Apple’s firewall until the problem is fixed.

If you still use Little Snitch 5

Our previous major version, Little Snitch 5, is not yet fully compatible with Sequoia. This is not a bug in Sequoia, but a last-minute change shortly before the final release: Little Snitch up to version 5.7.6 no longer has access to the name of the current Wi-Fi network. This breaks Automatic Profile Switching on network change. We will release version 5.8 soon which fixes the problem. Little Snitch 6.1.1 already contains this fix.

What was the problem with Little Snitch 6.1?

Soon after releasing version 6.1 (which brought compatibility with Sequoia), we noticed that DNS name lookups were leaving the machine unencrypted although Little Snitch was configured to encrypt DNS traffic. An analysis showed that some of the lookups were not sent to our DNS proxy network extension, but rather left the machine directly. We therefore suspected another macOS bug.

We were a bit concerned because such a code path existed at all: There are conditions under which the system can bypass a configured DNS proxy.

However, it turned out that this code path is necessary. If the DNS proxy network extension just wants to forward a lookup to a “normal” DNS server, the lookup should not be re-routed back to the DNS proxy again, as that would cause an infinite loop. In fact, we even rely on this behavior for handling configured exceptions from DNS encryption.

But: Why would that code path be taken for lookups done by Firefox? There was another improvement in version 6.1: Server names provided by Apple are sometimes incorrect, often returning a CNAME instead of the actual hostname that was entered by the user. In order to improve this, we used a man-in-the-middle technique between processes and the mDNSResponder daemon, responsible for name lookups. We already used this same technique in previous versions of Little Snitch for many years, before Apple began providing server names via API. Our improvement, however, made mDNSResponder think that all requests originated from our network extension! And therefore it sent them out directly, bypassing the DNS proxy.

In version 6.1.1, we reverted to using the server names provided by Apple's API. Maybe we can come up with an improvement in a future release.