NAT and PAT Configuration Scenarios

The access list 'NAT' is incorrect; it should permit only specific hosts, not the entire subnet.

Why wrong: The access list 'NAT' is not the problem. In dynamic NAT, the ACL is used solely to identify which inside addresses are eligible for translation, and permitting the entire internal subnet is standard and correct when all internal hosts should have Internet access. Even if the ACL were narrowed to specific hosts, the router would still fail to translate return packets because the outside interface has not been designated with 'ip nat outside'. The ACL only controls which source addresses are translated, not whether NAT is applied on an interface.

The NAT configuration lacks the 'overload' keyword, so the pool is exhausted quickly.

Why wrong: The lack of the 'overload' keyword is a red herring here. Without overload, the router performs standard dynamic NAT, which still works correctly as long as the number of active inside addresses does not exceed the number of addresses in the pool. In the scenario, there are only 2 active translations and 11 addresses in the pool, so the pool is not exhausted and overload would not change the immediate outcome. The real issue is that the outside interface is not configured for NAT, and adding overload cannot compensate for that missing interface-level command.

The NAT pool 'POOL' has too few addresses; it should be expanded to a /24 subnet.

Why wrong: The NAT pool 'POOL' has 11 addresses, which is more than enough for the two active translations, so pool size is not causing the problem. Expanding the pool to a /24 subnet would only increase the maximum number of concurrent translations; it would not make the router process return traffic on the outside interface. Even with 254 public addresses available, the router would still not translate reply packets because the outside interface is not marked with 'ip nat outside'. The symptom of no replies is a direct result of missing interface NAT designation, not address exhaustion.

Convert all inside hosts to the same private IP address.

Why wrong: Assigning every inside host the same private IP address would create Layer 3 addressing conflicts, breaking ARP and preventing any host from communicating on the LAN. PAT assumes each inside host retains its own unique private IPv4 address so the router can track individual sessions; the translation process then maps those unique local addresses to a shared public address with different port numbers. Thus, a common private IP is neither required nor usable.

Increase the size of the NAT pool to include multiple public addresses.

Why wrong: Expanding the NAT pool to include more public addresses is characteristic of dynamic NAT or many-to-many translation, not of PAT. In PAT, even with a pool of addresses, the distinguishing mechanism is still the transport-layer port number, and the router will overload the available addresses by reusing them with different source ports. Simply adding more public IPs does not enable port-based session multiplexing, which is the core feature that PAT uses to handle many inside sessions.

Configure static NAT mappings for each inside host.

Why wrong: Configuring static NAT for each host requires a one-to-one mapping between an inside local address and an inside global address, meaning you need one public IPv4 address per host. That defeats the purpose of PAT, which is designed to conserve public address space by allowing many hosts to share a single outside address through port multiplexing. Static NAT also does not scale for even a small office and fails to provide the transport-layer port translation that PAT implements.

Replace PAT with DHCP relay.

Why wrong: DHCP relay is an IP helper mechanism that forwards DHCPDISCOVER broadcasts between subnets so clients in one VLAN can obtain leases from a DHCP server in another subnet. It performs no address translation and creates no public-to-private mapping, so it cannot provide Internet reachability for the server. Replacing PAT with DHCP relay would eliminate the only translation mechanism in use, making the server even less reachable from the Internet.

Disable NAT entirely because PAT is preventing inbound routing.

Why wrong: Disabling NAT entirely would remove the translation that maps the branch's private RFC1918 addresses to routable public addresses, causing user packets to be dropped by the ISP because private addresses are not routable on the Internet. PAT itself does not prevent inbound routing; it simply lacks a translation entry for unsolicited packets destined to the server, which is why an inbound connection fails. The correct remedy is to add a static NAT mapping, not to turn off NAT altogether.

Put the server in the native VLAN.

Why wrong: Placing the server in the native VLAN changes only the Layer 2 domain for untagged frames on a trunk, typically used for management or specific legacy traffic. This action has no effect on Layer 3 address translation and does not create any public mapping, so Internet clients still cannot reach the server. The native VLAN is unrelated to NAT/PAT and cannot publish a server to the public Internet.

PAT overload only

Why wrong: PAT overload, also known as NAT overload, maps many inside hosts to a single public IPv4 address by tracking unique source port numbers. This dynamic translation is created only when an inside device initiates an outgoing session, so unsolicited inbound connection attempts directed at that public address have no preexisting binding. Without a static forward rule, an outside host cannot initiate a connection to an internal server through PAT, making it unsuitable for the stated requirement.

No NAT at all, because private IPv4 addresses are Internet-routable

Why wrong: The premise that private IPv4 addresses are Internet-routable is false: RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) are explicitly non-routable across the public Internet, and service providers drop packets using them. Consequently, a server holding only a private address would never receive direct inbound traffic from the outside world. This makes the 'no NAT' option incorrect because the design goal of reachability cannot be achieved without some form of address translation.

