CCNA NAT and PAT on IOS XE: Static NAT, Port Forwarding, Pools, Overload and Troubleshooting

Cisco names every address in a NAT entry by two words: inside or outside says whose address it is (a host on your network or a host beyond it), and local or global says where it is seen from (your inside network or the outside world). Four combinations result, and every column of the translation table uses one of them.

The common rules (ip nat inside source …) translate only the inside host, so the inside local and inside global values differ while the outside local and outside global values are the same address: nobody rewrote the server. The outside pair differs only when you also translate outside hosts with ip nat outside source …, which rewrites the source of packets arriving from outside so they appear with a different address on the inside.

A quick way to label an address: ask "which host owns it?" (inside or outside), then "which side would see this exact value on the wire?" (local or global). The address an internet server logs for your user is always the inside global address, never the inside local one.

NAT acts only on packets that cross from an interface marked ip nat inside to one marked ip nat outside, or the reverse. Mark the interface facing the private network inside and the interface facing the ISP outside:

interface GigabitEthernet0/0/0
 description LAN
 ip nat inside
interface GigabitEthernet0/0/1
 description ISP
 ip nat outside

The roles are what the translation rules key on, so getting them wrong breaks translation silently: the router accepts the configuration and simply never matches the traffic.

• Roles swapped. LAN packets now enter an outside interface, so an ip nat inside source rule never sees them as inside-to-outside traffic. Nothing is translated and the table stays empty.
• Both interfaces the same role. Inside-to-inside or outside-to-outside traffic is never translated.
• A third interface (for example a DMZ). Give it the role its hosts play. A server published with ip nat inside source static must sit behind an inside interface; if its DMZ interface is marked outside, traffic from the ISP to it is outside-to-outside and the static entry is never applied. Removing the role is not enough either, because then the DMZ has no NAT role at all.

Check the roles with show ip nat statistics, which lists the inside and outside interfaces near the top, or with show running-config interface.

Static NAT permanently maps one inside local address to one inside global address, and it is the form to use when outside hosts must be able to start connections to an inside host at any time. The command lists the local address first, the global address second:

ip nat inside source static 192.168.50.12 192.0.2.12

What makes static NAT different from every dynamic form:

• It exists before any traffic. The entry is created by the configuration line, so a client on the internet can connect to 192.0.2.12 even if the server has been silent for days.
• It works in both directions. Inbound connections to 192.0.2.12 reach 192.168.50.12, and connections the server itself starts leave with source 192.0.2.12.
• Only the IP address changes. One-to-one NAT leaves the ports alone, so a session from source port 50733 still uses 50733, and every port of the global address leads to the server.
• It wins over dynamic rules. If the same host is also matched by the ACL of a dynamic or PAT rule, the static mapping is used for it: its outbound sessions use the static global address, not the PAT address. Other hosts are never handed a static global address by a PAT rule on the interface.
• Clearing the table does not remove it. clear ip nat translation * deletes dynamic entries only; the static entry stays because the configuration line still exists.

Reversing the two addresses (global first) maps the wrong way. ip nat outside source static is a different feature: it translates the addresses of outside hosts as their packets enter, so it cannot publish an inside server whichever order the addresses are written in.

Static PAT maps one inside address and port to one global address and port, so a single public address can publish several inside services. The syntax is:

ip nat inside source static {tcp | udp} LOCAL-IP LOCAL-PORT {GLOBAL-IP | interface IFNAME} GLOBAL-PORT

• The local port is the port the inside server actually listens on; the global port is the one outside clients connect to. Swapping them is the classic mistake: clients connect to the wrong port, or the router forwards to a port the server is not listening on.
• The protocol must match the service: a udp entry never matches TCP connections such as SSH or HTTPS.
• The interface keyword uses whatever address the outside interface currently has, so the forward keeps working when the address is learned by DHCP and the ISP changes it.

! Web server listening on 8080, published on the router's DHCP address, port 80
ip nat inside source static tcp 192.168.50.40 8080 interface GigabitEthernet0/0/1 80

