Cisco 200-301: DHCP Relay, NAT and SSH Troubleshooting Lab

A client can fail to reach an application for three very different reasons: it never obtained a valid address, its packets are not being translated at the edge, or it is trying to manage a router through an unavailable or disallowed protocol. The Cisco CCNA 200-301 v1.1 blueprint includes configuring DHCP relay and inside-source NAT as well as using SSH for remote device access. These tasks belong to the same network path, but their failure symptoms must not be confused.

This hands-on lab follows one test client from address assignment to an outside connection and then to authenticated router management. Commands are IOS/IOS XE illustrations, not a universal recipe for every platform. Use a simulator or isolated authorized equipment, substitute your actual interface identifiers, and preserve console recovery access. All example addresses are documentation ranges; do not deploy them as externally reachable production assignments.

Design a path with separate address, translation and management functions

Build R1 with three routed interfaces. Gi0/0 faces a client LAN, 192.0.2.0/24, with R1 at 192.0.2.1. Gi0/1 faces a service network, 198.51.100.0/24, with R1 at 198.51.100.1 and a DHCP server at 198.51.100.10. Gi0/2 faces a simulated upstream router over 203.0.113.0/30, with R1 at 203.0.113.2 and the next hop at 203.0.113.1.

Do not use the address-translation pool as if it were automatically reachable on the simulated upstream network. For this lab, reserve 203.0.113.64/29 as the translated address block and install a route on the upstream device for that /29 toward R1’s 203.0.113.2 interface. The DHCP server also needs a route back to the client subnet through 198.51.100.1, typically its default gateway. Those return paths are part of the design, not optional polishing after the commands.

Verify interfaces and routing before testing services

Start with the router’s interface addresses and connected routes. If Gi0/0 is down, no helper-address statement can make the client communicate with it. If the server subnet is missing from the routing table, relay packets cannot reach the DHCP service. Verifying Cisco router interfaces and IP addresses establishes that Layer 3 baseline.

R1# show ip interface brief
R1# show ip route connected
R1# ping 198.51.100.10
R1# show running-config interface GigabitEthernet0/0
R1# show running-config interface GigabitEthernet0/2

Confirm the expected operational states and addresses, and test the server reachability from R1. A router-originated ping does not prove the client subnet has a return route, but a failed basic ping is a reason to investigate connectivity before blaming DHCP. Once routing works, configure one service at a time and repeat the baseline checks.

Relay the DHCP request to a server on another subnet

DHCP clients initially use a broadcast to find a server; routers do not ordinarily forward that broadcast across subnets. A helper address on the receiving client-facing interface can relay supported UDP broadcasts toward the remote server. For this topology, configure it on Gi0/0, the interface that receives the client’s request, not on the server-facing Gi0/1.

R1# configure terminal
R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip helper-address 198.51.100.10
R1(config-if)# end
R1# show running-config interface GigabitEthernet0/0

Configure the DHCP server with a scope for 192.0.2.0/24 and a default router of 192.0.2.1, excluding addresses reserved for network equipment. In this topology the relay identifies the requesting client subnet to the server, and the server must be able to send its response back through R1. The exact server-side commands depend on whether the DHCP service runs on Cisco IOS, Windows, Linux or another platform; do not pretend one server’s configuration applies universally.

Now renew the client lease. If the client never gets an address, inspect the receiving interface, the helper-address value, the server scope, relay-policy filters, and return routing. A host that receives an address but no correct gateway or DNS information is a different problem from one receiving no lease at all. Understanding DHCP and DNS helps separate these symptoms without treating NAT as an imagined DHCP fix.

Be aware that an IOS ip helper-address can forward several supported UDP broadcast services, not exclusively DHCP, unless the platform configuration is restricted appropriately. In a production setting, review the actual forwarding policy and security controls rather than copying a classroom helper address without considering the wider network.

Configure dynamic inside-source NAT with a real return path

Once the client can reach its gateway, test traffic toward the simulated outside network. The CCNA v1.1 objectives explicitly include inside-source NAT using static mappings and address pools. Here, use a dynamic pool first. It provides six usable translated addresses, 203.0.113.65 through .70, in the routed 203.0.113.64/29 block. Without overload, these mappings are not an unlimited many-to-one service.

