netdev - Re: masquerading AFTER first packet

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210902205423.GG3350910@belle.intranet.vanheusden.com>
Date:   Thu, 2 Sep 2021 22:54:23 +0200
From:   folkert <folkert@...heusden.com>
To:     Florian Westphal <fw@...len.de>
Cc:     netdev@...r.kernel.org
Subject: Re: masquerading AFTER first packet

> > [Thu Sep  2 19:40:54 2021] nf_ct_proto_17: bad checksum IN= OUT= SRC=192.168.4.2 DST=185.243.112.54 LEN=82 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=161 DPT=56523 LEN=61
> 
> So reverse direction packets are deemed invalid and are thus not reverse-translated.
> 
> This is a bug, but not sure where.  What driver/nic is feeding these
> packets to stack?

> sysctl net.netfilter.nf_conntrack_checksum=0
> should make things "work".

Indeed it does!

"The other end", the one feeding the packets, is a toy IP-stack
implementation of myself. I verified the correctness of the IP/UDP
checksums by looking at wireshark (after enabling them) and tcpdump;
they both say all is fine (else I wouldn't bother this mailinglist with
this). https://github.com/folkertvanheusden/myip by the way (not a full
implementation, just the bare essentials to get tcp/udp working).

Now there are also situations (different ISPs/VPS providers) where
no packets at all are received (and situations where all are received!).
I guess that can be explained by that some are less strict than others.

So conclusion: my IP-stack *may* be producing incorrect checksums, or
Linux or tcpdump and wireshark may be incorrectly evaluating them?

Folkert.