PAT Capacity and Logging After an ASA-to-FTD Cutover
A university replaces an ASA with a Cisco Secure Firewall 3105 HA pair. The inside network is 10.50.0.0/16 with about 4,000 concurrent users; outside is 198.51.100.0/24. The ISP assigned only 198.51.100.10 and .11. The migrated NAT rule is dynamic PAT using .10 for all inside addresses. Within an hour of cutover, users report failures to Microsoft 365 and other SaaS apps; FMC shows NAT allocation errors, and the translation table is near its limit. The security team also wants to identify which internal user made each outbound connection for incident response, but current logs show only the translated address and port. A second public IP is unused. The default route and access control policy are correct. The customer cannot request more public addresses for at least two weeks.
1. Diagnose why the single-IP PAT rule is exhausting ports and what immediate change would reduce the failures.
Read the worked answer
Single-IP PAT has a hard ceiling of roughly 64,000 TCP and UDP ports per translated address, minus reserved and in-use ports. 4,000 users with SaaS, Teams, and browser sessions can easily exceed that when TIME_WAIT and long-lived connections are counted. The NAT allocation error and near-limit translation table confirm port exhaustion, not a routing or ACP failure. Adding 198.51.100.11 to a PAT pool roughly doubles the port space and distributes translations. Use a dynamic PAT pool with both addresses; choose block allocation if per-user logging is required, because each inside host receives a block of ports that can be mapped back to the user. Round-robin spreads load but makes correlation harder. This is an interim fix for the two-week constraint; long-term, add public addresses or reduce unnecessary connections. Do not solve it by shortening idle timeouts alone, because that can break applications and does not address the fundamental port shortage.
2. How would you configure and verify the NAT change so that per-user logging remains possible?
Read the worked answer
Configure a dynamic NAT rule for 10.50.0.0/16 with PAT pool 198.51.100.10-198.51.100.11. Enable block allocation and logging on the rule; use include-reserve only after confirming application compatibility. Keep the original rule disabled, not deleted, until verification is complete. Verify with show nat, show nat pool, show conn, and show run nat; on FMC check connection events and NAT translations. Generate load from several inside hosts and confirm that source ports map to both public addresses. For per-user attribution, export connection events with initiator IP and translated port, or use NetFlow or syslog to a collector. Block allocation helps because each user's ports belong to a recognizable block; it is not a substitute for identity logging. If the customer needs user names rather than IPs, integrate identity or authenticate the proxy.
3. If failures continue after adding the second IP, what would you check next and what interim control would you recommend?
Read the worked answer
Check whether the pool is still exhausting, whether a few talkers consume most ports, and whether applications are opening many short-lived connections. On FMC, review top talkers, connection counts, and NAT allocation errors; on FTD use show conn and show nat pool. Look for half-open connections, scanning, or a misconfigured application retry loop. As an interim control, rate-limit or block nonessential high-connection traffic, and prioritize business applications with QoS or ACP rules. Do not simply increase timeouts without understanding application behavior. If port demand remains above capacity, the only durable fixes are more public addresses, NAT64 or HTTP proxy for selected traffic, or reducing the number of translated users. Document the capacity calculation so the two-week temporary pool is not treated as a permanent design.