DHCP relay

Why wrong: DHCP relay is a Layer 3 feature that forwards DHCP client broadcast messages to a DHCP server on a different subnet or VLAN, helping clients obtain IP configuration such as addresses and lease times. It performs no address translation and creates no mapping for inbound public traffic; it operates at the application layer of the DHCP protocol and does not affect IP routing reachability. Therefore, configuring DHCP relay would have zero impact on making an internal server reachable from the Internet, making it irrelevant to the requirement.

PAT requires OSPF to be enabled on the WAN link.

Why wrong: PAT operates at Layer 3/4 and only needs the inside and outside interfaces to be correctly identified and the ACL to match traffic. Routing protocols like OSPF are used to exchange routes, not to enable NAT. As long as the router has a route to the destination (e.g., a default static route), PAT will work independently of whether OSPF is running.

The ACL must be numbered 100 instead of 1.

Why wrong: Standard ACLs (1-99) and extended ACLs (100-199) are both valid for NAT. The `access-list 1 permit` command simply defines which source addresses are eligible for translation; it does not require a specific number range. In fact, many PAT configurations use a standard ACL numbered 1, so changing to 100 would have no effect on whether PAT is working.

The router must use GRE before PAT can overload.

Why wrong: PAT is a form of NAT that multiplexes many private addresses to one public IP using unique port numbers. GRE is a tunneling protocol used to encapsulate packets (e.g., for VPNs) and is not a prerequisite for NAT/PAT. The router can perform PAT directly on the physical WAN interface without any tunnel.

Configure 'ip nat outside' on GigabitEthernet0/0, 'ip nat inside' on GigabitEthernet0/1, keep ACL 10 as is, and add 'overload' to the PAT command.

Why wrong: This configuration marks the WAN side as inside and the LAN side as outside, so packets from the LAN are received on the 'outside' interface and are not matched by the 'ip nat inside source list' rule. Additionally, ACL 10 still permits the wrong subnet, so even if the interface roles were fixed, the NAT process would not select the intended internal addresses for translation. Adding 'overload' cannot compensate for the reversed inside/outside design and the faulty ACL.

Configure 'ip nat inside' on GigabitEthernet0/1, 'ip nat outside' on GigabitEthernet0/0, correct ACL 10 to permit 192.168.1.0 0.0.0.255, and add 'overload' to the PAT command.

Why wrong: With 'ip nat inside' assigned to GigabitEthernet0/1 (the WAN link) and 'ip nat outside' on the LAN interface, the router treats the public-facing connection as the internal side. Because the LAN is thus marked 'outside', traffic from 192.168.1.0/24 is never evaluated against the NAT ACL, even though ACL 10 now lists the correct subnet; the 'overload' keyword only enables port multiplexing on a correctly directed NAT rule. Consequently, internal hosts are not translated and the design fails.

Configure 'ip nat inside' on GigabitEthernet0/0, 'ip nat outside' on GigabitEthernet0/1, correct ACL 10 to permit 192.168.1.0 0.0.0.255, but do not add 'overload' to the PAT command.

Why wrong: Although the inside/outside markings and ACL 10 are correct, omitting 'overload' disables Port Address Translation. Without 'overload', the command attempts to translate inside local addresses to addresses from a configured global pool on a one-to-one basis; if the pool has only the single public IP on GigabitEthernet0/1, only one internal host can be translated at a time and the rest will fail. Adding 'overload' is mandatory for PAT-style many-to-one sharing of a single WAN address.

The access list should deny the inside subnet

Why wrong: The access list in the NAT statement defines which inside source addresses are eligible for translation; denying the inside subnet would exclude all internal hosts from translation entirely. That would stop NAT for every host, so neither one nor multiple hosts could reach the internet. The observed problem is not a total block but a limitation in concurrent translations, so modifying the ACL to deny the inside subnet would eliminate connectivity rather than resolve the one-at-a-time issue.

The inside and outside interface roles are reversed in the exhibit

Why wrong: If the inside and outside interface roles were reversed, NAT would examine traffic in the wrong direction and would not translate source addresses for outbound connections. This would typically prevent any inside host from reaching the internet, or cause translations to be applied to inbound traffic, not an intermittent one-at-a-time pattern. The symptom of hosts reaching the internet sequentially indicates that translation is occurring for individual flows, pointing to a lack of overload rather than a complete interface misconfiguration.

NAT cannot be used with RFC1918 addresses

Why wrong: NAT is specifically designed to translate RFC1918 private addresses (such as 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) to public, routable addresses, making this a standard and common use case. The exhibit clearly shows private addressing on the inside, which is exactly the scenario that NAT and PAT are intended to support. The issue is not the NAT mechanism itself but the missing overload keyword, which prevents multiple private hosts from sharing a single public IP simultaneously.

