LogoفارسیFA

Hands-On Lab: Configuring Dynamic NAT

This hands-on lab configures dynamic NAT using a pool of public addresses, verifying that internal hosts are assigned public addresses from the pool on a first-come, first-served basis and that translations expire once idle.

Dynamic NAT ConfigurationNAT PoolTranslation Timeout

~3 min read · Updated Sep 23, 2026

Lab Objective

Configure dynamic NAT on a router using a defined pool of public addresses, verify internal hosts are translated to addresses from that pool as they generate traffic, and observe a translation expire after its host goes idle.

Lab Purpose

Dynamic NAT, discussed earlier in this series, maps private addresses to public addresses drawn from a pool rather than a fixed one-to-one static mapping, assigned as traffic actually occurs — useful when a limited number of public addresses need to serve a larger set of occasionally active internal hosts.

Lab Topology

R1
  Gi0/0 (inside): 192.168.55.1/24
  Gi0/1 (outside): 203.0.113.30/30

Internal hosts: PC-A (192.168.55.10),
                PC-B (192.168.55.11)

Public address pool: 203.0.113.40 - 203.0.113.42

Task 1: Configure Basic Addressing and Interfaces

Configure both interfaces, marking Gi0/0 as inside and Gi0/1 as outside.

Task 2: Define the NAT Pool

Create a NAT pool named PUBLIC-POOL covering the three addresses shown.

Task 3: Define an ACL Identifying Eligible Internal Traffic

Create a standard ACL matching the internal subnet.

Task 4: Link the ACL to the Pool

Configure dynamic NAT, associating the ACL with the pool.

Task 5: Verify Dynamic Translation Occurs

Generate traffic from PC-A and PC-B and confirm each receives a distinct address from the pool.

Task 6: Observe Translation Expiration

Allow the translations to sit idle and confirm they eventually clear from the table.

Solution and Verification

R1(config)# interface gigabitethernet0/0
R1(config-if)# ip address 192.168.55.1 255.255.255.0
R1(config-if)# ip nat inside
R1(config-if)# no shutdown
R1(config-if)# exit
R1(config)# interface gigabitethernet0/1
R1(config-if)# ip address 203.0.113.30 255.255.255.252
R1(config-if)# ip nat outside
R1(config-if)# no shutdown

R1(config)# ip nat pool PUBLIC-POOL 203.0.113.40 203.0.113.42 netmask 255.255.255.252

R1(config)# access-list 1 permit 192.168.55.0 0.0.0.255

R1(config)# ip nat inside source list 1 pool PUBLIC-POOL

PC-A> ping 203.0.113.1
PC-B> ping 203.0.113.1

R1# show ip nat translations

Pro  Inside global     Inside local      Outside local  Outside global
icmp 203.0.113.40      192.168.55.10     203.0.113.1    203.0.113.1
icmp 203.0.113.41      192.168.55.11     203.0.113.1    203.0.113.1
-- Each host received a DIFFERENT address
-- from the pool, assigned on a first-come,
-- first-served basis as their traffic began

-- After leaving both hosts idle for several
-- minutes (default idle timeout is 24 hours
-- for TCP, shorter for other protocol types):

R1# show ip nat translations
-- (entries eventually clear once idle timeout
--  expires, freeing the pool addresses for
--  reuse by other hosts)

Key Takeaway

Dynamic NAT still requires one public address per simultaneously active internal host, since it remains fundamentally a one-to-one mapping at any given moment — with only 3 addresses in this pool, a fourth simultaneously active host would fail to get translated at all until one of the existing translations expires, which is exactly the scaling limitation that PAT, covered in the next lab, was designed to solve.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring OSPF Virtual Links

This hands-on lab connects a disconnected area to the backbone using an OSPF virtual link, addressing a design violation where an area does not have a direct physical connection to Area 0, and verifies routes flow correctly once the virtual link is established.

Continue

Hands-On Lab: Configuring an OSPF NSSA Area

This hands-on lab configures Area 1 as an NSSA, redistributing a local external route directly from within that area and verifying it propagates as a Type 7 LSA before being translated to Type 5 at the ABR, while inter-area routes from elsewhere remain blocked exactly as in a standard stub area.

Continue

Hands-On Lab: Configuring OSPF Stub and Totally Stubby Areas

This hands-on lab configures a leaf area as a standard stub area, then upgrades it to a totally stubby area, comparing the routing table size at each stage and verifying only a default route remains once fully configured.

Continue

Hands-On Lab: Configuring Multi-Area OSPF with Route Summarization

This hands-on lab configures multi-area OSPF across three routers, designating an ABR that summarizes several subnets from a leaf area into a single route advertised toward the backbone, tying together the area design and summarization concepts covered earlier in this series.

Continue

Hands-On Lab: Configuring EIGRP for IPv6

This hands-on lab configures EIGRP for IPv6 between two routers, activating the protocol directly on each interface similar to OSPFv3's approach, and highlights the mandatory router ID requirement unique to EIGRPv6.

Continue

Hands-On Lab: Configuring OSPFv3 for IPv6

This hands-on lab configures OSPFv3 between two routers to dynamically route IPv6 traffic, comparing its configuration syntax against the OSPFv2 labs covered earlier in this series while highlighting the interface-level activation approach OSPFv3 uses.

Continue
Previous ArticleNext Article