Mac Firewall Blocking an App? Here's How to Diagnose and Allow It

You launch a video call app, the connection times out, and macOS pops up a notification: “would like to receive incoming connections.” You click “Allow,” but it asks again the next time. Or you launched an app and immediately the menu bar is full of dialog boxes. Or you can’t figure out which firewall is even doing the blocking — macOS, Little Snitch, an antivirus, or your router.

Here’s how to diagnose and fix Mac firewall issues on macOS Sonoma 14 and Sequoia 15.

Step 1: Identify which firewall is involved

There are several layers of firewalling on a typical Mac:

• macOS Application Firewall: built-in, controls incoming connections per-app.
• macOS Packet Filter (pf): built-in, lower-level, rarely user-configured.
• Little Snitch / LuLu / Lulu / Radio Silence: third-party outbound firewalls.
• Antivirus suites: Norton, McAfee, Kaspersky often include firewall components.
• Corporate device management: Jamf, Mosyle, Kandji can push firewall policies.
• Router-level firewall: blocks traffic before it reaches the Mac.

Knowing which one is blocking matters because each is configured differently.

Step 2: Check the macOS Application Firewall

System Settings → Network → Firewall.

If the firewall is on, click “Options.” You’ll see a per-app list:

• Apps with green dots → “Allow incoming connections.”
• Apps with red dots → “Block incoming connections.”

If the app you’re troubleshooting is set to Block, click it and switch to Allow. Apply.

If the app isn’t in the list at all, click + → navigate to the app → add it → set to Allow.

Also check:

• “Block all incoming connections” at the top: if on, only specific Apple system services receive incoming traffic. Most apps (video calls, screen sharing, Plex) won’t work. Turn it off.
• “Automatically allow built-in software to receive incoming connections”: should be on for AirDrop, AirPlay, Handoff to work.
• “Automatically allow downloaded signed software to receive incoming connections”: should be on so legitimate apps from the App Store and signed developers don’t keep prompting.

Step 3: Check for Little Snitch / LuLu rules

If you have Little Snitch installed:

Open Little Snitch → Configuration → look for rules involving the blocked app. If you see a “deny” rule, edit it or delete it. The app will prompt again next time it tries to connect; allow it then.

For LuLu:

LuLu menu bar icon → Manage Rules → look for the app → toggle to Allow.

Step 4: Identify what the app needs

Some apps need only outbound connections (most browsers, mail clients). Some also need incoming (Plex Server, AirPlay receiver, file sharing, video calls in some configurations).

If you’re not sure what an app needs:

sudo lsof -i -P | grep <appname>

This lists every network connection the app is making. You’ll see ports and remote hosts. If outbound only, the macOS firewall won’t block it. If listening on a port (LISTEN state), incoming connections matter.

Step 5: Watch the firewall log

Console.app → search “appfirewall.” You’ll see when the firewall blocks something.

Sample entry:

Deny ZoomOpener listening from 0.0.0.0:19421

This tells you ZoomOpener was blocked from receiving incoming connections on port 19421. If you allow Zoom, this resolves.

Step 6: Reset firewall configuration

If the firewall settings are tangled (multiple stale entries for old versions of the same app), reset them:

sudo pfctl -F all -f /etc/pf.conf

Or, more nuclear, remove the firewall config plist:

sudo mv /Library/Preferences/com.apple.alf.plist ~/Desktop/

Restart. macOS rebuilds the firewall config with defaults — every app will re-prompt for permission.

Skip the manual huntSweep finds the cached configs, leftover daemons, and stale prefs across your Mac. Download Sweep free →

Step 7: Check Privacy & Security permissions

System Settings → Privacy & Security. The firewall isn’t the only thing that can block an app:

• Camera: video apps need this.
• Microphone: voice apps need this.
• Local Network: critical for AirPlay, Handoff, multi-device apps.
• Screen Recording: screen sharing apps.
• Accessibility: window managers and remote control tools.

If the app does multi-device discovery (Sonos, Spotify Connect, smart home apps), Local Network permission is the usual culprit. Ensure the app is checked.

Step 8: Check for stuck older app versions

