Hands-On Lab: PPP Authentication Using PAP

This hands-on lab configures PAP authentication on a PPP serial link, demonstrating the simple two-way username and password exchange PAP uses, and shows what happens when the configured credentials do not match between the two routers.

PPP PAP AuthenticationSerial Link SecurityUsername Password Configuration

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۲۱ شهریور ۱۴۰۵

Lab Objective

Configure PAP authentication between two routers running PPP, verify successful authentication, then introduce a credential mismatch and observe the resulting failure.

Lab Purpose

PAP is one of two standard PPP authentication methods, and while it sends credentials in clear text (a security weakness covered in more depth when comparing it to CHAP in a later lab), it remains a fundamental building block for understanding WAN link security and is still occasionally required for compatibility with older equipment.

Lab Topology

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

R1: 10.11.11.1/30
R2: 10.11.11.2/30

Both routers already run PPP encapsulation,
as configured in the previous lab

Task 1: Configure Usernames on Both Routers

On R1, create a local username matching R2's hostname with an agreed-upon password. On R2, create a local username matching R1's hostname with the same password.

Task 2: Enable PPP and PAP

Ensure PPP encapsulation is set, then enable PAP authentication on both serial interfaces.

Task 3: Configure the Outbound PAP Credentials

On each router's interface, specify the username and password to send to the remote peer during authentication.

Task 4: Verify Successful Authentication

Confirm the link authenticates successfully and IP connectivity works.

Task 5: Introduce a Password Mismatch

Change the password in R2's local username database without updating R1's outbound credentials, then observe the resulting authentication failure.

Solution and Verification

R1(config)# username R2 password Cisco123
R1(config)# interface serial0/0/0
R1(config-if)# encapsulation ppp
R1(config-if)# ppp authentication pap
R1(config-if)# ppp pap sent-username R1 password Cisco123

R2(config)# username R1 password Cisco123
R2(config)# interface serial0/0/0
R2(config-if)# encapsulation ppp
R2(config-if)# ppp authentication pap
R2(config-if)# ppp pap sent-username R2 password Cisco123

R1# show interfaces serial0/0/0

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

R1# ping 10.11.11.2

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

R2(config)# username R1 password WrongPassword

R1# show interfaces serial0/0/0

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

R1# debug ppp authentication

PPP Serial0/0/0: remote passed PAP authentication
PPP Serial0/0/0: Send PAP Auth-Nak
-- R2 rejects R1's credentials, since R2's
-- local username database no longer has the
-- matching password R1 is sending

R2(config)# username R1 password Cisco123

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

Key Takeaway

Each router's local username command defines what credentials it expects to RECEIVE from a peer, while ppp pap sent-username defines what credentials it SENDS — these are easy to confuse, and a mismatch on either side (expected versus sent) produces the identical authentication failure, so both must be checked during troubleshooting.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

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.

ادامه

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.

ادامه

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.

ادامه

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.

ادامه

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.

ادامه

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.

ادامه