Home/Blog/CCNA & NAT
9 min readReviewed

NAT explained: address and port translation in IPv4 networks

How static NAT, dynamic NAT and PAT connect private and public IPv4 addressing, and where translation reaches its limits.

What you will take away

Knowledge you can put to work.

  • Distinguish static NAT, dynamic NAT and PAT
  • Read inside-local and inside-global addresses in a translation table
  • Separate NAT problems from routing, ACL and application problems

NAT translates addresses at a network boundary; PAT also translates ports so multiple clients can share public IPv4 addresses. Translation still needs correct routing and an explicit firewall policy.

Why address translation is used

IPv4 has approximately 4.3 billion addresses, fewer than the number of connected devices. Private addressing inside a network and public addressing at its edge allow many devices to share connectivity. For example, internal clients 192.168.1.10, 192.168.1.20 and 192.168.1.30 appear through public address 203.0.113.5. Private RFC 1918 addresses are not globally routed.

Static NAT is a permanent one-to-one mapping, for example for a server. Dynamic NAT chooses from a pool of public addresses. PAT, often called NAT overload, distinguishes many internal connections using one or a few public addresses and translated ports.

Read a PAT translation

Inside local usually means a host's address as seen inside its network; inside global means its externally visible address. NAT changes addresses and, with PAT, source ports while storing state in a table. It does not decide routing on its own: correct interfaces, routes and access lists remain prerequisites.

In this simplified example, 192.168.1.10:5001 becomes 203.0.113.5:10001, while 192.168.1.20:5001 becomes 203.0.113.5:10002. Both illustrative connections have destination 8.8.8.8:80. The translation state associates each returning connection with its internal client; identical internal source ports need not become identical external ports.

NAT is not a firewall

PAT means an arbitrary unsolicited incoming connection is not automatically associated with an internal host without a matching state. That is not a substitute for a defined security policy. Port forwarding, static mappings and protocol helpers can expose services. A firewall evaluates traffic according to rules, zones, identities or applications.

Changing headers complicates some protocols, troubleshooting and end-to-end connectivity. IPv6 provides a much larger address space; security there comes from filtering and segmentation rather than deliberately preserving address scarcity.

Troubleshooting starts before translation

First check that the internal host can reach its gateway and that a destination route exists. Then inspect NAT classification, ACL, translation table and return path. No table entry suggests traffic is not reaching the device or does not match the rule. An entry without a reply may indicate upstream routing, filtering or a destination service problem.

Capture traffic on both sides to confirm the expected address and port changes. Size logging for real PAT volume, especially if connections must later be attributed to internal clients, and monitor available port capacity.

Practical checklist

  1. 01

    Check inside/outside interfaces and routing.

  2. 02

    Compare the source network, destination and NAT ACL with the test traffic.

  3. 03

    Observe translation entries and counters during a targeted test.

  4. 04

    Check both directions for asymmetric routing or filtering.

  5. 05

    Monitor NAT logs and port capacity.

Frequently asked questions

Why does a service work internally but not via its public address?

Possible causes include missing port forwarding, firewall rules, the wrong return route or missing hairpin NAT for internal access to the public address.

Does NAT make a network secure?

Not by itself. Security depends on explicit filtering, segmentation, secure services, identity and monitoring. NAT primarily translates addresses and ports.

From reading to action

How Bissolux can help

Turn the checks in this guide into a practical plan. Tell us about your systems and requirements so we can agree the work, responsibilities and scope.

Infrastructure diagram connecting workstations, network, servers and separate backupAdvertisement · Bissolux
Illustrative service preview
Bissolux · our offerA system that fits

IT infrastructure

Plan network, server and cloud capacity, access and ongoing responsibilities around your actual workloads.

Illustrative server racks and network environmentAdvertisement · Bissolux
Illustrative working environment
Bissolux · our offerPlan your protection

Network and access segmentation

Separate network areas, devices and access with suitable rules and documented responsibilities.