If you uninstalled an app and reinstalled it, the firewall sometimes holds rules for the old binary. The new install gets blocked because its signature doesn’t match the saved rule.

Fix:

System Settings → Network → Firewall → Options. Look for duplicate entries of the same app. Remove all of them. Apply. Launch the app — it’ll re-prompt fresh.

If old launch agents from the previous version are also lingering (~/Library/LaunchAgents/), they can interfere. Sweep’s app uninstaller catches launch agents from old versions when removing apps, so reinstalls start clean.

Reclaim what stale apps left behindOld apps leave behind helper tools, launch agents, and stale prefs. Sweep finds them all. Free for macOS →

Step 9: Check for VPN extensions blocking the app

A VPN’s network extension can block traffic in addition to the firewall. Symptoms: app works VPN-off, fails VPN-on. The VPN’s “kill switch” or per-app routing rules are blocking it.

VPN client → Settings → look for “Kill Switch” or “Per-App Routing” or “Allowed Apps.” Add your app to the allow list.

If you have a VPN extension loaded but no VPN is connected:

systemextensionsctl list

Old VPN extensions still intercept traffic. Remove them.

Step 10: Check the app’s signing status

The macOS firewall trusts apps signed by registered developers. Unsigned apps (or apps with broken signatures) get blocked more aggressively.

Check signing:

codesign -dv /Applications/AppName.app

If the output shows “code object is not signed at all” or the signature is broken, the app may be blocked because macOS doesn’t trust it.

Re-sign if you have the dev tools, or download a fresh copy of the app from the developer.

Step 11: Check the router-level firewall

If your home router has parental controls or guest network restrictions, they might block specific traffic types. Common router-level blocks:

• VPN protocols (UDP 500, 4500, 1194).
• BitTorrent ports.
• Game console traffic.

Test by connecting your Mac to your iPhone’s hotspot. If the app works on the hotspot but not on home Wi-Fi, your router is doing the blocking.

Step 12: Allow specific ports

If an app needs to receive connections on a specific port and the macOS firewall keeps blocking it:

sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /Applications/AppName.app
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --unblockapp /Applications/AppName.app

The socketfilterfw command is the underlying tool the GUI uses. Useful for scripting or for apps that aren’t bundled in standard .app form.

Step 13: Disable the firewall temporarily for testing

Just to confirm the firewall is the issue:

System Settings → Network → Firewall → toggle off.

Test the app. If it works, the firewall was blocking it. Re-enable the firewall and add a specific allow rule.

If it still doesn’t work with the firewall off, the firewall isn’t the issue. Look at antivirus, VPN, or app-specific configuration.

Step 14: Check for outbound block via pf

The macOS Application Firewall is for incoming. Outbound traffic is controlled by pf (packet filter), which most users don’t configure. But corporate device management can push pf rules.

sudo pfctl -s rules

If you see rules you didn’t add, an admin profile is filtering. Talk to IT if it’s blocking something legitimate.

Step 15: When apps need configuration help

Some apps require complex firewall configuration:

• Plex Server: needs incoming TCP 32400 allowed.
• Tailscale / WireGuard: needs UDP 41641 (default).
• Minecraft Bedrock multi-LAN: needs UDP 19132.
• iperf / network testing: needs the specific ports you’re testing.
• Apple Remote Desktop: needs TCP 3283 and 5900 plus several others.

Read the app’s documentation for its required ports, then add specific rules in System Settings → Network → Firewall → Options.

When the firewall isn’t really the problem

A common pattern: an app fails to connect, the user blames the firewall, but the actual cause is:

• DNS not resolving the app’s backend.
• An expired TLS certificate.
• A captive portal not yet logged into.
• The remote server being down.

Always test:

ping <server-name>
curl -I https://<server-name>

If those fail, the firewall isn’t the issue.

Most “Mac firewall blocking app” complaints are fixed in Step 2 (just allowing the app in System Settings) or Step 7 (Local Network permission). The firewall on macOS is conservative by design — it blocks unsolicited incoming connections, not outgoing — and most apps don’t actually need anything special. The ones that do are usually well-behaved about prompting; click Allow once and you’re done.