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: Configuring VTP Clients and Servers on Catalyst Switches

This hands-on lab configures VLAN Trunking Protocol between a server switch and a client switch, demonstrating how VLANs created on the server automatically propagate to the client without manual configuration on every device.

Continue

Hands-On Lab: Configuring Standard VLANs on Catalyst Switches

This hands-on lab covers creating standard-range VLANs, assigning access ports to them, and verifying that devices in different VLANs are properly isolated from each other at Layer 2.

Continue

Hands-On Lab: Verifying IP Parameters on macOS (GUI)

This hands-on lab covers checking a Mac's current IP configuration using the System Settings network panel, viewing detailed TCP/IP information, and renewing a DHCP lease directly from the graphical interface.

Continue

Hands-On Lab: Verifying IP Parameters on Linux (GUI and CLI)

This hands-on lab covers checking a Linux machine's current IP configuration using both the GUI network settings panel and command-line tools, and demonstrates renewing a DHCP lease using standard Linux networking utilities.

Continue

Hands-On Lab: Verifying IP Parameters on Windows (GUI and CLI)

This hands-on lab covers checking a Windows PC's current IP configuration using both the graphical Network Connections interface and the command-line ipconfig utility, including releasing and renewing a DHCP-assigned address.

Continue

Hands-On Lab: Power over Ethernet (PoE) Basics

This hands-on lab covers verifying PoE capability on a switch port, checking how much power is being drawn by a connected device such as an IP phone or access point, and configuring power priority to protect critical devices during a power budget shortage.

Continue
Previous ArticleNext Article