For a first baseline, we start with a client and a server, going through a server, with the same interface.

That gives us a first approach of a gateway impact.

276619 hits/s

Just having a gateway doesn't seem to have any impact on the number of connections we can handle.

Anyone that already used conntrack on a system having alot of connections noticed the default limits of connections tracking. If we want to handle hundreds of connections, we have to increase the default values.

# load the conntrack modules (ipv4)
iptables -I FORWARD -m state --state ESTABLISHED
iptables -D FORWARD -m state --state ESTABLISHED
# load the conntrack modules (ipv6)
ip6tables -I FORWARD -m state --state ESTABLISHED
ip6tables -D FORWARD -m state --state ESTABLISHED
# increase the max conntrack (default: 256k)
echo 33554432 > /proc/sys/net/netfilter/nf_conntrack_max
# increase the conntrack hash table size - default: 16k
echo 33554432 > /sys/module/nf_conntrack/parameters/hashsize 

That will give us some conntrack informations. Lets see what impact it has on our connection rate.

average over 5 minutes: 154726

But looking at the graph, we see a breakdown. It starts at 180k for 120 seconds, then there is a drastic drop to an average of 137k for the rest of the time.

As the conntrack count increase in a linear form, up to about 21.5M, and decrease from that time, it seems to drop when the first timeout start to hit.

Having conntracking gives a performance hit. Having tracking timeouts while gives an other performance hit.

For our heavy connections, we clearly need to be able to *not* track them.