SNAT not translating all iperf3 packets

SNAT not translating all iperf3 packets

[dynexbeats]

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.

Re: SNAT not translating all iperf3 packets

[dynexbeats]

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@protonmail.com> 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.