I followed your advice and I have set up a vm with a forwarding rules between my device and my server, and then I saw that the SYN-ACK packet is crossing the vm. So I think my issue was not due to netfilter but much more to a misconfigured firewall on the device. Thanks a lot for your reply Florian, you helped me moving forward on this issue. Le Fri, 21 Jan 2022 13:40:59 +0100, Florian Westphal <fw@xxxxxxxxx> a écrit : > Jerome Barotin <jbn@xxxxxx> wrote: > > I've got a specific device (industrial computer) where its > > TCP connection are always blocked by netfilter when it tries to > > connect to my server. > > > > Exactly the SYN packet is forwarded to my local process, but, the > > SYN-ACK answer is always tagged as invalid by the conntrack > > module, > > Its not, the message is misleading. > > > I noticed this behaviour in the following line in kern.log : > > > > Jan 14 11:26:15 myhostname kernel: [260283.271861] nf_ct_proto_6: > > invalid packet ignored in state SYN_RECV IN= OUT= SRC=10.1.1.4 > > DST=10.1.1.3 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP > > SPT=21 DPT=64004 SEQ=1624381780 ACK=2190670817 WINDOW=64240 > > RES=0x00 ACK SYN URGP=0 OPT (020405B40101040201030307) > > Maybe we should just axe this message. The packet is *ignored*, not > marked as invalid. Such packet will NOT trigger -m conntrack > --ctstate INVALID. The wording was slightly changed in 5.12 kernel, > where this is now: > > nf_ct_proto_6: packet (index 1) in dir 1 ignored, state SYN_RECV > IN=... > > > The corresponding pcap file can be found here : > > https://filebin.net/yazmmekhrdiu4dh8/capture_not_work_ano.pcap > > Thanks, lets see (trimmed line length): > .3.64004 > 10.1.1.4.21: Flags [S], seq 2190670816, win 8192, options > [mss 1330,nop,wscale 8,nop,nop,sackOK], length 0 > > This packets gets us to SYN_SENT state: > tcp 6 116 SYN_SENT src=10.1.1.3 dst=10.1.1.4 sport=64004 > dport=21 [UNREPLIED] src=10.1.1.4 dst=10.1.1.3 sport=21 dport=64004 > mark=0 use=1 > > ... packet would match --ctstate NEW. > > .4.21 > 10.1.1.3.64004: Flags [S.], seq 1624381780, ack 2190670817, > win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 > > This packet gets us to SYN_RECV state. > ... packet would match --ctstate ESTABLISHED. > > .4.21 > 10.1.1.3.64004: Flags [S.], seq 1624381780, ack 2190670817, > win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 > > This packet produces the 'ignored' message quoted above, its ignored > because we already saw such packet before, so packet matches > ESTABLISHED state. > > .4.21 > 10.1.1.3.64004: Flags [S.], seq 1624381780, ack 2190670817, > win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 > > This repeats the message, no other side effects. > > .3.64004 > 10.1.1.4.21: Flags [S], seq 2190670816, win 65535, options > [mss 1330,nop,nop,sackOK], length 0 > > Similar message, this is for 'index 0' > > 4.21 > 10.1.1.3.64004: Flags [S.], seq 1624381780, ack 2190670817, > win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 > > > Also, I do not understand how this connection could be in SYN_RECV > > conntrack state. This state means that SYN-ACK packet has already > > been received and I'm sure that no such packet has already been > > submitted. > > Where was that dump taken? Its what I used to tcpreplay into a vm. > > > Do I miss something ? Anybody has got idea to help me understand > > (and fix) this case ? > > Is the conntrack machine forwarding or an endpoint? > > If forwarding, can you provide pcaps from the inbound > and outbound interfaces? > > You could also -j LOG packets in state INVALID to pinpoint which > packet really does get marked as INVALID, but afaict its not a > packet contained in the provided pcap.
