{"id":4063,"date":"2026-10-13T10:41:52","date_gmt":"2026-10-13T10:41:52","guid":{"rendered":"https:\/\/www.exam-topics.net\/blog\/cisco-200-301-dhcp-relay-nat-ssh-troubleshooting-lab\/"},"modified":"2026-10-13T10:41:52","modified_gmt":"2026-10-13T10:41:52","slug":"cisco-200-301-dhcp-relay-nat-ssh-troubleshooting-lab","status":"publish","type":"post","link":"https:\/\/www.exam-topics.net\/blog\/cisco-200-301-dhcp-relay-nat-ssh-troubleshooting-lab\/","title":{"rendered":"Cisco 200-301: DHCP Relay, NAT and SSH Troubleshooting Lab"},"content":{"rendered":"

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<\/a> 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.<\/p>\n

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.<\/p>\n

Design a path with separate address, translation and management functions<\/h2>\n

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.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Component<\/th>\nLab address<\/th>\nExpected job<\/th>\n<\/tr>\n<\/thead>\n
Client<\/td>\nDHCP on 192.0.2.0\/24<\/td>\nLearn an address, mask and gateway<\/td>\n<\/tr>\n
R1 Gi0\/0<\/td>\n192.0.2.1\/24<\/td>\nClient gateway and DHCP relay point<\/td>\n<\/tr>\n
DHCP server<\/td>\n198.51.100.10\/24<\/td>\nOffer the client-subnet scope via relay<\/td>\n<\/tr>\n
R1 Gi0\/1<\/td>\n198.51.100.1\/24<\/td>\nRoute to the DHCP server<\/td>\n<\/tr>\n
R1 Gi0\/2<\/td>\n203.0.113.2\/30<\/td>\nOutside NAT interface<\/td>\n<\/tr>\n
Upstream router<\/td>\n203.0.113.1\/30<\/td>\nRoute back toward the translation pool<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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.<\/p>\n

Verify interfaces and routing before testing services<\/h2>\n

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<\/a> establishes that Layer 3 baseline.<\/p>\n

R1# show ip interface brief\nR1# show ip route connected\nR1# ping 198.51.100.10\nR1# show running-config interface GigabitEthernet0\/0\nR1# show running-config interface GigabitEthernet0\/2<\/code><\/pre>\n
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.<\/p>\n
Relay the DHCP request to a server on another subnet<\/h2>\n
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.<\/p>\n
R1# configure terminal\nR1(config)# interface GigabitEthernet0\/0\nR1(config-if)# ip helper-address 198.51.100.10\nR1(config-if)# end\nR1# show running-config interface GigabitEthernet0\/0<\/code><\/pre>\n
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.<\/p>\n
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<\/a> helps separate these symptoms without treating NAT as an imagined DHCP fix.<\/p>\n
Be aware that an IOS ip helper-address<\/code> 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.<\/p>\n
Configure dynamic inside-source NAT with a real return path<\/h2>\n
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.<\/p>\n
R1# configure terminal\nR1(config)# access-list 10 permit 192.0.2.0 0.0.0.255\nR1(config)# ip nat pool CCNA_LAB 203.0.113.65 203.0.113.70 netmask 255.255.255.248\nR1(config)# ip nat inside source list 10 pool CCNA_LAB\nR1(config)# interface GigabitEthernet0\/0\nR1(config-if)# ip nat inside\nR1(config-if)# exit\nR1(config)# interface GigabitEthernet0\/2\nR1(config-if)# ip nat outside\nR1(config-if)# exit\nR1(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.1\nR1(config)# end\nR1# show ip nat translations\nR1# show ip nat statistics\nR1# show access-lists 10<\/code><\/pre>\n
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<\/code> 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.<\/p>\n
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<\/a> explanation gives the conceptual background, while this lab focuses on what you can infer from command output.<\/p>\n
Compare dynamic and static NAT without overlapping mappings<\/h2>\n
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.<\/p>\n
R1(config)# no ip nat inside source list 10 pool CCNA_LAB\nR1(config)# no ip nat pool CCNA_LAB\nR1(config)# ip nat inside source static 192.0.2.10 203.0.113.65\nR1(config)# end\nR1# show ip nat translations<\/code><\/pre>\n
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.<\/p>\n
Enable SSH management without confusing it with NAT<\/h2>\n
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.<\/p>\n
R1# configure terminal\nR1(config)# hostname R1\nR1(config)# ip domain name lab.example\nR1(config)# username netops secret <choose-a-unique-lab-secret>\nR1(config)# crypto key generate rsa modulus 2048\nR1(config)# ip ssh version 2\nR1(config)# line vty 0 4\nR1(config-line)# login local\nR1(config-line)# transport input ssh\nR1(config-line)# end\nR1# show ip ssh\nR1# show running-config | section line vty<\/code><\/pre>\n
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.<\/p>\n
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<\/a> 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.<\/p>\n
Diagnose by the first stage that actually fails<\/h2>\n\n\n\n\n\n\n\n\n\n\n
Observed result<\/th>\nInvestigate first<\/th>\nDo not assume<\/th>\n<\/tr>\n<\/thead>\n
No DHCP lease<\/td>\nClient-facing helper, server scope, UDP policy and return route<\/td>\nThat NAT must be enabled for DHCP<\/td>\n<\/tr>\n
Lease exists but gateway is wrong<\/td>\nDHCP scope options and host route table<\/td>\nThat router outside routing is the only problem<\/td>\n<\/tr>\n
Outside flow has no translation<\/td>\nNAT inside\/outside roles, ACL match, pool exhaustion<\/td>\nThat the remote server is down<\/td>\n<\/tr>\n
Translation exists but response never returns<\/td>\nUpstream route to global pool and outside filtering<\/td>\nThat the presence of a NAT entry proves success<\/td>\n<\/tr>\n
Ping reaches R1 but SSH fails<\/td>\nSSH service, keys, VTY transport, authentication and access restrictions<\/td>\nThat a static NAT rule will repair local management<\/td>\n<\/tr>\n
SSH works but DNS names fail<\/td>\nResolver settings, DHCP option and DNS reachability<\/td>\nThat an encrypted management session proves every service<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
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.<\/p>\n
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.<\/p>\n","protected":false},"excerpt":{"rendered":"
An original Cisco CCNA 200-301 IOS lab for diagnosing DHCP relay, inside-source NAT pools, return routing and secure SSH management.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11,1],"tags":[],"class_list":["post-4063","post","type-post","status-publish","format-standard","hentry","category-cisco","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts\/4063","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/comments?post=4063"}],"version-history":[{"count":0,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts\/4063\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/media?parent=4063"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/categories?post=4063"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/tags?post=4063"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}