NAT and PAT Configuration Scenarios

It defines the inside interface for NAT.

Why it fails: The command 'ip nat inside source list' does not define the NAT inside interface; that is done with the interface-level command 'ip nat inside'. The access-list in the NAT command only selects which source addresses are eligible for translation, not which interface is inside. Thus, this option confuses interface role configuration with traffic selection.

It filters inbound traffic before NAT is applied.

Why it fails: This access-list is not a security filter and does not inspect or drop traffic based on inbound direction; it merely classifies which inside source addresses should be translated when the packet exits the outside interface. Inbound filtering is accomplished separately with an access-group applied to an interface using 'ip access-group', which evaluates packet headers independently of NAT. The NAT ACL has no effect on permitting or denying traffic—it only influences translation eligibility.

It configures the router as a DHCP server.

Why it fails: DHCP server functionality is configured with commands like 'ip dhcp pool' and 'network', which define address pools and options to distribute to clients. The command in question is part of the 'ip nat' configuration and is used solely for address translation, not for allocating IP addresses. Although DHCP and NAT often coexist on the same router, this specific command does not enable DHCP services.

vSmart controller

Why it fails: vSmart is not the answer because it operates as the control plane controller, responsible for running Overlay Management Protocol (OMP) and exchanging routing and policy information with vEdge routers. While it is critical for path selection and centralized policy, it does not perform initial orchestrator duties like device authentication or NAT traversal. vSmart itself must learn about vBond through the vBond orchestrator during its own onboarding process.

vManage NMS

Why it fails: vManage is incorrect for this role because it is the network management system (NMS) that provides centralized configuration, monitoring, and fault management for the entire SD-WAN fabric. It runs the GUI and REST APIs used by administrators, but it does not handle the initial discovery or authentication of devices. In fact, vManage is one of the devices that vBond helps other nodes locate, so it depends on vBond rather than serving as the orchestrator.

vEdge router

Why it fails: vEdge routers are not orchestrators; they are data plane devices that forward user traffic based on policies pushed from vSmart and configuration from vManage. Their role is strictly packet forwarding and applying local policies, with no visibility into the initial authentication or NAT traversal process. Each vEdge also requires vBond at startup to authenticate itself and discover the active vManage and vSmart controllers.

The access list used for NAT does not permit the web server's IP address.

Why it fails: An ACL referenced in a NAT configuration (e.g., ip nat inside source list) serves only to match inside local addresses for dynamic translation. Static NAT entries are created with an explicit ip nat inside source static command and are never filtered by an ACL. Therefore, even if the ACL denied the web server's address, it would have no bearing on a static mapping; the inability to reach the web server is due solely to the missing static entry.

The ip nat inside and ip nat outside commands are applied on the wrong interfaces.

Why it fails: If ip nat inside and ip nat outside were swapped on the interfaces, the router would fail to correctly translate traffic for all hosts, and outbound sessions would typically break as well. The scenario focuses on a single internal web server being unreachable from outside, which indicates a missing static mapping rather than a global interface configuration error. Correct interface placement is a prerequisite, but the specific symptom of only the web server failing points to the absence of the static NAT command, not to misapplied interface directives.

The global configuration mode is missing the ip nat pool command.

Why it fails: An ip nat pool defines a range of global addresses for use with dynamic NAT or PAT, typically paired with a source ACL in a command like ip nat inside source list <acl> pool <name>. Static NAT, which is what a web server requires for inbound access, does not involve a pool; it uses the ip nat inside source static command to map one specific inside local address to one inside global address. The absence of a pool is irrelevant because static NAT never references a pool, so this cannot explain why the web server is unreachable.

All translations are static NAT entries.

Why it fails: Static NAT entries are manually configured and persist in the translation table indefinitely, regardless of traffic. The provided output shows no such persistence evidence: every entry is accompanied by an idle timer context, and several entries carry TCP/UDP port numbers, which static NAT never creates. Static NAT would never mix port-based translations with portless ones, so the statement that all translations are static is false.

The router is performing only PAT (overload).

