NAT Gateway - Maximum connection limit

Solution 1:

Correct me if I'm wrong but this is the way I understand it. The limits are per client / server / port. So in light of that.

1) In TCP is a single source IP limited to 65536 MAX theoretical outgoing connections?

No. I believe it's limited to 65536 theoretical max to the same destination IP.

Windows workstations (non server versions) have limits imposed which make this number much less. Linux has resource limits, but they generally aren't hit by the average user and you can easily tweak them.

You'll probably hit other resource limits as you start increasing the number anywhere near 64K.

Consumer grade routers might have much lower limits due to the limited resources.

2) Or is the limit actually 65536 connections for each Remote Host?

Yes

3) Are the answers to questions 1 and 2 different for a ...'not normal system' [Cisco router acting as a NAT Gateway]?

No

4) The above questions all assume a stateful TCP connection. Is the story any different with a stateless conection like UDP?

UDP is connectionless. So this isn't really relevant to UDP.

5) Will our LAN be limited to 65536 (or some other theoretical limit) concurrent connections to the outside world through a single public IP address?

No.


In the context of stateful firewalls that track connections and provide other tracking features, yes these modules themselves may have limits. The op has not said anything about which firewall/NAT router is being used so we can't even speculate as to what limitations it might impose at the moment.

Solution 2:

Because there are many approaches to NAT design, the answer of course is "it depends." Geoff Huston wrote an excellent overview of various NAT designs.

In my experience many small-office/home-office routers will not handle > 64k addresses to the same address, but not just because of port exhaustion. Many have limited memory and will run out of RAM for a NAT table well before hitting the 64k limit.


Solution 3:

5) Will our LAN be limited to 65536 (or some other theoretical limit) concurrent connections to the outside world through a single public IP address?

No, because one port NAT IP can be used for multiple connections:

cat /proc/net/ip_conntrack | grep 51380
tcp      6 191 ESTABLISHED src=10.1.8.5 dst=17.133.254.23 sport=51380 dport=5223 src=17.133.254.23 dst=my.nat.pub.ip sport=5223 dport=51380 [ASSURED] mark=0 use=2
tcp      6 24 CLOSE_WAIT src=10.1.26.1 dst=80.68.255.71 sport=51380 dport=80 src=80.68.255.71 dst=my.nat.pub.ip sport=80 dport=51380 [ASSURED] mark=0 use=2

Solution 4:

The long-story-short is that it's heavily platform-dependent, configuration-dependent, and implementation-dependent.

But let me explain quickly:

Apparently, other answers state about the theory limit reaching >65535 (notice port 0 is often reserved), which migth be true to certain extent such as...:

  • In big CGNAT systems or similar high-grade routers, whose main purpose is this one, including NAT-PAT.
  • In certain Linux distro might be possible in theory when using a PC for software NAT/routing by CPU under certains circumstances such as ram > 1GB, kernel prepared, etc.

However in the real world, where hardware-accelerated routing takes place with limited resouce, the NAT table has a well-known limit, which is often a configuration parameter for protection.

  • Cisco mentions starting at IOS 12, the max NAT depends on DRAM resulting on around ~10K translations (source), which is less than those 65K in your question.

  • Take your old xDSL router, if you want to bring up a P2P at home with many connections, most of them have configured a global max-limit of 1024~4096. For instance my high-end FTTH router at home has NAT limit configured to 8K by the vendor.

Finally, to answer Q2-rewrite, I have seen products with dispair implementations of RFC3489 with the following NAT tables. Obviously the last one does limit considerably the NAT posiblities:

  • iAddr:iPort - eAddr:ePort - dAddr:dPort (typical symmetric nat)
  • iAddr:port - eAddr:port - dAddr (very low end product)

Tumbs up if you like this answer!