! Two SSH servers that both listen on 22, sharing one public address
ip nat inside source static tcp 192.168.50.41 22 192.0.2.6 22
ip nat inside source static tcp 192.168.50.42 22 192.0.2.6 2222

Each global address-and-port pair can belong to only one inside server, which is why the second server above is published on a different global port. A full one-to-one static mapping would claim every port of the shared address, so it cannot coexist with other services or with PAT users on that address.

Static PAT and interface PAT combine well: a branch with a single public address can give all its users ip nat inside source list 20 interface Gi0/0/1 overload and still publish one server port with a static PAT entry on the same interface. The two are kept apart by port.

Only static NAT and static PAT let an outside host start a new connection to an inside host, because only they have a translation entry before the inside host sends anything. Dynamic NAT and PAT entries are created by traffic from the inside host and removed when they time out, so an unsolicited connection from the internet matches nothing and the router has nowhere to send it.

So an inside host that is reachable only through dynamic NAT or PAT cannot accept a session started from outside, however the dynamic rule is written. Making any inside host reachable from outside needs a static NAT or static PAT entry.

Dynamic NAT gives each inside host that an ACL selects its own global address from a pool, for as long as its translation entry lasts. It takes three pieces: a pool, an ACL and the rule that joins them.

ip nat pool BRANCH 198.51.100.97 198.51.100.102 netmask 255.255.255.248
access-list 30 permit 192.168.50.0 0.0.0.255
ip nat inside source list 30 pool BRANCH

• The pool takes a subnet mask or a prefix length (netmask 255.255.255.248 or prefix-length 29), never a wildcard mask; wildcards belong to ACLs.
• Use only usable host addresses. For 198.51.100.96/29, .96 is the network address and .103 the broadcast, so the pool runs .97 to .102.
• Leave out addresses that static mappings own. If a server is statically mapped to the last usable address of the block, the users' pool must stop one address short of it, or the pool could hand the server's address to another host.
• One host, one address. Without overload, a pool of four addresses serves at most four inside hosts at once. When every address is allocated, the next host's packets are dropped (not sent untranslated, and no existing entry is evicted) and the pool's misses counter in show ip nat statistics increases.

Dynamic NAT is the right choice when each inside host must appear with its own public address, and you do not want to maintain one static line per host: the ACL matches whole subnets, so hosts that join or change address are covered without any NAT edit, while the pool still bounds how many can be translated at once.

PAT, also called NAT overload, lets many inside hosts share one or a few global addresses by giving each session its own source port. Adding the keyword overload turns either dynamic rule into PAT:

! Share the outside interface's own address (works with a DHCP-learned address)
ip nat inside source list 20 interface GigabitEthernet0/0/1 overload

! Share the addresses of a pool
ip nat inside source list 30 pool ALLOWLISTED overload

How PAT keeps sessions apart. Each entry records protocol, inside local address and port, inside global address and port, and the remote address and port. The router tries to keep the original source port; when that global address-and-port is already taken (two hosts both using port 50112 toward the same server, say), it picks a different free port for one session. Replies arrive at the global address on that port and the entry tells the router which inside host and original port to restore.

Interface or pool?

• The interface form follows the address on the outside interface, so it suits a single DHCP-learned address that the ISP may change.
• The pool form keeps users on specific addresses, such as a block a partner has allowlisted. A PAT pool generally uses the first address until its ports run short before moving to the next.
• Without overload, the interface form lets only one inside host use the address at a time.

Fixing pool exhaustion. If show ip nat statistics shows a pool 100% allocated, a rising misses count and entries that are not "extended" (no port translation), the rule lacks overload. Adding overload to the same pool rule keeps users on the same addresses while sharing them by port; changing the pool mask or repeatedly clearing translations adds no capacity.

The ACL in ip nat inside source list decides which inside packets may be translated: a permit means "translate", a deny (or no match) means "do not translate with this rule". It is evaluated against inside-to-outside packets, top down, and the first matching entry decides.

