Got it, so if I'll somehow unload nf_conntrack from kernel, then I'll get natural timings for TCP handshake? Logic of my measurements is right if there is no optimisations from firewall perspective? 10.06.2019, 14:11, "Reindl Harald" <h.reindl@xxxxxxxxxxxxx>: > Am 10.06.19 um 12:51 schrieb iam@xxxxxxxxxxx: >> 10.06.2019, 12:52, "Reindl Harald" <h.reindl@xxxxxxxxxxxxx>: >>> Am 10.06.19 um 10:12 schrieb iam@xxxxxxxxxxx: >>> >>> for conntrack a connection is no longer new after the first *response* >>> packet has been seen, it's that easy and given that the first rule in >>> every chain should be to allow RELATED,ESTABLISHED this is a game changer >> >> is it right that conntrack just override natural behaviour of tcp handshake by immediately changing TCP state to ESTABLISHED right after getting first SYN packet, but in fact connection should be ESTABLISHED only after getting ACK from the client side? >> >> Yes, logic you've described is giving speed for packet processing and "optimized" for conntrack cases, but isn't it wrong to change state before it's really ESTABLISHED? >> >>> it's ESTABLISHED after SYN+ACK and i don't get what annoys you in the >>> fact that something is fast and optimized? >> >> ESTABLISHED after SYN+ACK sent and not after ACK receive and that annoys me > > from a firewall perspective it's enough that you a) accepted the SYN and > b) the backend ACK'ed it and for UDP it's the only option > > if you get no further package back there is no harm anyways > > if you get the ACK back it passes anyways to the backend > so what's the point going it the whole ruleset down? > > when you have thousands of connections per second on a large ruleset > that behavior makes the difference if you survive the load or not
