On Thu, 31 Jan 2019, Dominique Martinet wrote: > Jozsef Kadlecsik wrote on Thu, Jan 31, 2019: > > > tcpdump loops on: > > > 05:30:41.411346 IP x.y.z.34.49149 > x.y.z.1.24007: Flags [S], seq 837922022, win 26880, options [mss 8960,sackOK,TS val 1689048672 ecr 0,nop,wscale 7], length 0 > > > 05:30:41.411481 IP x.y.z.1.24007 > x.y.z.34.49149: Flags [S.], seq 1749683989, ack 837922023, win 26844, options [mss 8960,sackOK,TS val 560823762 ecr 1689017605,nop,wscale 7], length 0 > > > 05:30:57.595860 IP x.y.z.1.24007 > x.y.z.34.49149: Flags [S.], seq 1749683989, ack 837922023, win 26844, options [mss 8960,sackOK,TS val 560839947 ecr 1689017605,nop,wscale 7], length 0 > > > > [...] > > > > For some reason nf_conntrack_log_invalid does not output anything to > > > dmesg, but adding log rules before and after the default firewalld's > > > INPUT --ctstate INVALID -j DROP rule shows that the synack packets fall > > > there (and should have been picked up by the RELATED rule earlier and > > > weren't) > > > > We need the SYN/ACK packet as well. Without the packet data there's no way > > to tell why conntrack classified it as INVALID. Packet logging is not > > enough, please capture the whole (broken) traffic between the server and > > the client. > > I'm not sure I follow; I didn't give the packet logging here but I did > give the tcpdump textual representation above (left in the quote, it > does list sequence/window/ack) -- that's all the broken traffic I have > right now, I don't have the leading sequence. > > iirc last time I was able to give you a pcap file, but I unfortunately > cannot do this as work imposes a restriction on exporting data and I > cannot give e.g. the IPs out. If you have particular fields you'd like > to see from a trace I can export them though (tshark in superverbose > mode just masking IPs would do?) > > I've been trying to reproduce ever since sending my mail and I'm super > annoyed because I managed to reproduce once but tcpdump wasn't running > (I decided to use more clients to test and forgot to run tcpdump on all > the clients); but since I could reproduce once I'll eventually get it > again... Sorry, my fault. Shouldn't write before "booted" properly :-). Unfortunately a full packet dump is required. I mean, it should contain the full previous successful connection and the next failing one. Only the IP/TCP headers are required, without the payload and the IP addresses can be munged. Where does the firewall run? On the clients? So the kernel version 3.10.0-693.11.6.el7.x86_64 for the firewall itself, doesn't it? Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary
