[edit] It boils down to principle of least surprise, managing expectations, etc. - proper documentation is indeed key.
(I'm not impartial about Tailscale.)
Humility helps a lot on the internet- the important thing about iptables is that it runs on millions, possibly billions of machines. Production systems that don't have unit tests but run at scale aren't worse than systems which are newly introduced but have fairly unknown implications.
I'm not making a value judgement about people who need to keep using iptables. I might be making a value judgement about people who demand that everyone else keep using iptables.
But, my point still stands. You can't simply assert your system is better, it has to be proven at a scale similar to iptables before you can say that.
(I'm not impartial about Tailscale, but I don't work there).
Well, that's certainly different from "all TCP port 22 packets" - I suppose some emphasis should be on "after the WireGuard decryption" (ie: over the wireguard interface). It's not entirely clear from the comment (but probably clear to engineers working on the tailscale code).
I read it as if tailscale snapped up packets before the kernel from (all) network interfaces...
> So it doesn't matter whether you have other processes (or iptables rules, etc) that would prevent the Tailscale SSH server from binding to port 22.
This sounds like a great feature when exploiting buggy WordPress/php apps! /s
I realize this is a feature - but it's a bit sad that the standard package handling isn't up to the task; leaving (I expect) the tailscale daemon as a "magic" netcitizen - not featuring in neither "ss" or "iptables" output (why can't I login to opensshd?).