> The other thing worthy of note is that it appears every single packet will need to be processed through this application

No, only the initial connection requests will go into the netfilter queue (as well as DNS requests so that it knows what a particular IP actually refers to). Packets sent as part of a connection aren't vetted, and it uses the marking feature of netfilter so all of the actual filtering is done by the kernel.

If performance becomes an issue, the packet processing stuff could be split out into a faster daemon.

I'm surprised, I expected this to be an iptables frontend.

What would a "pure iptables front end" be and how would it learn about connection attempts? (Serious question, it's quite possible I'm forgetting an API)

The used technique, redirecting initial packets to a netfilter queue and then marking the connection to offload further processing to the kernel seems like a reasonable way to do this from userspace.

I don't know enough about Linux networking - I didn't realise the distinction between iptables and netfilter. Off to do some reading - thanks.

(I interpreted "iptables frontend" as probably meaning something that just generates iptables rules, that's why I was asking)

netfilter is the underlying kernel infrastructure, that's used e.g. by iptables to set rules for packets. From this https://github.com/evilsocket/opensnitch/blob/master/opensni..., it looks like OpenSnitch uses iptables to set rules so that the kernel delivers outgoing packets that don't belong to an existing connection to a queue. It then can use said queue to only intercept those packets – if it lets them pass, a connection will be created and further packets will not be passed to/handled by OpenSnitch. It touches the first packet of each outgoing connection, but not all traffic.

Connection requests shouldn't be a performance issue on a standard desktop.

If I understand it correctly, it only intercepts DNS and the beginning of new connections: https://github.com/evilsocket/opensnitch/blob/master/opensni...

OpenSnitch author here ... although performances are not a big deal here because only conntrack packets are intercepted, the project will move to a C++ implementation once the current Python prototype/PoC will be complete and will prove that what I want to do is 100% doable on GNU/Linux :)

I would say that golang is good enough. But if you are interested , you could go for Rust. Multiple teams have built extremely high performance network manipulation tools in Rust - like linkerd-tcp .

Unless you were planning to use Ragel.

As I said, it'll be in C++, Go is great, Rust too, but I just can't get used to their syntax :D

Once I saw OpenSnitch I decided to write my own in Rust (mostly as a learning experience for myself)[1] -- it's still obviously WIP as it doesn't even filter packets yet! My intention is to make it have a remote API so that policy decisions aren't done in the daemon but are done in swappable clients.

[1]: https://github.com/cyphar/whistled

I thought the Ragel stuff was back in.

I hoped so too. I think someone is forking it, but AFAIK it's c or ASM only.

I'd have selected Go or Rust my self.

The performance of this Python implementation will be interesting to watch.

Doesn't it just need to watch what ports are accessed by applications and allow/deny with a firewall?