Comment by huhtenberg
7 hours ago
> Plenty of setups block incoming SYN,!ACK packets
Even in the presence of a conntrack entry created by an earlier outbound SYN,!ACK ?
Got a source?
7 hours ago
> Plenty of setups block incoming SYN,!ACK packets
Even in the presence of a conntrack entry created by an earlier outbound SYN,!ACK ?
Got a source?
I've seen plenty of firewall rulesets over the past 25 years which only consult state after doing some initial stateless inspection.
I don't have a convenient source though.
Sanity 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.
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 :)
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.)
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.
1 reply →