linux - conntrack delete does not stop runnig copy of big file

I have a router with nat port forwarding configured. I launched a http copy of big file via the nat. The http server is hosted on the LAN PC which contains the big file to download. I launched the file download from WAN PC. I disabled the nat rule when file copy is running. the copy of file keep remaining. I want to stop the copy of file when I disable the nat forward rule with conntrack-tool.

my conntrack list contains the following conntrack session

# conntrack -L | grep "33.13"
tcp      6 431988 ESTABLISHED src=192.168.33.13 dst=192.168.33.215 sport=52722 dport=80 src=192.168.3.17 dst=192.168.33.13 sport=80 dport=52722 [ASSURED] use=1

I tried to remove it with the following command:

# conntrack -D --orig-src 192.168.33.13
tcp      6 431982 ESTABLISHED src=192.168.33.13 dst=192.168.33.215 sport=52722 dport=80 src=192.168.3.17 dst=192.168.33.13 sport=80 dport=52722 [ASSURED] use=1
conntrack v1.4.3 (conntrack-tools): 1 flow entries have been deleted.

the conntrack session is removed I can see in the following command. But another conntrack session was created with src ip address is the lan address of the removed conntrack

# conntrack -L | grep "33.13"
tcp      6 431993 ESTABLISHED src=192.168.3.17 dst=192.168.33.13 sport=80 dport=52722 src=192.168.33.13 dst=192.168.33.215 sport=52722 dport=80 [ASSURED] use=1
conntrack v1.4.3 (conntrack-tools): 57 flow entries have been shown.

I tried to remove the new conntrack but it keep remaining

# conntrack -D --orig-src 192.168.3.17

# conntrack -L | grep "33.13"
conntrack v1.4.3 (conntrack-tools): 11 flow entries have been shown.
tcp      6 431981 ESTABLISHED src=192.168.3.17 dst=192.168.33.13 sport=80 dport=52722 src=192.168.33.13 dst=192.168.33.215 sport=52722 dport=80 [ASSURED] use=1

What I m missing?

Answer

https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt

nf_conntrack_tcp_loose - BOOLEAN
0 - disabled not 0 - enabled (default)
If it is set to zero, we disable picking up already established connections.

So the already established connection is detected on-the-fly (without SYN/SYN+ACK/ACK involved) and added back as a new conntrack entry. Since it's a new conntrack entry, the nat table will be traversed again and the DNAT rule applied again. Even if one way doesn't work immediately (if there's no SNAT/MASQUERADE defined in addition to the DNAT rule the http server's outgoing packets might appear on WAN as 192.168.3.17 for a short while and be rejected/ignored by 192.168.33.13), as soon as the other way tries again (ACK retry from 192.168.33.13...) this will match.

Type this:

echo 0 > /proc/sys/net/netfilter/nf_conntrack_tcp_loose

And try again deleting the conntrack entry with conntrack -D ...

This should hopefully prevent a new conntrack entry to be created and cut the download.