Am 10.06.19 um 10:12 schrieb iam@xxxxxxxxxxx: > But what about tcpdump -tttttv from receiver side? > > Receiver got SYN: > 00:00:00.000000 IP (tos 0x28, ttl 49, id 280, offset 0, flags [DF], proto TCP (6), length 60) > dst_host > src_host: Flags [S], cksum 0x46ae (correct), seq 4063608731, win 29200, options [mss 1460,sackOK,TS val 332512899 ecr 0,nop,wscale 6], length 0 > > Receiver sent SYN+ACK: > 00:00:00.000071 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) > src_host > dst_host: Flags [S.], cksum 0x84c2 (incorrect -> 0x3c01), seq 1516815880, ack 4063608732, win 28960, options [mss 1460,sackOK,TS val 2341429130 ecr 332512899,nop,wscale 7], length 0 > > Receiver got ACK: > 00:00:00.079183 IP (tos 0x28, ttl 49, id 281, offset 0, flags [DF], proto TCP (6), length 52) > dst_host > src_host: Flags [.], cksum 0xda11 (correct), ack 1, win 457, options [nop,nop,TS val 332512918 ecr 2341429130], length 0 > > such low numbers are between syn_recv and syn+ack send, but between syn_recv and established it should be 00:00:00.079183 (79.183 ms) ping between hosts ~83ms, so there couldn't be no RTT > > handshake is working the same way for both sides and should take around 2 RTT 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 it's ESTABLISHED after SYN+ACK and i don't get what annoys you in the fact that something is fast and optimized? Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 17M 11G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 2 425K 24M INBOUND all -- wan * 0.0.0.0/0 0.0.0.0/0 ctstate NEW 3 418K 34M LOCAL all -- !wan * 0.0.0.0/0 0.0.0.0/0 ctstate NEW
