Hello,
Just a follow up, after some further testing, I no longer see the symptoms of traffic flows not being SNAT'ted after implementing the following kernel parameter on the host performing the SNAT (reboot was needed, not enough to do ' sysctl -p '):
net.netfilter.nf_conntrack_tcp_be_liberal=1
Hope this helps others noticing these symptoms.
Take care.
------- Original Message -------
On Tuesday, March 29th, 2022 at 11:20 AM, dynexbeats <dynexbeats@xxxxxxxxxxxxxx> wrote:
> Hello,
>
> I am doing testing with iperf3 (multiple connections) through a Linux node that is performing SNAT on all IP traffic to a pool of IPs, and I am noticing that a few iperf3 packets are not being SNAT'ted at all:
>
> snip of iperf3 server output
>
> [ 85] local 2.2.2.110 port 5201 connected to 3.3.3.4 port 37646
>
> [ 87] local 2.2.2.110 port 5201 connected to 3.3.3.4 port 37648
>
> [ 89] local 2.2.2.110 port 5201 connected to 3.3.3.4 port 37650
>
> [ 91] local 2.2.2.110 port 5201 connected to 192.168.20.20 port 37652
>
> [ 93] local 2.2.2.110 port 5201 connected to 3.3.3.4 port 37654
>
> [ 95] local 2.2.2.110 port 5201 connected to 3.3.3.4 port 37656
>
> /snip
>
> I noticed a few threads in this mailing list mentioning that conntrack packets/flows that are viewed as INVALID will not be SNAT'ted, however I am not understanding how that can be with the traffic I am generating with iperf3. It appears that all the connections iperf3 is generating are essentially the same with the exception of the source port (look to be increments of 2).
>
> The session does appear to be normal (or valid) as per the " conntrack -L " output:
>
> snip of ' conntrack -L ' output
>
> tcp 6 282 ESTABLISHED src=192.168.20.20 dst=2.2.2.110 sport=37646 dport=5201 src=2.2.2.110 dst=3.3.3.4 sport=5201 dport=37646 [ASSURED] mark=0 use=1
>
> tcp 6 282 ESTABLISHED src=192.168.20.20 dst=2.2.2.110 sport=37648 dport=5201 src=2.2.2.110 dst=3.3.3.4 sport=5201 dport=37648 [ASSURED] mark=0 use=1
>
> tcp 6 282 ESTABLISHED src=192.168.20.20 dst=2.2.2.110 sport=37650 dport=5201 src=2.2.2.110 dst=3.3.3.4 sport=5201 dport=37650 [ASSURED] mark=0 use=1
>
> tcp 6 282 ESTABLISHED src=192.168.20.20 dst=2.2.2.110 sport=37652 dport=5201 src=2.2.2.110 dst=192.168.20.20 sport=5201 dport=37652 [ASSURED] mark=0 use=1
>
> tcp 6 431982 ESTABLISHED src=192.168.20.20 dst=2.2.2.110 sport=37654 dport=5201 src=2.2.2.110 dst=3.3.3.4 sport=5201 dport=37654 [ASSURED] mark=0 use=1
>
> tcp 6 282 ESTABLISHED src=192.168.20.20 dst=2.2.2.110 sport=37656 dport=5201 src=2.2.2.110 dst=3.3.3.4 sport=5201 dport=37656 [ASSURED] mark=0 use=1
>
> /snip
>
> Is there anything that I am missing or not taking into consideration??
>
> Here is the iperf3 (client side) command I am using:
>
> iperf3 -Z -t 300 -P 37 --connect-timeout 2000 -c 2.2.2.110
>
> -Z = zerocopy /// -t = duration in seconds (5min) /// -P = parallel connections or streams
>
> Here is the nftables ruleset for the forwarding and SNAT function:
>
> table inet testing {
>
> chain forward {
>
> type filter hook forward priority 0; policy drop;
>
> ct state { established,related } limit rate 200 mbytes/second burst 64 kbytes counter accept;
>
> ct state { new } counter accept;
>
> }
>
> chain postrouting {
>
> type nat hook postrouting priority srcnat;
>
> ip protocol {tcp,udp,icmp} oif vlan2001 snat to 3.3.3.3-3.3.3.4;
>
> }
>
> }
>
> Linux node performing SNAT is running 5.13.0-27 kernel.