R1(config)# access-list 1 permit 192.168.1.0 0.0.0.255 R1(config)# ip nat inside source list 1 interface GigabitEthernet0/1 overload R1(config)# interface GigabitEthernet0/0 R1(config-if)# ip nat outside R1(config-if)# interface GigabitEthernet0/1 R1(config-if)# ip nat inside

Why wrong: This is incorrect because the NAT source interface is GigabitEthernet0/1, which is the inside interface. The translation should use the outside interface (GigabitEthernet0/0) IP address.

R1(config)# access-list 1 permit 192.168.1.0 0.0.0.255 R1(config)# ip nat inside source list 1 interface GigabitEthernet0/0 R1(config)# interface GigabitEthernet0/0 R1(config-if)# ip nat outside R1(config-if)# interface GigabitEthernet0/1 R1(config-if)# ip nat inside

Why wrong: This is incorrect because the 'overload' keyword is missing from the NAT configuration. Without 'overload', only one internal host can be translated at a time (dynamic NAT), which would not allow multiple hosts to access the internet simultaneously.

R1(config)# access-list 1 permit any R1(config)# ip nat inside source list 1 interface GigabitEthernet0/0 overload R1(config)# interface GigabitEthernet0/0 R1(config-if)# ip nat outside R1(config-if)# interface GigabitEthernet0/1 R1(config-if)# ip nat inside

Why wrong: This is incorrect because the ACL permits any source IP, including traffic from the ISP side or other networks, which could cause security issues and unintended translations. The ACL should be restricted to the internal LAN (192.168.1.0/24).

The NAT pool is exhausted because it contains only 21 addresses, and more than 21 internal hosts are trying to access the Internet simultaneously.

Why wrong: While pool exhaustion is possible, the output shows many translations already, and the symptom is that external hosts cannot initiate connections—a problem that would persist even with a larger pool if overload is not used.

The inside local addresses are not in the same subnet as the inside interface, causing asymmetric routing.

Why wrong: The inside local addresses 192.168.1.x are normal RFC 1918 addresses, and the NAT table shows them being translated to public addresses, which implies the router is successfully receiving and forwarding their outbound traffic. If these addresses were not in the same subnet as the inside interface, the router would not have a directly connected route to them and no translations would appear in the first place. Moreover, asymmetric routing—where outbound and return traffic take different paths—would be a routing topology issue, not a NAT configuration issue, and the shortage of inbound connectivity is explained by the lack of overload or static mappings.

The outside global addresses are not routable on the Internet, so external hosts cannot send return traffic.

Why wrong: The public IPs shown (203.0.113.x) are from the TEST-NET-3 range, which is not globally routable. However, this is a common documentation range used in examples; in a real network, these would be replaced with routable IPs. The question assumes they are routable for the scenario.

The ACL must deny RFC1918 traffic before NAT can work.

Why wrong: The access-list used with ip nat inside source is not a traffic filter; it defines which inside local addresses are eligible for translation. RFC1918 private addresses are precisely the addresses that must be matched and translated, so denying them would stop outbound NAT from ever occurring. The enterprise's real fault is labeling the LAN interface as ip nat outside and the WAN interface as ip nat inside, which prevents any translation regardless of ACL content.

PAT cannot use an interface address for overload.

Why wrong: Cisco IOS explicitly supports PAT with the overload keyword using the outside interface's own IP address as the translated source address. For example, ip nat inside source list 1 interface Serial0/0/0 overload is a standard configuration for sharing one public IP among many internal clients. Therefore, the inability to reach the internet is not caused by using an interface address for PAT; it is caused by incorrectly assigning ip nat inside and ip nat outside to the WAN and LAN interfaces, respectively.

The inside subnet must be configured as /24 on both interfaces.

Why wrong: Cisco NAT does not require the inside and outside interfaces to share a subnet mask or even belong to the same IP network. The LAN-facing interface normally uses a private /24 subnet, while the WAN-facing interface uses a public address from the ISP's different subnet; a /24 mask on the WAN link is not a design requirement. The actual problem here is that the NAT interface roles are reversed, not that the subnet masks are misconfigured.

PAT requires a 1:1 mapping of internal to external IP addresses.

Why wrong: PAT is the opposite of a 1:1 mapping: it is a many-to-one overload technique that allows every internal host to be represented by the same public IP address. A 1:1 relationship between internal and external addresses describes static NAT or dynamic NAT without overload, where each private address consumes a separate public address. PAT instead differentiates concurrent sessions through unique source port numbers, and it can work with just a single interface IP address, so no pool or 1:1 binding is required.

PAT can only be configured with a pool of public IP addresses.

