How to configure NAT static port forwarding extendable on Catalyst 9300

By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30

Static NAT with port forwarding is bread and butter. The extendable keyword is what most engineers forget. Without it, you cannot map the same inside-local IP and port to two different outside-global IPs: useful when the box hosts an HTTPS reverse proxy that needs to answer on two public IPs. I hit this at a Comsys Mumbai GeM-tender deployment for a state PSU where the published RFP required dual-ISP HA on the same internal Nginx VM. On Catalyst 9300, the command sequence below is what cleared the %IPNAT-6-CREATED log entries cleanly.

Pre-requisites

• Catalyst 9300 on IOS XE 17.x or later. The extendable keyword has been around since classic IOS but the syntax tightened around 17.6.
• Two outside public IPs reachable on the same outside interface, or on two outside interfaces if you are doing dual-ISP HA.
• The internal server. Confirm its inside-local IP responds on the target port before you ever touch NAT. A Wireshark 4.2 capture inside the LAN saves a lot of guesswork.
• NAT64 disabled. If NAT64 is on, the extendable map gets ignored on certain code trains. I learned this one the hard way at a Comsys Mumbai POC.
• SmartNet and a backup of show running-config | section ip nat taken before any change. Restoring NAT mistakes without a backup is painful.

Step-by-step on Catalyst 9300

1. Test the inside server first. From a host on the same VLAN: curl -v http://192.168.20.10:443. If this fails, fix the server, not the NAT box.
2. Write the first static NAT. ip nat inside source static tcp 192.168.20.10 443 203.0.113.10 443 extendable. This forwards public IP 203.0.113.10 port 443 to the internal server.
3. Add the second mapping using the same internal target. ip nat inside source static tcp 192.168.20.10 443 198.51.100.10 443 extendable. Without the extendable keyword on both lines, IOS refuses the second entry with %NAT: duplicate mapping.
4. Mark inside / outside interfaces. Same as PAT: ip nat inside on the LAN interface, ip nat outside on each ISP-facing interface.
5. Confirm both mappings are live. show ip nat translations static. Both rows should appear with the same inside-local. If only one appears, the extendable keyword didn't take, check IOS version.
6. Reach the server from both public IPs. From an external host: curl -v https://203.0.113.10 and curl -v https://198.51.100.10. Both must return the same content.
7. Save and document. write memory, then record both public IPs in the runbook so the next on-call engineer doesn't decommission one by accident.

A deployment I shipped

The Comsys Mumbai POC I keep referring to ran an Nginx reverse proxy on a single VM behind a Catalyst 9300. The state PSU's RFP required two public IPs for DR. one MTNL, one Tata, with HTTPS reaching the same backend on port 443. First attempt without extendable failed: IOS rejected the second ip nat inside source static line. After we added extendable to both lines, show ip nat translations static listed both entries and external curl tests from both public IPs returned the same Nginx welcome page. Tata's ISP charged ₹14,500 per month for the second /29; MTNL was bundled into the GeM tender. The PSU's CISO signed off the DR design in one review.

How I verify the change actually works

1. show ip nat translations static: both static entries present.
2. show ip nat translations | inc 192.168.20.10, active flows split correctly.
3. External curl -v https://203.0.113.10 + curl -v https://198.51.100.10. both return the same backend.
4. show running-config | section ip nat, both lines have the extendable keyword.

Gotchas I've eaten in production

• %NAT: duplicate mapping. You forgot the extendable keyword on the second static entry. Add it. Re-enter both lines if needed.
• Only one public IP works. The other ISP interface lacks ip nat outside. Fix that, NAT will populate.
• Port number mismatch. A common typo: forwarding 443 outside to 80 inside silently. Always confirm both ends of the mapping in show running-config | section ip nat.
• Cisco IOS XE Stack-Wise V1/V2 mismatch on stacked Catalysts. When two stack members disagree on NAT pool ownership, ARP for the public IP flips between them and translation gets dropped. Reseat the stack cables and reload the secondary.

Cost impact

Numbers are 2026 indicative ranges and depend on the SKU plus your reseller. Redington and Ingram Micro typically beat list by 8-14% for partner-managed renewals. GeM-tender pricing varies again: most government rate contracts include first-year SmartNet bundled into the hardware price.

Tooling I keep on the bench

• Putty 0.78 for the console session. Logging is on by default for every box I touch.
• SecureCRT 9.4 when the customer has tab-heavy sessions or needs tabbed scripting against a fleet.
• Wireshark 4.2 for any time the platform behaviour does not match the documentation. A 10-second capture answers what 30 minutes of show commands cannot.
• Cisco DNA Center / Catalyst Center for fleets above 30 devices. The compliance dashboard catches drift that an engineer never sees.
• Cisco Modeling Labs (CML 2.7) for pre-prod testing. ₹0 for personal use up to 20 nodes; commercial licence runs about ₹1.2 lakh annually.
• Ansible 2.16 for templated rollouts. The cisco.ios and cisco.nxos collections both handle the platforms in this guide.

How this interacts with other Cisco surfaces

Hardly any change on Catalyst 9300 lives alone. The features in this guide ripple into adjacent boxes, sometimes within seconds, sometimes the next morning. Here is what I trace before I close a ticket.

Catalyst Center (DNAC) compliance

