PPP Authentication with MD5

I had a task this weekend that asked to authenticate PPP via Md5. I did a context sensitive help and saw this:

R2(config-if)#ppp authentication ?
chap        Challenge Handshake Authentication Protocol (CHAP)
eap         Extensible Authentication Protocol (EAP)
ms-chap     Microsoft Challenge Handshake Authentication Protocol (MS-CHAP)
ms-chap-v2  Microsoft CHAP Version 2 (MS-CHAP-V2)
pap         Password Authentication Protocol (PAP)

Doesn't look like there is an Md5 option...or is there? I looked up the ppp authentication commands in the DocCD:

-12.4 Mainline
-Master Index
-Cisco IOS Master Command List, All Releases
-ppp authentication MWP-147, SEC-1481

Click the SEC-1481 link

Now is where I used the browser search to look for "Md5." Not sure if this is possible in the lab so you may have to quickly scan with your eyes. The only hit comes up under "ppp eap local" command. You will see this phrase:

"In local mode, the EAP session is authenticated using the MD5 algorithm and obeys the same authentication rules as does Challenge Handshake Authentication Protocol (CHAP)."

Voila!

So now that we know what mode we need everything else is easy, and it works just like CHAP. On both sides:

username R5 password cisco

interface Serial1/1
ip address 150.100.25.2 255.255.255.0
encapsulation ppp
ppp authentication eap
ppp eap password 0 cisco
ppp eap local

Always verify just to make sure it's working:

R2#debug ppp authentication

*Mar  1 00:34:34.779: Se1/1 PPP: Using default call direction
*Mar  1 00:34:34.783: Se1/1 PPP: Treating connection as a dedicated line
*Mar  1 00:34:34.783: Se1/1 PPP: Session handle[9700001A] Session id[32]
*Mar  1 00:34:34.787: Se1/1 PPP: Authorization required
*Mar  1 00:34:34.967: Se1/1 EAP: O REQUEST  IDENTITY id 50 len 5
*Mar  1 00:34:35.015: Se1/1 EAP: I REQUEST  IDENTITY id 19 len 5
*Mar  1 00:34:35.015: Se1/1 EAP: O RESPONSE IDENTITY id 19 len 7 from "R2"
*Mar  1 00:34:35.123: Se1/1 EAP: I RESPONSE IDENTITY id 50 len 7 from "R5"
*Mar  1 00:34:35.127: Se1/1 EAP: O REQUEST  MD5 id 51 len 24 from "R2"
*Mar  1 00:34:35.131: Se1/1 EAP: I REQUEST  MD5 id 20 len 24 from "R5"
*Mar  1 00:34:35.147: Se1/1 EAP: Using hostname from unknown source
*Mar  1 00:34:35.151: Se1/1 EAP: Using password from interface EAP
*Mar  1 00:34:35.151: Se1/1 EAP: O RESPONSE MD5 id 20 len 24 from "R2"
*Mar  1 00:34:35.435: Se1/1 EAP: I RESPONSE MD5 id 51 len 24 from "R5"
*Mar  1 00:34:35.451: Se1/1 PPP: Sent CHAP LOGIN Request
*Mar  1 00:34:35.455: Se1/1 EAP: I SUCCESS id 20 len 4
*Mar  1 00:34:35.463: Se1/1 PPP: Received LOGIN Response PASS
*Mar  1 00:34:35.475: Se1/1 PPP: Sent LCP AUTHOR Request
*Mar  1 00:34:35.483: Se1/1 PPP: Sent IPCP AUTHOR Req
*Mar  1 00:34:35.495: Se1/1 LCP: Received AAA AUTHOR Response PASS
*Mar  1 00:34:35.499: Se1/1 IPCP: Received AAA AUTHOR Response PASS
*Mar  1 00:34:35.499: Se1/1 EAP: O SUCCESS id 51 len 4
*Mar  1 00:34:35.507: Se1/1 PPP: Sent CDPCP AUTHOR Request
*Mar  1 00:34:35.519: Se1/1 CDPCP: Received AAA AUTHOR Response PASS
*Mar  1 00:34:35.543: Se1/1 PPP: Sent IPCP AUTHOR Request

*Mar  1 00:34:36.503: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/1, changed state to up

