Hands-On Lab: Configuring PAT (NAT Overload)

This hands-on lab configures Port Address Translation using the overload keyword, allowing many internal hosts to share a single public IP address simultaneously, and verifies each host is distinguished by a unique translated port number.

PAT ConfigurationNAT OverloadPort-Based Translation

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۱ مهر ۱۴۰۵

Lab Objective

Configure PAT on a router so multiple internal hosts share the single public IP address assigned to the outside interface, and verify simultaneous sessions from different hosts are correctly distinguished by port number.

Lab Purpose

Dynamic NAT, covered in the previous lab, still requires one public address per simultaneously active host. PAT removes this limitation entirely by allowing many internal hosts to share a single public address at once, distinguishing between them using different source port numbers — by far the most common NAT configuration in real-world networks, including nearly every home router.

Lab Topology

R1
  Gi0/0 (inside): 192.168.65.1/24
  Gi0/1 (outside): 203.0.113.50/30

Internal hosts: PC-A (192.168.65.10),
                PC-B (192.168.65.11),
                PC-C (192.168.65.12)

No pool needed -- all hosts will share
R1's own outside interface address

Task 1: Configure Basic Addressing and Interfaces

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

Task 2: Define an ACL Identifying Eligible Internal Traffic

Create a standard ACL matching the internal subnet.

Task 3: Configure PAT Using the Overload Keyword

Configure NAT to translate matched traffic using the outside interface's own address, with the overload keyword enabling port-based translation.

Task 4: Generate Simultaneous Traffic from Multiple Hosts

Generate traffic from all three internal hosts at once.

Task 5: Verify All Hosts Share One Public Address

Confirm the translation table shows all three hosts mapped to the same public address, distinguished only by port number.

Solution and Verification

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

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

R1(config)# ip nat inside source list 1 interface gigabitethernet0/1 overload

-- Unlike dynamic NAT's pool-based approach,
-- "overload" reuses the outside interface's
-- single address for every translated host,
-- adding a unique port number to distinguish
-- between them

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

R1# show ip nat translations

Pro  Inside global            Inside local          Outside local  Outside global
icmp 203.0.113.50:1           192.168.65.10:1       203.0.113.1    203.0.113.1
icmp 203.0.113.50:2           192.168.65.11:2       203.0.113.1    203.0.113.1
icmp 203.0.113.50:3           192.168.65.12:3       203.0.113.1    203.0.113.1

-- All three hosts share the EXACT SAME
-- outside global address (203.0.113.50),
-- distinguished only by the port number
-- appended after the colon -- this is what
-- allows an unlimited number of internal
-- hosts to share one single public address,
-- unlike the pool exhaustion limit seen with
-- dynamic NAT in the previous lab

Key Takeaway

PAT's "overload" keyword is the single word that transforms NAT from a one-to-one mapping into a true many-to-one mapping, entirely by tracking port numbers alongside the shared IP address — this is precisely why an entire home network of a dozen or more devices can share the single public IP address typically assigned by an internet service provider.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه