Firewalls: stateful filtering and macOS’s options

A firewall’s job sounds simple: let good traffic through, keep bad traffic out. The interesting part is how it decides, and at what level. This lesson covers stateful filtering as a concept, then the specific, separate tools macOS offers, each working at a different layer.

Stateful filtering: remembering the conversation

An early, “stateless” firewall inspects each packet in isolation against a fixed set of rules. A stateful firewall instead keeps track of open connections, and as Cloudflare’s networking glossary describes it, “saves information regarding open connections and uses this information to analyze incoming and outgoing traffic, rather than inspecting each packet” from scratch. In practice this means a stateful firewall can keep ports effectively closed until a connection you initiated asks for a response, then let that specific reply back in, without opening the port to anything else. Nearly every consumer and operating-system firewall in use today, including macOS’s, is stateful.

Inbound vs egress filtering

Inbound filtering controls connections arriving at the machine, uninvited, from outside: someone or something trying to reach a service running on it. Egress (outbound) filtering controls connections the machine itself, or an app on it, tries to make outward. The two matter for different reasons. Inbound filtering stops a machine from being reached and probed in the first place. Egress filtering matters after something has gone wrong: harmful software that gets onto a machine still needs to phone home, receive instructions, or send data out, and every one of those needs an outbound connection. A machine with a strong inbound firewall and no egress filtering at all can still leak everything on it, one outbound connection at a time.

What macOS actually gives you

The practical read of this table is that macOS’s built-in, supported firewall (the Application Firewall) covers inbound connections well but says nothing about what leaves the machine. pf can technically do both, but it is a low-level, script-based tool aimed at administrators comfortable editing configuration files and reasoning about rule order, not something this course will walk through configuring, since a mistake in a hand-written ruleset can silently fail open or lock out network access entirely, and Apple does not treat it as a first-class, supported end-user setting the way it does the Application Firewall. Community hardening guides that publish ready-made pf rulesets or scripts that pull in third-party IP blocklists go further than this course recommends: those lists need to be trusted and kept updated by someone, and a broken update can break connectivity with no clear error message.

That gap, an inbound-only built-in firewall with no simple, supported way to see or control outbound connections per app, is exactly what Apple’s Network Extension framework exists to let third-party developers fill, with the user’s explicit permission at installation.