On 9/15/12, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote: > Mans Nilsson wrote:
I am not suggesting that. I'm just trying to point out that there might be a bunch of assumptions that aren't as true anymore when a lot of client connections share both source and destination address, and perhaps also destination port. If this happens simultaneously when a large amount of other tcp connections are NATed through the same box, resource starvation will occur.
Assumptions that are already broken in Enterprise networks where 100+ users may share an IP What you can use is an edge device with a large NAT table, 30000 entries at least; setup a policy that limits each private IP address to 50 simultaneous TCP connections, to protect NAT device against malware-infected laptops, You might also use a wireless AP and Ethernet switches with PVLAN (or protected port bridging) and DHCP snooping functionality, then configure to restrict attached devices from sending or receiving any kind of IP or Ethernet broadcast traffic with other hosts on the LAN, And ensure the NAT/Firewall device will not route traffic from the Inside interface back to the Inside interface, so the NAT device and DHCP server are the only units that attached nodes may communicate with. Use a short NAT timeout period for UDP (30 seconds), so there is a certain number of users that your NAT device can service, depending on its CPU power and NAT table size. You can calculate an upper bound for required NAT table capacity, based on number of users, and number of allowed connections per user. Then take your total number of users, Divide by say 20, and build a NAT pool with that many public IP addresses, For example: one /24 of public IP addresses per 5000 users. to accomplish on average 20 users per public IP, providing you pick a NAT/Firewall device balances internal private to public IP usage fairly evenly. -- -JH