Why it fails: If the router were performing only PAT (overload), every translation would include a protocol field and port numbers in the inside local/inside global columns, because PAT multiplexes many inside hosts onto a single outside address. The output, however, contains a portless one-to-one translation for 10.0.0.10, which cannot occur with pure PAT. Additionally, the outside global addresses are not all the same; a single overloaded interface would reuse one public IP for all translations, so the observed diversity of outside global addresses contradicts this option.

The outside global address is the same for all translations.

Why it fails: The translation table clearly lists different outside global addresses: 203.0.113.5 is used in some entries, while 198.51.100.2 appears in others. If every translation shared the same outside global address, the configuration would have to be a single-address pool or one overloaded interface. Since the output shows at least two distinct outside global addresses, the statement that the outside global address is the same for all translations is incorrect.

Static NAT

Why it fails: Static NAT creates a permanent, one-to-one mapping between a private inside address and a public outside address. It does not involve any port multiplexing, so a single public IP can only represent one internal host at a time. This makes it suitable for inbound services (e.g., a web server) but wasteful and impractical for large numbers of internal users sharing a single public IPv4 address.

Dynamic NAT

Why it fails: Dynamic NAT maps multiple inside addresses to a pool of public addresses on a first-come, first-served basis, but each translation still consumes one entire public IP per active session. When the pool is exhausted, no additional translations occur, and like static NAT, it lacks port-level multiplexing. It is useful for outbound-only environments with enough public addresses, but it does not achieve the address conservation that PAT provides.

Policy NAT

Why it fails: Policy NAT is used to perform NAT based on extended access-control-list matching criteria (source, destination, protocol, and port), but it does not inherently perform port multiplexing. It can be used to enforce different translation rules for different traffic types, such as translating some traffic to one public IP and other traffic to a different public IP or to a PAT pool. The concept is about policy-driven selection of translation behavior, not about conserving addresses through port-level multiplexing, so it is not the mechanism that allows multiple inside addresses to share a single outside IP.

The vManage IP address is not configured on the branch routers.

Why it fails: The vManage IP address is not required during the initial ZTP/discovery phase; a vEdge router first contacts the vBond orchestrator, which authenticates the device and then supplies the vManage and vSmart addresses. The vManage is only the management plane, so omitting its IP in the bootstrap configuration would not prevent the control connections from being established. Therefore, this is not the cause of the branch routers failing to connect.

The vSmart IP address is not configured on the branch routers.

Why it fails: In Cisco SD-WAN, the vSmart controller address is learned dynamically after the vBond handshake, not statically configured on branch routers. Without a valid vBond endpoint, the router cannot request the vSmart list, so the absence of a vSmart IP is a symptom of the discovery failure rather than the root cause. The branch device only needs the vBond IP or FQDN to start the secure authentication and receive the controller list.

The DTLS port 12346 is not open on the branch routers' firewall.

Why it fails: While DTLS (the default control-plane protocol) uses UDP 12346 on the vBond, the engineer has already verified transport-layer reachability across the WAN, so a firewall drop is not indicated. Even if the port is open, the branch router has no destination address to target because the vBond IP is missing; the connection attempt cannot start. Thus, port 12346 blocking is not the correct explanation for the failure.

These translations will expire after a configurable timeout.

Why it fails: The verbose output shows timeout: never with flags: static, so these entries persist indefinitely rather than ageing out. Configurable idle timeouts apply to dynamic translations, which is why the option tempts anyone who assumes all NAT entries eventually expire.

The translations are dynamic and will be removed after idle timeout.

Why it fails: The flags: static and timeout: never fields show these mappings are static, so they are not removed after idle timeout. Dynamic translations do age out, which is why the option tempts engineers accustomed to seeing timeout values on NAT entries.

The router is performing PAT for these addresses.

Why it fails: PAT multiplexes many inside local addresses onto one inside global address using port numbers; here each local address maps one-to-one to a distinct global address. PAT is tempting because it is the commonest NAT deployment, but the one-to-one pairing in the output rules it out.

