macOS Network Extensions: how a modern Mac firewall sees every connection

To judge a connection, a firewall has to be asked about it before it happens. On older versions of macOS, that meant a kernel extension: code loaded into the heart of the operating system. Kernel code runs with the highest privileges, and a bug in it can crash the whole machine, the dreaded kernel panic, or open a hole attackers can use. Apple has spent several years moving that work out of the kernel.

From kernel extensions to system extensions

Since macOS Catalina, Apple provides system extensions: components that run in user space, as separate processes, but with the specific entitlements they need. Apple’s developer documentation describes kernel extensions as deprecated for the jobs system extensions now cover, and Apple’s deployment guide explains how both are approved. A system extension that misbehaves can be stopped and restarted without taking the Mac down with it.

Networking is one of those jobs. The Network Extension framework offers several provider types, each for a different purpose. Two are easy to confuse:

• NEFilterDataProvider, a content filter: macOS asks it about each new network flow, and it answers allow, drop, or pause while it decides. This is the natural building block for a firewall.
• NEAppProxyProvider, an app proxy: it receives an app’s traffic and forwards it itself, like a per-app VPN. It is built for tunnelling traffic, not for judging it.

What the user has to approve

A content filter sees every app’s connections, so macOS does not install one silently. The app must be signed with the right Apple entitlement, and the user approves the system extension once in System Settings. Organisations can pre-approve it through device management. This friction is deliberate: anything with this much visibility should be visible to the person who owns the Mac.

How FireAI uses the content filter

FireAI registers a system extension built on NEFilterDataProvider. When an app opens a connection, macOS asks FireAI first, with the app’s identity, the remote host or address, the port and the protocol. FireAI identifies the app by its code signature, applies your rules, and answers. If it needs to ask you, it pauses the flow until you decide; Apple’s framework lets a TCP flow wait, while UDP flows have a short deadline, so FireAI falls back to your default for those and still shows the question.

Many browsers and Electron apps resolve names themselves and connect straight to an IP address. FireAI reads the DNS answers that pass through the filter to attach the real host name to those connections, so a rule for a domain still matches.

Limits worth knowing

• A content filter judges flows; it does not decrypt them. Lesson 5 covers what can still be learned from an encrypted connection.
• It only works while the extension is running and approved. Removing the approval removes the protection.
• Incoming connections are enforced too, but FireAI does not prompt for them, and it does not list which apps are listening.

Check it on your own Mac

You can see which system extensions are installed with the read-only Terminal command systemextensionsctl list, which shows each extension, its developer team and whether it is activated and enabled. Recent versions of macOS also list network extensions and active content filters in System Settings, under General › Login Items & Extensions and in the Network settings. If a security product claims to filter your traffic, it should appear there. If you ever remove its approval, you have removed the protection, whatever its window still says.

It is also a useful habit when you evaluate any network tool: ask which extension type it uses. A content filter judges flows it does not own; a proxy or VPN extension owns and relays them. Both are legitimate, but they carry different responsibilities, and the answer tells you what the tool can and cannot see.