Re: How to understand causes of invalid state for an OUPUT SYNACK packet

[Florian Westphal <fw@strlen.de>]

Jerome Barotin <jbn@s4e.fr> 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.