ip nat pool POOL 203.0.113.5 203.0.113.5 netmask 255.255.255.0

Why it fails: This command creates a NAT pool with a single address. While it could be used for dynamic NAT, the scenario requires translating to the outside interface address, which is better done with interface overload. This command does not define the source list of inside addresses.

ip nat inside source list 1 interface GigabitEthernet0/0 overload

Why it fails: This command enables NAT overload using the outside interface, but it requires an existing access list to define the inside addresses. It is part of the configuration but not the command that defines the source list itself. The question asks for the command to define the NAT source list.

ip nat inside source static 192.168.1.1 203.0.113.5

Why it fails: This command creates a static NAT translation for a single inside host, not for the entire subnet. The scenario requires translating all inside addresses, so a static entry is insufficient. It also does not define a source list for dynamic translation.

Configure OSPF to use a different DSCP value so it matches a higher-priority class in the CoPP policy.

Why it fails: Changing the DSCP value of OSPF packets is not a standard practice and would require modifications on all OSPF neighbors. CoPP classification is typically based on ACLs matching protocol and port numbers, not DSCP. This approach is complex and unlikely to resolve the issue without additional changes.

Remove the CoPP policy from the control plane and reapply it after OSPF stabilizes.

Why it fails: Removing the CoPP policy entirely would eliminate control plane protection, leaving the router vulnerable to DoS attacks. While it might temporarily resolve the OSPF flapping, it does not maintain the required protection. The goal is to adjust the policy, not disable it, to balance security and routing stability.

Apply the CoPP policy only to the management plane interface instead of the control plane.

Why it fails: CoPP is designed to protect the control plane, which handles routing protocol traffic. Applying it to the management plane interface would not protect the control plane from OSPF floods and would leave the router vulnerable. The management plane is separate and typically protected by other means like ACLs.

CoPP cannot be applied to BGP traffic; it only supports management protocols like SSH and SNMP.

Why it fails: CoPP can match and police any control plane traffic, including BGP. The limitation is not protocol support but the policy design. Claiming CoPP cannot handle BGP is incorrect and would lead the engineer away from the real issue of insufficient classification granularity.

The service-policy must be applied to the data plane instead of the control plane for BGP to be protected.

Why it fails: CoPP is specifically applied to the control plane to protect the route processor. Applying it to the data plane would not protect BGP keepalives, which are processed by the control plane. This option misunderstands the purpose and placement of CoPP.

The policer should be configured with 'police cir' instead of 'police pps' to properly rate-limit BGP.

Why it fails: Both pps and cir-based policing can be used in CoPP. The issue is not the unit of measurement but the fact that all three protocols share one policer. Changing to cir would not separate BGP from SSH and SNMP, so BGP could still be dropped during congestion.

The access list 1 is too permissive and includes the public IP address of the router.

Why it fails: While a permissive ACL may match more inside hosts than intended, including the router's own public IP in access list 1 does not directly exhaust the NAT translation table. PAT only translates traffic sourced from inside local addresses that enters the inside interface, so packets sourced from the outside/public IP would rarely traverse that path. Even if it did, this would be a constant misconfiguration causing consistent behavior, not sporadic translation failures tied to session volume.

The router is not configured with ip nat inside on the internal interface.

Why it fails: The 'ip nat inside' command marks the interface where inside local addresses are sourced before translation. If it were missing from the internal interface, no traffic arriving on that interface would be translated at all — every inside host would fail to reach the Internet, not just intermittently. With PAT, a missing 'ip nat inside' would also produce a persistent, total outage rather than a table-filling condition. Thus, this configuration error cannot explain sporadic connectivity.

The overload keyword is misspelled or not supported on this IOS version.

Why it fails: The 'overload' keyword is a standard, widely supported IOS parameter that enables PAT; if it were misspelled, the router would reject the command with a syntax error during configuration, not silently malfunction. An unsupported keyword on an older IOS version would similarly cause a configuration rejection, not allow the NAT rule to install and then behave unpredictably. Consequently, the session-dependent failures described are not consistent with a keyword that was never accepted by the router.