NAT Overload Port Exhaustion and a Second HTTPS Publication
An office has 250 laptops, 40 IP phones, and 30 servers behind one Cisco ISR doing NAT overload to 203.0.113.2/29 (usable .1-.6). The outside interface uses .2 for overload; .3 is statically mapped to a web server at 10.20.0.10; .4 is statically mapped to a mail server; .5 is unused; .6 is the provider gateway. Every weekday around 10:00, Teams calls and SaaS sessions fail, and the router logs NAT errors about being unable to allocate a port. show ip nat translations shows roughly 58,000 entries, more than 80 percent of them TCP 443 to two SaaS addresses, still present hours after the sessions ended; someone had previously set ip nat translation tcp-timeout 604800. A new guest VLAN 60 (10.60.0.0/24) on a separate Layer 3 switch cannot obtain addresses from the DHCP server at 10.10.0.5. The business also wants a second internal web server, 10.20.0.12, published on HTTPS.
1. Explain the port exhaustion quantitatively and rank the fixes by risk.
Read the worked answer
NAT overload multiplexes flows onto one public address using the transport source port, giving roughly 64,000 usable TCP ports on 203.0.113.2 (and separately on UDP). With 250 laptops each holding a few hundred concurrent browser/app connections, 58,000 live translations is credible; at that point new flows cannot be assigned a port and fail - which is exactly what the log reports. The 604800-second TCP timeout (seven days) is the amplifier: closed sessions keep their ports allocated, so the table never drains.
Fixes, lowest risk first: (1) restore a sane timeout, e.g. ip nat translation tcp-timeout 3600 plus a short finrst-timeout, and confirm with show ip nat statistics that the table drains. (2) Add the unused .5 to an overload pool (ip nat pool with overload) to double capacity, and, if DNS is heavy, keep DNS translations short. (3) Where traffic is destined for many distinct IPs, port reuse is limited by flow uniqueness - offload to a firewall with a larger public block. Buying more bandwidth does nothing: the constraint is translation table entries, not bits.
2. The business wants 10.20.0.12 served on HTTPS from the internet while .3:443 already maps to 10.20.0.10. What are the options and their trade-offs?
Read the worked answer
Static PAT is keyed on the outside address plus protocol plus port. Since 203.0.113.3:443 is already consumed, adding a second mapping for the same tuple on the same address is rejected by the router, and if it were not, inbound traffic could not be demultiplexed.
Options: (1) Use the free .5 for the second server: ip nat inside source static tcp 10.20.0.12 443 203.0.113.5 443, with a matching inbound ACL permit. Simplest and cheapest; requires DNS records for the second name to point at .5, and clients must use that name. (2) Terminate both names on a reverse proxy that inspects SNI and forwards to the correct backend - one public address, but a new device and certificate management. (3) Publish on a different external port (e.g., 8443), which breaks default-port clients and is usually unacceptable. (4) IPv6, if available, removing NAT entirely.
Remember the DNS and ACL sides: certificate SANs must cover the name actually used, and the outside ACL must permit 443 to the chosen public address before translation is considered.
3. The guest VLAN cannot get DHCP from 10.10.0.5. Walk through the relay requirements and the likely gaps.
Read the worked answer
A router does not forward broadcasts by default, so the DHCP DISCOVER on 10.60.0.0/24 dies at the Layer 3 boundary unless a relay is configured on the guest SVI: ip helper-address 10.10.0.5. The helper rewrites the request into a unicast with giaddr set to the guest SVI address, which is how the server selects the right scope.
Likely gaps, in order of probability: the helper is missing on the guest SVI (or was placed on an interface in the wrong VRF); the DHCP server has no 10.60.0.0/24 scope, or the scope is exhausted; the server has no route back to 10.60.0.0/24, so its OFFER is dropped; an ACL is filtering UDP 67/68 between the VLAN and the server; or DHCP snooping is enabled on the guest VLAN without trusting the uplink toward the server, which drops the OFFER.
Verify with a capture at the SVI: you should see the DISCOVER relayed with giaddr 10.60.0.x, then an OFFER returning. Then check show ip dhcp snooping binding and the server's scope statistics. If the Layer 3 switch is also NATting, confirm the helper address is reachable in the correct VRF.