You can see above that we have incoming and outgoing MD5 reposnses and the requests pass.

PPP - Negotiated address via DHCP

This kind of task may seem more difficult than it really is. I, in fact, spent way too long one morning/afternoon/evening trying to get this scenario to work. Turns out my server did not have a route back to the requester's subnet. So here it is without all the crap (ok, some of it) I went through:

Topology:

R5---R2---R1

R5 to R2 is PPP.
R5 needs to negotiate its address.
R1 is to supply this address.

R2-R5: 150.100.25.x/24
R1-R2: 150.100.12.x/24

R5 config is EASY:

interface Serial0/1
ip address negotiated

R2 is also easy, we configure it's interface to supply the address via DHCP and then specify a DHCP server:

R2(config)#int s1/1
R2(config-if)#peer default ip address dhcp
R2(config-if)#exit
R2(config)# ip dhcp-server 150.100.12.1

On R1 we configure the pool and everything is cool, right?

R1(config)#ip dhcp pool R5
R1(dhcp-config)#network 150.100.25.0 /24
R1(dhcp-config)#exit
R1(config)#ip dhcp excluded-address 150.100.25.1 150.100.25.4
R1(config)#ip dhcp excluded-address 150.100.25.6 150.100.25.255

Let's check R5, to see if it got an address:

R5#show ip int brief | inc l1/1
Serial1/1 unassigned YES IPCP up up

Nothing! Let's do some debugging on R1 with an ACL to match DHCP packets:

R1(config)#access-list 150 pe udp any any eq bootpc
R1(config)#access-list 150 pe udp any any eq bootps
R1(config)#access-list 150 pe udp any eq bootpc any
R1(config)#access-list 150 pe udp any eq bootps any

R1#debug ip packet 150 detail
IP packet debugging is on (detailed) for access list 150

*Mar 1 00:15:27.995: IP: s=150.100.12.1 (local), d=150.100.25.2, len 328, unroutable
*Mar 1 00:15:27.999: UDP src=67, dst=67

R1 has no route to 150.100.25.0/24 yet! Let's configure one and then manually shut/no shut the interface on R5:

R1(config)#ip route 150.100.25.0 255.255.255.0 150.100.12.2

R1#debug ip dhcp server events

*Mar 1 00:19:27.263: DHCPD: Sending notification of DISCOVER:
*Mar 1 00:19:27.263: DHCPD: htype 1 chaddr 0000.0c07.79e1
*Mar 1 00:19:27.267: DHCPD: circuit id 00000000
*Mar 1 00:19:27.267: DHCPD: Seeing if there is an internally specified pool class:
*Mar 1 00:19:27.271: DHCPD: htype 1 chaddr 0000.0c07.79e1
*Mar 1 00:19:27.271: DHCPD: circuit id 00000000
*Mar 1 00:19:28.411: DHCPD: Adding binding to radix tree (150.100.25.5)
*Mar 1 00:19:28.415: DHCPD: Adding binding to hash tree
*Mar 1 00:19:28.419: DHCPD: assigned IP address 150.100.25.5 to client 0063.6973.636f.2d31.3530.2e31.3030.2e32.352e.322d.5365.7269.616c.312f.31.
*Mar 1 00:19:28.495: DHCPD: Sending notification of ASSIGNMENT:
*Mar 1 00:19:28.499: DHCPD: address 150.100.25.5 mask 255.255.255.0
*Mar 1 00:19:28.499: DHCPD: htype 1 chaddr 0000.0c07.79e1
*Mar 1 00:19:28.503: DHCPD: lease time remaining (secs) = 86400
*Mar 1 00:20:17.647: DHCPD: checking for expired leases.
*Mar 1 00:22:17.647: DHCPD: checking for expired leases.
*Mar 1 00:24:17.647: DHCPD: checking for expired leases.

Now check R5:

R5#show ip int bri s1/1
Interface IP-Address OK? Method Status Protocol
Serial1/1 150.100.25.5 YES IPCP up up
R5#

*** IMPORTANT ***

R1 needs a route back to the 150.100.25.0/24 subnet. In this case I have a default route from R1 toward R2. This is EXTREMELY important. I wasted many minutes of my life trying to get this thing to come up. My DHCP configuration was correct but the DHCP server did not have a route back to the requester!

