alt Hacker NewsSanity checks, sure, but SYN,!ACK packets cannot be rejected before the conntrack for obvious reasons.
> Plenty of setups block incoming SYN,!ACK packets
Nowhere close to being "plenty". It's doable, but this is extremely niche.
Replies
cperciva • yesterday at 5:02 PM
for obvious reasons
What are the obvious reasons? If you're protecting a client system, you don't want to allow in any bare SYNs. (And for that matter, if you're protecting a server, you probably want to discard ill-targeted bare SYNs without consulting conntrack anyway, just as a matter of avoiding extra CPU work.)
gzread • yesterday at 5:11 PM
Does this mean by establishing a new connection with a SYN,ACK bypasses some firewalls? I expect at least one OS out there ignores the extraneous ACK flag and proceeds to establish a new connection.
➕ show 1 reply
It's not uncommon with routable internal networks to only drop inbound SYN,!ACK to disallow inbound connections while permitting outbound ones, since it doesn't require connection tracking (which can be resource intensive).
I can't really imagine why you would do it for NAT'd v4 since you can't avoid the connection tracking overhead, but you certainly could, and I don't doubt OP has run into it in the wild. I've seen much weirder firewall rules :)