[paws]

The more macOS seems to break user control of networking, the more I wonder what kind of "separate box" solutions are out there that can intermediate _outgoing_ traffic. e.g. Something like LittleSnitch on a router, where it notifies the Mac when it detects a new outgoing connection.

Do things e.g. pfSense support that already? "Hold" an outgoing connection from the moment the SYN is observed, notify whatever client, and only allow if the user clicks?

[smashed]

> Do things e.g. pfSense support that already? "Hold" an outgoing connection from the moment the SYN is observed, notify whatever client, and only allow if the user clicks?

Not that I am aware of.

This is a desktop centric workflow where the user can react live to an application that is sending traffic.

Your typical network firewall will apply a set of static rules and the decision to log/reject/drop is done ASAP. Waiting for user input is impossible.

Some systems can show logs of recent blocked traffic, and allow an admin to quickly generate an exception/allow rule for blocked traffic but that's pretty much it.

[jerf]

With some work you could integrate the two; create an external box paired with an app on your source machine. When the source machine can see more info about the connection it can cooperate to pass it along to the middlebox, and if the middlebox sees something the source system has no idea about, well, that's useful info to annotate the network connection with.

[fiddlerwoaroof]

Most of the alternatives that aren’t marketed to the consumer immediately have something. I ran openwrt for years and used its firewall to block a bunch of traffic and now I’ve switched to Ubiquiti because of wifi issues.

[catiopatio]

pf’s `divert-to` can be used to divert packets to a local port; `getsockname()` will return the original destination address, so you can either close the connection, or proxy it in userspace.

Alternatively, you could possibly use a divert(4) socket — coupled with a targeted firewall rule — to divert only the initial SYN packet, and if the connection is to be permitted, re-inject it and allow connection to proceed normally.

OpenBSD supports using divert(4) sockets with pf; unfortunately, FreeBSD divert(4) sockets only work with the older ipfw firewall.

[meindnoch]

And how would you decide whether an outgoing connection to a random AWS IP is legit or not? You don't know which app is the source.

[WirelessGigabit]

Actually you do. You request a port on which your process will listen to the result of the call.

[azinman2]

So then you need each device to run software to communicate this to your router. This isn’t a purely router based solution.

[intelVISA]

If there's a market this could be an interesting weekend project.

[gonzo]

if you get something, lmk, and maybe we'll put it in pfsense.

that said, the description could be covered by something like captive portal.

[paws]

Not sure I'm understanding you correctly - by captive portals do you mean the "challenge" that renders in a browser/webview context, commonly when joining a new network? I'm not sure that would be suitable for what I describe above.

What makes LittleSnitch/Lulu/similar nice is they listen for "all" outgoing traffic types TCP/UDP/ICMP/etc, and show UI immediately, including for non-browser apps, e.g. games, VoIP, P2P apps, whatever -- it tends to be covered. Unless I'm mistaken I don't believe a captive portal can be triggered when "just any" process originates traffic.

That's the strength of LittleSnitch/similar, but the major weakness with host-level filtering they rely on, is you're 100% at the mercy of Apple's networking stack, and this Sonoma issue isn't the first time Apple moved the goalposts. Not too long ago Apple exempted their own services from whatever LittleSnitch hooks [1] and it could of course happen again with any macOS update.

In my view this is precisely why a separate box is appealing. Ideally it'd have as tight of a UI as the incumbent apps, including the same metadata (process name + app icon, protocol, port #, most recent previous attempt, etc).

[1] https://news.ycombinator.com/item?id=24838816

[bonestamp2]

I think the best you can do in pfSense would be to log it and then look at the logs regularly.

[_boffin_]

Interesting