If the customer runs Catalyst Center, any out-of-band CLI edit will show as compliance drift inside 15 minutes. I either pre-stage the change as a template in the Network Design workflow, or I accept the drift flag and immediately re-sync the device state. Leaving the drift unresolved means the next compliance scan re-applies the previous template and silently wipes your change.

SD-WAN policy fabric

On a fabric router under vManage / Cisco SD-WAN control, CLI edits to features the controller manages get reverted on the next template push. The right move is to apply the change via a feature template, attach a CLI add-on for what the GUI does not cover, and push from vManage. If you are testing in isolation, detach the device from vManage first.

Identity Services Engine (ISE) RADIUS sessions

When the platform you are touching also acts as a NAS for 802.1X, every config save reloads the RADIUS subsystem briefly. Active wired sessions held by ISE can reauthenticate. Schedule the change outside the 9 a.m. login spike or use aaa accounting update periodic 5 to keep stale sessions visible to ISE while the box settles.

Firepower / FTD inspection

If a Firepower NGIPS or FTD sits between the inside and outside zones, any new NAT flow needs an access-control rule allowing it. The control-plane change on the router does not automatically open the firewall. I keep a paired change request open on FMC so the rule lands in the same window.

Duo MFA for admin login

If admin logins are protected by Cisco Duo, plan for the push prompt during your change window. A Duo push that times out at the wrong moment can leave you locked out of the second box mid-change. I keep a parallel console session open before I touch any auth-related config.

Long-term monitoring I leave running

A clean change is one that still looks clean a month later. On Catalyst 9300, I leave the following hooks in place after every deployment touched by this guide.

• SNMPv3 polling on the interfaces involved. CPU, memory, input / output bps, errors. PRTG or LibreNMS both work; the customer's existing NMS is usually fine.
• Syslog forwarding to a central collector. I prefer Graylog 5.2 with a dashboard that filters on %LINEPROTO-5-UPDOWN, %SYS-5-CONFIG_I, %SPANTREE-2-RECV_PVID_ERR, %OSPF-4-ERRRCV, and any platform-specific NAT / MPLS facility codes.
• NetFlow / IPFIX at low sample rate (1 in 1,000) to the customer's flow collector. Useful for proving that the NAT pool is being used the way the design intended.
• Monthly compliance scan via Catalyst Center or a manual show running-config diff against the change baseline. Drift catches silent edits.
• Quarterly review of SmartNet entitlement. If the SmartNet contract is about to expire (₹85,000 - 2 lakh annual, set a calendar 60 days out), renewal lead time on a GeM-tender customer can be 90 days.

None of these are heavy lifts. Combined, they catch the regressions that an ad-hoc show command will not. Customers who run them rarely call us about repeat incidents on the same change.

More frequently asked questions

Can I roll back without a reload?

Yes for every topic in this guide. The no-form of each command unwinds the change in real time. Run show running-config before and after so you can diff with VSCode or notepad++ if anything looks off.

Does this break IPv6?

No. None of these features touch the IPv6 forwarding path. If you run dual-stack on Catalyst 9300, IPv6 keeps its own LSDB, its own NAT (or NPTv6) state, and its own LDP context, they share nothing with IPv4 here.

What about IOS XE Stack-Wise V1/V2 mismatch?

Mixing Stack-Wise V1 and V2 members in the same stack is unsupported and reliably breaks NAT pool ownership. Replace the older member before configuring any of these features on a stacked Catalyst.

Is this safe to run during business hours?

Read-only verification is always safe. Config changes: even the no-op-looking ones, can disturb production. I schedule a 30-minute window with the customer, capture pre-change state, run the change, verify, and stop. A Comsys Mumbai-style runbook keeps this consistent across teams.

Will SmartNet TAC help if I get stuck?

Yes. With an active SmartNet (₹85,000 - 2 lakh annually depending on SKU and tier) TAC will accept a P3 ticket and review the running-config plus the relevant show outputs. Without SmartNet you can still post on the Cisco Community forum but expect community response speed, not SLA speed.

How do I avoid this becoming legacy debt?

Document the change in CMDB. Tag it with the project name. Add the verification commands to the runbook. Add a Catalyst Center compliance policy if you run one. The engineer who picks this up in 2028 will thank you.

What I do after the change is in

Three habits keep me sane after any production config change. First, I leave the console session logged in for 15 minutes and watch the syslog buffer. Second, I run show logging | last 100 from a fresh session 24 hours later. Third, I ask the customer's NOC to confirm zero alerts during the window. The combination catches almost every regression before it becomes a Monday morning ticket.

On a Catalyst 9300-class platform, the syslog patterns that I watch for are %LINEPROTO-5-UPDOWN on the affected interfaces, %SYS-5-CONFIG_I for unexpected re-edits, and %SPANTREE-2-RECV_PVID_ERR on the L2 underlay. If none of those show up in the next 48 hours, the change has settled.

If you came here because of a live outage, the fastest rollback is almost always the no-form of the commands above. Restore. Stabilise. Then reschedule the change for a quiet window. Production is not the time to be brave.

Related fixes

Related guides worth a look while you sort this one out:

• How to configure NAT static port forwarding extendable on Catalyst 8300/8500
• How to configure NAT static port forwarding extendable on Catalyst 9200
• How to configure NAT static port forwarding extendable on Catalyst 9400
• How to configure NAT static port forwarding extendable on Catalyst 9500
• How to configure NAT static port forwarding extendable on Catalyst 9800 WLC
• How to configure NAT static port forwarding extendable on Catalyst Center / DNAC