Please help me understand the port allocation for Hide NAT on Maestro.

[okatsladz454]

Good afternoon, colleagues! 

I am currently studying the CCME guide and have come across a point that I would like to discuss with you.

The guide states that Maestro does not use GNAT in version 81.10 due to technical limitations. Instead, it uses Dynamic Allocation technology, which also has its own set of limitations. 

The most important question I have for these two lines is:

Example 1 - Maestro Security Gateway with 6 INSPECT/Instance Cores(default 2/6 CoreXL split of 8 total cores):

 Each instance has 8,333 source ports available for each Hide NATaddress/destination IP address pair.

Example 2 - Maestro Security Gateway with 48 cores and a default 4/44split:

Each INSPECT/Instance core only has 1,136 source ports available foreach Hide NAT address/destination IP address pair.

There is a greater risk of port exhaustion.

My main question is about the risk of port depletion for NAT connections when connections to certain destinations do not necessarily need to go through the same core instance. I might be misunderstanding something here.

 It's also not clear to me what the main advantage of Dynamic Allocation is over NET, since GNAT also doesn't expand the pool of available ports.

Thanks for your future answers. 

[Timothy_Hall · Accepted solution]

I was a contributor to the CCME course material and wrote this section.  The CCME material simplifies the discussion somewhat by citing an example of "Static Hide NAT source port allocation" which was used prior to R77.30, which is close but is not precisely how Dynamic Port allocation works.  Everything in the next paragraph applies equally to "regular" gateways and Maestro gateways.  

GNAT was introduced on standard security gateways in R80.40 and Maestro gateways in R81.20.  GNAT is enabled by default on gateways with 8 more more total cores (whether SMT or not).  As stated with the older Dynamic Allocation, for each Hide NAT address a portion of the 50,000 available ports are allocated via an initial quota block to the various CoreXL instances as needed.  If the instance needs more it can request another block and also release blocks if no longer needed.  With GNAT, a global pool of ports for each Hide NAT address can be allocated one-by-one on demand by the CoreXL instances as they need them for each new Hide NAT operation, instead of pulling a larger block of source ports from the pool which may end up not being completely used.  This more efficient GNAT allocation reduces the chance of port exhaustion, especially as the number of instances increases which is why it is only enabled on gateways with 8+ cores, since GNAT does cause additional allocation/deallocation overhead.

Now let's talk Maestro.  First off the Orchestrator does a simple hash calculation based on the pre-NAT packet IP addresses (and port number if L4 distribution is enabled) when deciding which security group member to send the packet to.  If the packet is the first of a new connection, the Dynamic Dispatcher on the security group member who received the packet allocates it to a CoreXL instance for handling, based on which instance has the lowest CPU load.  In theory different connections that are Hide NATted behind the same IP address yet all going to the same destination IP address should usually end up on different CoreXL instances.  But even if they don't and they all somehow end up on the same instance, GNAT helps ensure that a situation will not occur where a certain instance cannot allocate any more source ports for that Hide NAT address (exhaustion), yet some other instance is holding onto some of the available, yet unused source ports for itself corresponding to the same Hide NAT address.

So you are correct GNAT does not increase the total number of Hide NAT source ports beyond 50k, but it helps ensure that the source ports for each Hide NAT address are allocated and released as efficiently as possible among the instances, without "wasting" unused source ports thus increasing the chance of exhaustion.