Why wrong: PAT can be configured with either a single public IP address (using the interface address) or a pool of public IP addresses. It does not require a pool; a single address is sufficient for PAT overload.

PAT translations are always static and never time out.

Why wrong: PAT translations are dynamic by nature: they are created on demand when an internal host starts an outbound session and are removed after the session ends or after an inactivity timeout expires. For example, a TCP entry on Cisco IOS typically times out after 24 hours by default, while UDP entries time out after just a few minutes, and administrators can tune these timers with 'ip nat translation' commands. Static NAT entries persist indefinitely, but PAT entries are intended to be temporary so that ports can be recycled and the limited public address is shared efficiently.

Static NAT only

Why wrong: Static NAT only is wrong because it creates a fixed one-to-one mapping between a single private IPv4 address and a single public IPv4 address. With static NAT, each internal host requires its own dedicated public address, so there is no sharing of one public IP among multiple users. This approach does not fulfill the requirement of allowing many internal users to share a single public IPv4 address.

No NAT, because private IPv4 addresses are Internet-routable

Why wrong: No NAT is wrong because private IPv4 addresses defined in RFC 1918 (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) are explicitly non-routable on the public Internet. Internet routers drop packets that use these source or destination addresses, so internal users cannot directly communicate with external servers without translation. Therefore, NAT is essential to convert private source addresses to a routable public IPv4 address for Internet access.

DHCP relay

Why wrong: DHCP relay is unrelated to address sharing because it simply forwards DHCP broadcast messages from clients on one LAN segment to a DHCP server located on another segment. DHCP relay does not perform any address translation and does not affect how private or public IPv4 addresses are used for Internet connectivity. It is a protocol helper service, not a mechanism for multiplexing many internal users onto one public IPv4 address.

It enables PAT overload for all internal users

Why wrong: PAT overload requires the 'overload' keyword along with a dynamic NAT pool or interface, enabling many internal addresses to share one public IP using unique source port numbers. The given command uses 'static' and therefore references only one inside host, not the entire internal network. It cannot provide Internet access for multiple users concurrently.

It blocks inbound access to the inside host permanently

Why wrong: Static NAT does not apply any security filtering; it merely advertises a public IP that maps to an inside host, and inbound packets are forwarded to that host. Restricting inbound access would require an access control list or firewall rule applied to the interface. Therefore, this statement confuses NAT behavior with packet filtering.

It changes the host subnet mask to a public prefix

Why wrong: NAT translation operates on IP packet headers as they traverse the router, altering the source or destination IP address. It does not modify the host's locally configured subnet mask, which remains part of the host's IP stack and is used for direct or gateway-based delivery. Subnet mask changes would require reconfiguration on the host itself.

ip access-list standard PERMIT_INTERNAL permit 192.168.1.0 0.0.0.255 interface GigabitEthernet0/1 ip nat outside interface GigabitEthernet0/0 ip nat inside ip nat inside source list PERMIT_INTERNAL interface GigabitEthernet0/0 overload ip nat inside source static tcp 192.168.1.10 80 203.0.113.10 80 ip nat inside source static tcp 192.168.1.20 25 203.0.113.11 25

Why wrong: This configuration incorrectly assigns the NAT interface directions: the inside interface (Gig0/1) is marked as 'outside' and the outside interface (Gig0/0) as 'inside'. This would cause NAT to fail because traffic from internal hosts would not be translated correctly.

ip access-list standard PERMIT_INTERNAL permit 192.168.1.0 0.0.0.255 interface GigabitEthernet0/1 ip nat inside interface GigabitEthernet0/0 ip nat outside ip nat inside source list PERMIT_INTERNAL interface GigabitEthernet0/0 overload ip nat inside source static 192.168.1.10 203.0.113.10 ip nat inside source static 192.168.1.20 203.0.113.11

Why wrong: This configuration omits the protocol and port in the static NAT entries. Without specifying TCP and port numbers, the static NAT would apply to all traffic (including non-HTTP/SMTP) and could conflict with PAT. Also, the 'extendable' keyword is missing, which is recommended when using PAT alongside static NAT.

ip access-list standard PERMIT_INTERNAL permit 192.168.1.0 0.0.0.255 interface GigabitEthernet0/1 ip nat inside interface GigabitEthernet0/0 ip nat outside ip nat inside source list PERMIT_INTERNAL interface GigabitEthernet0/0 overload ip nat outside source static tcp 203.0.113.10 80 192.168.1.10 80 ip nat outside source static tcp 203.0.113.11 25 192.168.1.20 25

Why wrong: This configuration uses 'ip nat outside source static' instead of 'ip nat inside source static'. The 'outside source static' command translates the source address of packets coming from the outside, which is not the correct method for mapping external public IPs to internal servers. The correct command is 'ip nat inside source static'.