LogoفارسیFA

Hands-On Lab: Configuring Static NAT

This hands-on lab configures static NAT to provide a consistent, permanent public IP address for an internal server, verifying inbound connections from the internet reach the server correctly through the translated address.

Static NAT ConfigurationInside Local and GlobalOne-to-One Translation

~3 min read · Updated Sep 23, 2026

Lab Objective

Configure static NAT on a router to map a single internal server's private address to a dedicated public address, designate the inside and outside interfaces, and verify inbound traffic from an external host reaches the internal server correctly.

Lab Purpose

Static NAT, discussed earlier in this series, creates a permanent one-to-one mapping ideal for servers that need to be consistently reachable from the internet, such as a web server — unlike dynamic NAT or PAT, the same public address always maps to the same specific internal host.

Lab Topology

R1
  Gi0/0 (inside): 192.168.45.1/24
  Gi0/1 (outside): 203.0.113.10/30

Internal server: 192.168.45.100/24
Public address to map: 203.0.113.20

Task 1: Configure Basic Addressing

Configure both interfaces as shown.

Task 2: Designate Inside and Outside Interfaces

Mark Gi0/0 as the NAT inside interface and Gi0/1 as the NAT outside interface.

Task 3: Configure the Static NAT Mapping

Create a static NAT entry mapping the internal server's private address to the designated public address.

Task 4: Verify the Translation Table

Confirm the static mapping appears in the NAT translation table.

Task 5: Verify Inbound Connectivity

From an external host, connect to the public address and confirm it reaches the internal server.

Solution and Verification

R1(config)# interface gigabitethernet0/0
R1(config-if)# ip address 192.168.45.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.10 255.255.255.252
R1(config-if)# ip nat outside
R1(config-if)# no shutdown

R1(config)# ip nat inside source static 192.168.45.100 203.0.113.20

R1# show ip nat translations

Pro  Inside global      Inside local        Outside local  Outside global
---  203.0.113.20       192.168.45.100      ---            ---
-- The static entry appears immediately and
-- permanently, unlike dynamic entries which
-- only appear once traffic actually flows

ExternalHost> curl http://203.0.113.20

-- Successfully reaches the internal server

R1# show ip nat translations

Pro  Inside global       Inside local         Outside local     Outside global
tcp  203.0.113.20:80     192.168.45.100:80    198.51.100.5:52341  198.51.100.5:52341
-- Once traffic actually flows, a more detailed
-- per-connection entry appears alongside the
-- permanent static mapping

Key Takeaway

A static NAT entry appears in the translation table immediately upon configuration and remains permanently, unlike dynamic NAT or PAT entries which only exist while active traffic uses them — this permanence is precisely what makes static NAT the correct choice for a server that must always be reachable at the same public address, regardless of whether traffic happens to be flowing at any given moment.

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