May
15

 

The following question was recently sent to me regarding PPP and CHAP:

 

At the moment I only have packet tracer to practice on, and have been trying to setup CHAP over PPP.

It seems that the "PPP CHAP username xxxx" and "PPP CHAP password xxxx" commands are missing in packet tracer.

I have it set similar to this video... (you can skip the first 1 min 50 secs)

https://www.youtube.com/watch?v=5ltNfaPz0nA

As he doesn't use the missing commands, if that were to be done on live kit would it just use the hostname and magic number to create the hash?

 

Also, in bi-directional authentication, do both routers have to use the same password or can they be different as long as they match what they expect from the other router?

Thanks, Paul.

 

Here was my reply:

Hi Paul,

When using PPP CHAP keep in mind four fundamental things:

  1. The "magic number" that you see in PPP LCP messages has nothing to do with Authentication or CHAP.  It is simply PPPs way of trying to verify that it has a bi-directional link with a peer. When sending a PPP LCP message a random Magic Number is generated.  The idea is that you should NOT see your own Magic Number in LCP messages received from your PPP Peer.  If you DO see the same magic number that you transmited, that means you are talking to yourself (your outgoing LCP CONFREQ message has been looped back to you).  This might happen if the Telco that is providing your circuit is doing some testing or something and has temporarily looped-back your circuit.
  2. At least one of the devices will be initiating the CHAP challenge.  In IOS this is enabled with the interface command, “ppp authentication chap”.  Technically it only has to be configured on one device (usually the ISP router that wishes to “challenge” the incoming caller) but with CHAP you can configure it on both sides if you wish to have bi-directional CHAP challenges.
  3. Both routers need a CHAP password, and you have a couple of options on how to do this.
  4. The "hash" that is generated in an outgoing PPP CHAP Response is created as a combination of three variables, and without knowing all three values the Hash Response cannot be generated:
  • A router's Hostname
  • The configured PPP CHAP password
  • The PPP CHAP Challenge value

I do all of my lab testing on real hardware so I can't speak to any "gotchas" that might be present in simulators like Packet Tracer.  But what I can tell you, is that on real routers the side that is receiving the CHAP challenge must be configured with an interface-level CHAP password.

The relevant configurations are below as an example.

ISP router that is initiating the CHAP Challenge for incoming callers:

username Customer password cisco
!
interface Serial1/3
encapsulation ppp
ppp authentication chap
ip address x.x.x.x y.y.y.y
!

Customer router placing the outgoing PPP call to ISP:

hostname Customer
!
interface Serial1/3
encapsulation ppp
ppp chap password cisco
ip address x.x.x.x y.y.y.y
!

If you have a situation where you expect that the Customer Router might be using this same interface to "call" multiple remote destinations, and use a different CHAP password for each remote location, then you could add the following:

 

Customer router placing the outgoing PPP call to ISP-1 (CHAP password = Bob) and ISP-2 (CHAP password = Sally):

hostname Customer
!
username ISP-1 password Bob
<em><strong>username ISP-2 password Sally</strong></em>
!
interface Serial1/3
encapsulation ppp
ppp chap password cisco
ip address x.x.x.x y.y.y.y
!

Notice in the example above, the "username x password y" commands supercede the interface-level command, "ppp chap password x". But please note that the customer (calling) router always needs the "ppp chap password" command configured at the interface level.  A global "username x password y" in the customer router does not replace this command.  In this situation, if the Customer router placed a call to ISP-3 (for which there IS no "username/password" statement) it would fallback to using the password configured at the interface-level.

Lastly, the "username x password y" command needs to be viewed differently depending on whether or not it is configured on the router that is RESPONDING to a Challenge...or is on the router that is GENERATING the Challenge:

  • When the command "username X password Y" is configured on the router that is responding to the CHAP Challenge (Customer router), the router's local "hostname" and password in this command (along with the received Challenge) will be used in the Hash algorithm to generate the CHAP RESPONSE.

 

  • When the command "username X password Y" is configured on the router that is generating the CHAP Challenge (ISP Router), once the ISP router receives the CHAP Authentication Response (which includes the hostname of the Customer/calling router) it will match that received Hostname to a corresponding "username X password Y" statement. If one is found that matches, then the ISP router will perform its own CHAP hash of the username, password, and Challenge that it previously created to see if its own, locally-generated result matches the result that was received in the CHAP Response.

Lastly, you asked, " Also, in bi-directional authentication, do both routers have to use the same password or can they be different as long as they match what they expect from the other router?"

Hopefully from my explanations above it is now clear that in the case of bi-directional authentication, the passwords do indeed have to be the same on both sides.

 

Hope that helps!

Keith

 

 

 

 

Jan
14

In this post, we will examine PAP and CHAP forms of PPP authentication. The emphasis here will be on the fact that these technologies are one-way in nature. So many of my CCIE-level students believe that they must be configured in a bidirectional configuration. I guess this is because it is what traditional Cisco classes always demonstrate at the CCNA and CCNP levels.

OK - I have pre-configured two routers, R1 and R2, they are connected by their Serial 0/0 interfaces. Let us begin with R1 as a PPP PAP server, and the R2 device as the PPP PAP client. If you ALWAYS think of these technologies (PAP and CHAP) in terms of CLIENT and SERVER commands, you will be in excellent shape.

Let us begin with R1 playing the role of a PAP server and R2 playing the role of a PAP client. In other words, R1 will be the device that requires authentication, and R2 will be the device that must respond with the correct authentication information.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#username ROUTER2 password cisco
R1(config)#int s0/0
R1(config-if)#encapsulation ppp
*Mar  1 00:04:47.359: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to down
R1(config-if)#ppp authentication pap
R1(config-if)#end

Here is the configuration of the PAP client:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int s0/0
R2(config-if)#encapsulation ppp
R2(config-if)#ppp pap sent-username ROUTER2 password cisco
R2(config-if)#end
R2#
*Mar  1 00:08:40.539: %SYS-5-CONFIG_I: Configured from console by console
R2#
*Mar  1 00:08:41.647: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up
R2#

Study these server and client commands above carefully. Also, notice how the moment the correct commands are entered on the client, the link is established.

Now it is time to review the CHAP configuration. We will have the R2 device serve as the CHAP server and the R1 device function as the CHAP client. First the R2 CHAP server commands:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#username R1 password cisco
R2(config)#int s0/0
R2(config-if)#ppp authentication chap
R2(config-if)#
*Mar  1 00:14:06.407: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to down
R2(config-if)#end
R2#

Now the CHAP client configuration on R1:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#username R2 password cisco
R1(config)#
*Mar  1 00:16:43.983: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up
R1(config)#

Notice that once the matching shared secret password of cisco is placed on the client system, the link is restored.

Enjoy your CCNA studies here at INE!

Subscribe to INE Blog Updates

New Blog Posts!