LogoفارسیFA

Hands-On Lab: PPP Authentication Using CHAP (Method 1 — Matching Usernames)

This hands-on lab configures CHAP authentication on a PPP serial link using matching local usernames on both routers, demonstrating CHAP's more secure challenge-response exchange compared to PAP and highlighting the critical requirement that both sides share an identical secret.

PPP CHAP AuthenticationChallenge HandshakeShared Secret Configuration

~3 min read · Updated Sep 12, 2026

Lab Objective

Configure CHAP authentication between two routers using the straightforward method of matching usernames and passwords, verify the challenge-response exchange completes successfully, and observe a mismatched-secret failure.

Lab Purpose

Unlike PAP, covered in the previous lab, CHAP never sends the actual password across the link — it uses a challenge-response mechanism based on a shared secret, making it significantly more resistant to interception. This is the reason CHAP is strongly preferred over PAP in virtually all real-world deployments.

Lab Topology

R1 ---- Serial0/0/0 (DTE) ------ Serial0/0/0 (DCE) ---- R2

R1: 10.12.12.1/30
R2: 10.12.12.2/30

Both routers already run PPP encapsulation

Task 1: Configure Matching Usernames and Passwords

On each router, create a local username matching the OTHER router's hostname, with both routers using the identical secret password.

Task 2: Enable CHAP Authentication

Enable CHAP authentication on both routers' serial interfaces.

Task 3: Verify the Challenge-Response Exchange

Use debug output to observe the CHAP challenge and response messages exchanged between the two routers.

Task 4: Verify Connectivity

Confirm the link authenticates successfully and IP connectivity works.

Task 5: Introduce a Secret Mismatch

Change the password in R1's local username entry for R2 without updating R2's matching entry, and observe the resulting failure.

Solution and Verification

R1(config)# username R2 password SharedSecret1
R1(config)# interface serial0/0/0
R1(config-if)# encapsulation ppp
R1(config-if)# ppp authentication chap

R2(config)# username R1 password SharedSecret1
R2(config)# interface serial0/0/0
R2(config-if)# encapsulation ppp
R2(config-if)# ppp authentication chap

R1# debug ppp authentication

PPP Serial0/0/0: Send CHAP challenge id=1
PPP Serial0/0/0: CHAP challenge from R2
PPP Serial0/0/0: CHAP response received from R2
PPP Serial0/0/0: remote passed CHAP authentication

-- Note: no password ever appears in this
-- exchange -- only a challenge and a hashed
-- response computed from the shared secret,
-- fundamentally different from PAP's plain-text
-- exchange covered in the previous lab

R1# show interfaces serial0/0/0

Serial0/0/0 is up, line protocol is up

R1# ping 10.12.12.2

!!!!!
Success rate is 100 percent (5/5)

R1(config)# username R2 password DifferentSecret

R1# show interfaces serial0/0/0

Serial0/0/0 is up, line protocol is down

R1# debug ppp authentication

PPP Serial0/0/0: CHAP response received from R2
PPP Serial0/0/0: remote FAILED CHAP authentication
-- The hash R1 computes using its own stored
-- secret no longer matches what R2's response
-- expects, since R1's local copy of the secret
-- changed while R2's did not

R1(config)# username R2 password SharedSecret1

R1# show interfaces serial0/0/0
Serial0/0/0 is up, line protocol is up

Key Takeaway

With this matching-username method, both routers must store the identical secret under a username matching the OTHER router's hostname — CHAP's security comes from never transmitting this secret directly, but this also means both sides' locally stored copies must always remain perfectly synchronized, since there is no way to simply "resend" a forgotten password as PAP effectively allows.

Written & researched by Dr. Shahin Siami

Related Articles

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.

Continue

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.

Continue

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.

Continue

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.

Continue

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.

Continue

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.

Continue
Previous ArticleNext Article