PPP over Frame-relay with CHAP

Another task I had trouble with in Mock Lab 1 was 2.2 which is a PPP over FR task.

Here it is:

"For the connection between R4 and R5, use a PPP over frame configuration with RFC 1973 encapsulation. The connection should use CHAP authentication. For authentication both devices should use a username of T3ST123 and a password of PPPoverFr@m3. Both sides should challenge an respond."

I got PPP over FR to work fine, but when I enabled authentication it wasn't working so I skipped the task, instead just going for reachability.

Here I try it again. First, just with PPP over FR and no auth:

R4:

R4(config)#int virtual-template 1
R4(config-if)#ip address 141.141.45.4 255.255.255.0
R4(config-if)#exit
R4(config)#int s1/0
R4(config-if)#encapsulation frame-relay
R4(config-if)#frame-relay interface-dlci 405 ppp virtual-Template 1
R4(config-if)#frame-relay map ip 141.141.45.5 405 broadcast
R4(config-if)#no shut

R5:

R5(config)#int virtual-template 1
R5(config-if)#ip address 141.141.45.5 255.255.255.0
R5(config-if)#exit
R5(config)#int s1/0
R5(config-if)#encapsulation frame-relay
R5(config-if)#int s1/0.2 multipoint
R5(config-subif)#frame-relay interface-dlci 504 ppp virtual-Template 1
R5(config-subif)#frame-relay map ip 141.141.45.4 504 broadcast
R5(config-subif)#int s1/0
R5(config-if)#no shut

Verify:

R4#ping 141.141.45.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 141.141.45.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/38/92 ms
R4#

Easy enough, right? Let's add CHAP:

R4(config)#username T3ST123 password PPPoverFr@m3
R4(config)#int virtual-template 1
R4(config-if)#ppp authentication chap
R4(config-if)#ppp chap hostname T3ST123
R4(config-if)#ppp chap password PPPoverFr@m3

R5(config)#username T3ST123 password PPPoverFr@m3
R5(config)#int virtual-template 1
R5(config-if)#ppp authentication chap
R5(config-if)#ppp chap hostname T3ST123
R5(config-if)#ppp chap password PPPoverFr@m3

Notice the error we get when we try and bring up the link. R4 is ignoring the username because that's what it is using:

R4#debug ppp authentication
PPP authentication debugging is on
R4#ping 141.141.45.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 141.141.45.5, timeout is 2 seconds:

*Mar 1 00:14:42.211: Vi1 CHAP: I CHALLENGE id 18 len 28 from "T3ST123"
*Mar 1 00:14:42.211: Vi1 CHAP: Ignoring Challenge with local name
*Mar 1 00:14:42.247: Vi1 AUTH: Timeout 2
*Mar 1 00:14:42.247: Vi1 CHAP: O CHALLENGE id 27 len 28 from "T3ST123"
*Mar 1 00:14:52.247: Vi1 CHAP: I CHALLENGE id 19 len 28 from "T3ST123"
*Mar 1 00:14:52.247: Vi1 CHAP: Ignoring Challenge with local name
*Mar 1 00:14:52.263: Vi1 AUTH: Timeout 3
*Mar 1 00:14:52.263: Vi1 CHAP: O CHALLENGE id 28 len 28 from "T3ST123"
*Mar 1 00:15:02.271: Vi1 CHAP: I CHALLENGE id 20 len 28 from "T3ST123"
*Mar 1 00:15:02.271: Vi1 CHAP: Ignoring Challenge with local name

What's the answer? Well it turns out the command is not documented very well. I actually gave up and looked in the procotor guide:

R4(config)#int virtual-template 1
R4(config-if)#no ppp chap ignoreus

R5(config)#int virtual-template 1
R5(config-if)#no ppp chap ignoreus

The option doesn't even show up in context-sensitive help:

R4(config-if)#ppp chap ?
hostname Set alternate CHAP hostname
password Set default CHAP password
refuse Refuse to authenticate using CHAP
wait Wait for caller to authenticate first

In fact, I didn't find any mention of it on the DocCD and only 3 results came up in Google! One of them was this link:

Understanding and Configuring PPP CHAP Authentication

