NAT Pool Capacity Calculator
Size a NAT or SNAT public address pool from client sessions, planning reserve and hot-destination demand with headroom and failure checks.{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }}{{ badge.value }}
Topology preview unavailable; the calculation remains active.
| Measure | Value | Planning meaning | Copy |
|---|---|---|---|
| {{ row.metric }} | {{ row.value }} | {{ row.note }} |
| Check | State | Recommendation | Copy |
|---|---|---|---|
| {{ row.metric }} | {{ row.value }} | {{ row.note }} |
| Scenario | Public IPs | Client capacity | Planning note | Copy |
|---|---|---|---|---|
| {{ row.scenario }} | {{ row.publicIps }} | {{ row.clientCapacity }} | {{ row.note }} |
Introduction:
A shared internet address can run out of translated source ports long before a circuit runs out of bandwidth. The symptom may look random: some new connections fail while existing sessions continue, or one busy service becomes unreachable even though overall NAT utilization still looks acceptable.
Network address translation (NAT) rewrites addressing information as traffic crosses a gateway. Port address translation, often called PAT or source NAT (SNAT), also assigns a translated source port so many inside clients can share one public IPv4 address. Each active translation consumes allocator state, and the practical inventory depends on the platform, protocol, destination tuple, timeouts, blocked ranges, and any per-host limits.
- Translated-port inventory
- The source ports available per public address after exclusions.
- Planning demand
- The larger of estimated client sessions and observed active translations.
- Hot destination
- One destination address, destination port, and protocol that receives a large share of connections.
- Planning reserve
- Capacity deliberately kept unused for bursts, growth, measurement error, and uneven allocation.
Aggregate sizing starts with public addresses multiplied by effective ports per address. Demand starts with peak active clients multiplied by concurrent sessions per client, then adds a growth allowance. Those totals can still hide concentration. Some NAT systems limit how many translations each public address can create toward the same destination tuple, so a popular API, identity provider, database endpoint, or content origin can exhaust its tuple budget first.
The peak population should describe clients that are active at the same time, not every registered device. Sessions per client should come from gateway telemetry during a representative busy period when possible. Browsers, service meshes, retrying applications, and pools of short-lived API connections can create far more simultaneous translations than a simple one-user-one-session assumption suggests.
| Risk | What can look healthy | What reveals the problem |
|---|---|---|
| Aggregate exhaustion | Public addresses are reachable | Reserve-adjusted pool has fewer ports than peak demand |
| Hot-tuple exhaustion | Total pool utilization is moderate | One destination's demand exceeds its tuple-specific capacity |
| One-address loss | Normal operation fits | The remaining addresses cannot carry the peak client count |
| Per-host limit | Pool has spare ports | One inside client reaches its own translation cap |
Capacity arithmetic is a planning model, not a vendor guarantee. Allocation algorithms, endpoint-dependent mapping, protocol pools, idle timeouts, port reuse, connection tracking limits, and platform quotas can lower usable capacity. Confirm the selected inventory and limits against current documentation and live telemetry.
How to Use This Tool:
Size the translated-port pool for the busiest simultaneous period, then test both aggregate and destination-concentrated demand.
- Choose the closest Platform profile and confirm the visible Port inventory per IP against the live gateway. Edit the value when the platform, protocol, or configuration differs.
- Enter only active translated Public IP addresses. The one-address-loss scenario is calculated separately, so do not remove an address twice.
- Enter Peak active clients and Sessions per client from the same busy period. Add Observed translations when telemetry gives a stronger peak than the client estimate.
- Set the Planning reserve, Session growth allowance, and Hot destination share. A higher reserve reduces usable capacity; growth and concentration raise demand.
- Record unavailable ports or an inside-host cap only when those limits apply to the selected allocator. A per-host cap is a separate warning and does not increase pool capacity.
- Read the state, spare ports, required public addresses, hot-destination headroom, and one-address-loss capacity together before approving the design.
Interpreting Results:
Within plan means that aggregate and hot-destination demand remain below their reserve-adjusted budgets and neither review boundary has been reached. It does not guarantee that the gateway's connection table, per-host quota, or timeout behavior will support the workload.
Reserve review begins at 85% aggregate utilization or 80% hot-destination utilization. Aggregate shortfall takes priority when total planning demand exceeds usable ports. Hot-tuple shortfall applies when the aggregate pool fits but concentrated demand exceeds the same-destination budget.
Check the one-address-loss result separately. A pool that passes normally but shows negative spare clients after losing one public address has no modeled maintenance or failure margin.
Technical Details:
NAT pool sizing combines a port inventory, a concurrency estimate, and a reserve policy. The model treats each simultaneous translation as one unit of demand. It does not simulate port reuse or timeouts; those behaviors must already be reflected in the observed or estimated peak.
Formula Core
Unavailable ports are removed first. Reserve is then withheld from the remaining pool, while client demand is increased by the growth allowance.
| Symbol | Meaning | Unit |
|---|---|---|
| N | Active public IP addresses | count |
| P | Translated-port inventory per public IP | ports |
| B | Unavailable ports per public IP | ports |
| R | Planning reserve divided by 100 | ratio |
| U | Peak active clients | clients |
| S | Sessions per client | translations/client |
| G | Session growth allowance divided by 100 | ratio |
User capacity is the floor of usable ports divided by adjusted sessions per client. Reserve ports are rounded up to a whole port. Required public addresses use the unrounded reserve-adjusted capacity per address and are rounded up, with a minimum result of one.
Lookup Core
Profiles supply planning inventories. Editing a profile-derived value makes the entered inventory authoritative for the calculation.
| Profile | Ports per IP | Same-destination ports per IP |
|---|---|---|
| Generic PAT / SNAT | 64,512 | 64,512 |
| Cisco interface overload range | 59,399 | 59,399 |
| Palo Alto DIPP | 64,512 | 64,512 |
| FortiGate dynamic SNAT | 60,416 | 60,416 |
| AWS NAT Gateway | 55,000 | 55,000 |
| Azure NAT Gateway | 64,512 | 50,000 |
| Google Cloud NAT | 64,512 | 64,512 |
| Custom | Entered value | Entered value |
Hot-destination demand equals planning demand multiplied by the entered destination share. Hot-destination capacity equals public addresses multiplied by the smaller of effective ports and the profile's tuple limit, then multiplied by one minus the reserve. The one-address-loss capacity repeats the usable-port calculation with one fewer public address.
Rule Core
| First matching condition | Status |
|---|---|
| Aggregate spare ports < 0 | Aggregate shortfall |
| Hot-destination spare ports < 0 | Hot-tuple shortfall |
| Aggregate utilization ≥ 85% or hot-destination utilization ≥ 80% | Reserve review |
| Otherwise | Within plan |
The inside-host cap is compared with adjusted sessions per client as a separate diagnostic. It does not reduce the aggregate pool or change the ordered state.
Accuracy Notes:
Vendor port inventories and allocation behavior can change by product, protocol, region, address count, and configuration. Treat every preset as a reviewed planning value and replace it with the platform's current documented or measured limit when they differ.
- Observed active translations control demand only when they exceed the client-based estimate.
- One session is modeled as one translated port; timeout churn and reuse are not simulated.
- Connection-table memory, quotas, per-destination rules, protocol separation, and per-host limits can fail before aggregate port exhaustion.
Worked Examples:
Eight-address shared pool
Eight generic addresses at 64,512 ports each provide 516,096 gross ports. A 20% reserve leaves 412,876 usable ports after whole-port rounding. At 2,800 active clients and 120 sessions each, demand is 336,000, utilization is about 81.4%, and the modeled client capacity is 3,440. Losing one public address still leaves room for 210 clients.
Aggregate shortfall despite four addresses
Four AWS planning-profile addresses provide 176,000 usable ports after a 20% reserve. A peak of 3,200 clients at 90 sessions each needs 288,000 translations, leaving a 112,000-port shortfall. The required-address result rounds up to seven; the hot-destination budget still fits, but aggregate shortfall takes priority.
References:
- RFC 2663: IP Network Address Translator Terminology and Considerations, Internet Engineering Task Force, August 1999.
- RFC 4787: Network Address Translation Behavioral Requirements for Unicast UDP, Internet Engineering Task Force, January 2007.
- NAT Gateway Basics, Amazon Web Services.
- Azure NAT Gateway Resource, Microsoft.
- Cloud NAT IP Addresses and Ports, Google Cloud.