• Standard ACLs match the source only, which is all most rules need. Get the wildcard right: it is the inverse of the subnet mask. A /20 (mask 255.255.240.0) needs wildcard 0.0.15.255; 0.0.7.255 would cover only the first half of it, and 0.0.31.255 (a /19) could also catch a neighbouring subnet that must stay untranslated. Putting a subnet mask where the wildcard belongs matches the wrong addresses.
• NAT exemption needs an extended ACL. To leave traffic to one destination untranslated (for example traffic to a partner network carried over a tunnel) while translating everything else, match source and destination and put the deny first:

access-list 120 deny   ip 192.168.50.0 0.0.0.255 172.20.0.0 0.0.255.255
access-list 120 permit ip 192.168.50.0 0.0.0.255 any
ip nat inside source list 120 interface GigabitEthernet0/0/1 overload

A deny placed below the broad permit is never reached. A deny written with the partner as source and the LAN as destination describes return traffic, not the packets being translated. A standard ACL cannot see the destination at all. ACL syntax itself is covered in the IPv4 access control lists lesson; here what matters is that the selecting ACL controls translation, not forwarding.

Inside to outside, IOS XE routes the packet before it translates it; outside to inside, it checks the inbound ACL before it translates. That fixed order decides which address routing and every interface ACL see.

Three practical results:

• Filtering by inside source address. A private source address exists only on the inside leg of the path, before translation, so an ACL that matches it as a source belongs inbound on the inside interface. Outbound on the outside interface the source is already the global address (shared by everyone under PAT). The other two positions, outbound on the inside interface and inbound on the outside interface, carry that host's traffic only as replies, where its address is the destination (the global address on the outside, the private one on the inside), so a source match there never sees the host at all.
• Publishing a server through an edge ACL. With ip nat inside source static 192.168.50.12 192.0.2.12, an inbound ACL on the outside interface must permit traffic to 192.0.2.12. An entry for 192.168.50.12 never matches because translation has not happened yet.
• An empty translation table can be a routing fault. If the NAT configuration is correct but the router has no route (often a missing default route toward the ISP next hop), inside packets are dropped at the routing step and never translated.

Return routing for global addresses

Translation solves only half the path: replies are addressed to the inside global address, so the upstream network must route that address back to the NAT router. When the global addresses are the router's own outside-interface address or sit inside the link subnet, the ISP already reaches them. When they come from a separate block the ISP assigned (a pool or static addresses outside the link subnet), the ISP router needs a route for that block pointing to the NAT router's link address.

! On the ISP router: pool block 198.51.100.160/27 lives behind R1 (192.0.2.2)
ip route 198.51.100.160 255.255.255.224 192.0.2.2

• The route must cover the whole pool. A route with a longer prefix than the block (a /28 for the /27 above, say) returns replies for only part of it, so users given the other addresses see no replies.
• The next hop must be the NAT router, not the ISP's own address.
• A route for the private LAN on the ISP does nothing: replies are addressed to global addresses, not private ones.
• Outbound packets still need the NAT router's own default route toward the ISP; a route on the NAT router pointing the pool at the ISP sends traffic the wrong way.

Two show commands verify NAT on IOS XE, and one clear command resets dynamic state.

Tracing a host. A remote server only ever sees translated values, so match its report (address and port) against the inside global column, then read the inside local column on the same row. Do not match the remote's port against inside local ports: an inside host's own port can coincide with another host's translated port.

Pro  Inside global      Inside local       Outside local       Outside global
udp  192.0.2.2:1031     192.168.50.31:50112 198.51.100.140:53  198.51.100.140:53

Reading this DNS query row from right to left: the remote server's address is the same in both outside columns (only the inside host was translated), the server sees the inside global address and port, and the inside local column on that row names the real host and its original port.

Entries outlive configuration changes. A dynamic entry lasts until it times out or is cleared, and a host that already has an entry keeps using it. After you point a rule at a new pool, or after inside hosts are re-addressed, old entries keep their old global addresses until they expire. Run clear ip nat translation * to make the next packets build entries from the current rule. Saving the configuration or clearing statistics or ACL counters does not touch the table.