netfilter buglog - May 2020 - [Bug 1427] New: can not reuse source port to a DNATed IP if it is being used by another connection

https://bugzilla.netfilter.org/show_bug.cgi?id=1427

            Bug ID: 1427
           Summary: can not reuse source port to a DNATed IP if it is
                    being used by another connection
           Product: netfilter/iptables
           Version: unspecified
          Hardware: x86_64
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: NAT
          Assignee: netfilter-buglog at lists.netfilter.org
          Reporter: antonio.ojea.garcia at gmail.com

Scenario:

There is one established connection IP1:Port1 -> IP2:Port2
There is a DNAT rule like IP3:Port3 -> IP2:Port2

If a new connection is created from IP1 to IP3:Port3,
and this connection has source port Port1,
the connection can not be established,
because the incoming packet is not de-natted

The bug was originally reported in Kubernetes:
https://github.com/kubernetes/kubernetes/issues/90258

but I was able to reproduce it here:
https://gist.github.com/aojea/4ffb520db9f72de21685294d8fec7f33

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20200521/e3bbbd34/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1427

Florian Westphal <fw at strlen.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|netfilter-buglog at lists.netf |fw at strlen.de
                   |ilter.org                   |
                 CC|                            |fw at strlen.de

--- Comment #1 from Florian Westphal <fw at strlen.de> ---
I will have a look, but this might not be a conntrack
problem.
>From the gist:
[root at localhost ~]# conntrack -E | grep 60974
    [NEW] tcp      6 120 SYN_SENT src=192.168.121.44 dst=10.96.0.1 sport=60974
dport=443 [UNREPLIED] src=192.168.121.1 dst=192.168.121.44 sport=6443
dport=1362
 [UPDATE] tcp      6 60 SYN_RECV src=192.168.121.44 dst=10.96.0.1 sport=60974
dport=443 src=192.168.121.1 dst=192.168.121.44 sport=6443 dport=1362
 [UPDATE] tcp      6 60 SYN_RECV src=192.168.121.44 dst=10.96.0.1 sport=60974
dport=443 src=192.168.121.1 dst=192.168.121.44 sport=6443 dport=1362
 [UPDATE] tcp      6 60 SYN_RECV src=192.168.121.44 dst=10.96.0.1 sport=60974
dport=443 src=192.168.121.1 dst=192.168.121.44 sport=6443 dport=1362
 [UPDATE] tcp      6 60 SYN_RECV src=192.168.121.44 dst=10.96.0.1 sport=60974
dport=443 src=192.168.121.1 dst=192.168.121.44 sport=6443 dport=1362
[DESTROY] tcp      6 src=192.168.121.44 dst=10.96.0.1 sport=60974 dport=443
src=192.168.121.1 dst=192.168.121.44 sport=6443 dport=1362 delta-time=67

This means conntrack picks up the 2nd request (SYN_SENT),
and also processes the syn/ack reply from peer (state changes to SYN_RECV).

The only 'bug' i see so far is the misleading "invalid" in
this log message:

[60184.546120] nf_ct_tcp: invalid packet ignored in state SYN_RECV IN=
OUTSRC=192.168.121.44 DST=10.96.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=21806 DF
PROTO=TCP SPT=60974 DPT=443 SEQ=4078343799 ACK=0 WINDOW=29200 RES=0x00 SYN
URGP=0 OPT (020405B40402080A0391C7440000000001030306) UID=0 GID=0

The packet is NOT invalid -- conntrack accepts it.

Its ignored because its another SYN packet, while kernel expects ACK (to bring
state from SYN_RECV to ESTABLISHED).  But this packet is not marked as INVALID
 and not dropped.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20210219/29273eeb/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1427

Florian Westphal <fw at strlen.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #2 from Florian Westphal <fw at strlen.de> ---
This is caused by bad interaction between TCP early demux and the NAT engine.
Test case works with "sysctl net.ipv4.tcp_early_demux=0"

patch to detect this case & undo the wrong lookup:

https://patchwork.ozlabs.org/project/netfilter-devel/patch/20210224162321.4899-2-fw
at strlen.de/

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20210224/4e625cfa/attachment.html>