R1# configure terminal
R1(config)# access-list 10 permit 192.0.2.0 0.0.0.255
R1(config)# ip nat pool CCNA_LAB 203.0.113.65 203.0.113.70 netmask 255.255.255.248
R1(config)# ip nat inside source list 10 pool CCNA_LAB
R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip nat inside
R1(config-if)# exit
R1(config)# interface GigabitEthernet0/2
R1(config-if)# ip nat outside
R1(config-if)# exit
R1(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.1
R1(config)# end
R1# show ip nat translations
R1# show ip nat statistics
R1# show access-lists 10

Before generating traffic, the translation table may be empty because a dynamic mapping has not yet been allocated. Send a permitted test flow from the client to the simulated upstream-side destination; then inspect show ip nat translations and compare inside local versus inside global addresses. The ACL in this example identifies which source addresses are eligible for translation. It is not, by itself, an access policy that guarantees a flow is allowed through every device.

If packets leave R1 but replies never return, inspect the upstream route for 203.0.113.64/29. A successful NAT entry proves that translation occurred for a flow; it does not prove that the outside destination exists, that the return path is correct, or that a firewall permits the exchange. The general network address translation explanation gives the conceptual background, while this lab focuses on what you can infer from command output.

Compare dynamic and static NAT without overlapping mappings

Static inside-source NAT is different: one inside local address maps to a chosen inside global address rather than taking a temporarily available pool member. To test it cleanly, reset or remove the dynamic lab mapping and pool on the isolated router, confirm that stale bindings no longer conflict, and reserve 203.0.113.65 for the one test host. Do not apply the sample static statement simultaneously to an overlapping active dynamic pool.

R1(config)# no ip nat inside source list 10 pool CCNA_LAB
R1(config)# no ip nat pool CCNA_LAB
R1(config)# ip nat inside source static 192.0.2.10 203.0.113.65
R1(config)# end
R1# show ip nat translations

The upstream device must still have a path to the translated address. A static translation can be visible even before a test application succeeds; the visibility of the mapping is not evidence of end-to-end reachability. On an actual platform, clear or let old dynamic bindings expire according to the software’s supported procedure before reusing an address. In a production environment, changing a NAT policy also demands change control and an assessment of active connections.

Enable SSH management without confusing it with NAT

With basic IP connectivity proven, configure R1 to accept SSH management from a permitted internal client. SSH access relies on management reachability, hostname/domain configuration, server keys, user authentication, and VTY transport policy. A router that responds to ping but refuses SSH may have no usable RSA keys, no local or AAA authentication path, blocked VTY access, or a firewall restriction; NAT is not automatically the right remedy.

R1# configure terminal
R1(config)# hostname R1
R1(config)# ip domain name lab.example
R1(config)# username netops secret <choose-a-unique-lab-secret>
R1(config)# crypto key generate rsa modulus 2048
R1(config)# ip ssh version 2
R1(config)# line vty 0 4
R1(config-line)# login local
R1(config-line)# transport input ssh
R1(config-line)# end
R1# show ip ssh
R1# show running-config | section line vty

The local account is an example only; do not publish a reusable password or copy an instructor’s shared credentials into a live network. Select a key size and algorithms allowed by your actual IOS/IOS XE release and organizational policy. Some platforms require different RSA key-generation syntax, and enterprise environments may use AAA rather than local login. Test from an authorized client with an SSH client directed to R1’s reachable management address, then confirm the authenticated session.

Access control and authentication are separate from the encryption provided by SSH. A VTY line can be SSH-only while a policy blocks the source address. Separating AAA, TACACS+ and SSH is essential: identity and policy decisions are not the same as encrypted transport. If SSH is configured but fails, check IP reachability first, then protocol availability, key/authentication status, source restrictions, and any applicable AAA server connectivity.

Diagnose by the first stage that actually fails

Run these checks in a reproducible order: confirm host IP parameters and gateway, verify the router’s client and server interfaces, prove reachability to the DHCP server, validate the client lease, test the intended outside flow, inspect NAT state and upstream return routing, then separately test SSH. Save the command output or screenshots that support each conclusion. The absence of evidence at one stage should not become a license to change unrelated functions.

The strongest final exercise is to introduce one fault at a time. Remove the helper address and predict how the client behaves; restore it. Remove the upstream pool route and predict which NAT evidence remains; restore it. Restrict VTY transport and predict whether SSH or Telnet should work; restore the intended SSH-only policy. By learning which observations isolate each failure, you turn three exam objectives into one usable network troubleshooting method.