Well I guess that's how it goes in the life of a CCIE candidate

PPP - Address negotiation, authentication, and some lcp/ipcp options

Today and the next couple days I am reviewing everything I got wrong on IPexpert Volume 3 Mock Lab 1. I am setting up small networks to handle each task separately in order to completely understand the solution.

I had a PPP task which I skipped because I did not know how to do it. It was 3 points and to get reachability I just setup standard PPP.

Here is the task:

"Configure the serial link connecting R2 and R5 for PPP encapsulation, using plaintext authentication. R2 should recieve its address from R5. Configure for a maximum of 3 bad authentication retries. Configure link control and IP control to predict peer responses."

So I have a small network in Dynamips:

[R2]s1/1---s1/1[R5]

Where to begin? Let's do ip addressing first:

R5(config)#int s1/1
R5(config-if)#encapsulation ppp
R5(config-if)#ip address 141.41.205.5 255.255.255.0
R5(config-if)#peer default ip address 141.41.205.2

R2(config)#int s1/1
R2(config-if)#encapsulation ppp
R2(config-if)#ip address negotiated

After enabling interfaces, here is the debug ppp negotiation output:

*Mar 1 01:41:16.819: Se1/1 IPCP: Address 141.41.205.2 (0x03068D29CD02)
*Mar 1 01:41:16.823: Se1/1 IPCP: O CONFREQ [ACKsent] id 2 len 10
*Mar 1 01:41:16.823: Se1/1 IPCP: Address 141.41.205.2 (0x03068D29CD02)
*Mar 1 01:41:16.827: Se1/1 CDPCP: I CONFACK [ACKsent] id 1 len 4
*Mar 1 01:41:16.831: Se1/1 CDPCP: State is Open
*Mar 1 01:41:16.839: Se1/1 IPCP: I CONFACK [ACKsent] id 2 len 10
*Mar 1 01:41:16.839: Se1/1 IPCP: Address 141.41.205.2 (0x03068D29CD02)

R2#show ip int brief | in 1/1
Serial1/1 141.41.205.2 YES IPCP up up

Simple enough but these commands are new to me. They appear in the dial technologies reference on the DocCD so that's a good place to look for PPP related commands. Let's configure authentication.

Do this on R2 as well. I started on R2 which is why you see the interface come back up after it dropped.

R5(config)#username cisco password cisco
R5(config)#int s1/1
R5(config-if)#ppp authentication pap
R5(config-if)#ppp max-bad-auth 3
R5(config-if)#ppp pap sent-username cisco password cisco
PPP: Warning: You have chosen a username/password combination that
is valid for CHAP. This is a potential security hole.
R5(config-if)#
*Mar 1 01:47:28.623: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/1,
changed state to up

R5(config-if)#do ping 141.41.205.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 141.41.205.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/32/84 ms
R5(config-if)#

Last part is easy if you know what the task is saying "Configure link control and IP control to predict peer responses." I don't know much about how PPP works, just how to configure the basics, ip addressing and authentication. Here is where context-sensitive help can be of value:

I noticed that ipcp and lcp were options for the ppp command. Let's have a look:

R5(config-if)#ppp lcp ?
(output omitted)
predictive Predict peers LCP requests/replies

R5(config-if)#ppp ipcp ?
(output omitted)
predictive Predict peers IPCP requests/replies

You can see the keyword "predictive" is available for both these commands. This is the answer in fact, but how can we be sure? Let's try the DocCD...Head over the master command list for 12.3. I use 12.3 a lot because they have the old links still working :)

ppp ipcp predictive

ppp lcp predictive

Here is an excerpt from the ppp ipcp entry:

"...set the PPP Internet Protocol Control Protocol (IPCP) to a predictive state that reduces negotiation time by predicting responses from peers and sending expected reply and request packets..."

So here's the commands in action:

R2(config-if)#ppp lcp predictive
R2(config-if)#ppp ipcp predictive

R5(config-if)#ppp lcp predictive
R5(config-if)#ppp ipcp predictive

These tasks seem so easy now. I admit I feel a little rushed and uncomfortable when I get a task that I know I should know but don't really no where to begin. It's all part of the learning process though and it just means I need to study things that I am unfamiliar with.