Archive for May, 2015
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)
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?
Here was my reply:
When using PPP CHAP keep in mind four fundamental things:
- 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.
- 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.
- Both routers need a CHAP password, and you have a couple of options on how to do this.
- 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
username ISP-2 password Sally
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!
Edit: Thanks for playing! You can find the official answer and explanation here.
I had an interesting question come across my desk today which involved a very common area of confusion in OSPF routing logic, and now I’m posing this question to you as a challenge!
The first person to answer correctly will get free attendance to our upcoming CCIE Routing & Switching Lab Cram Session, which runs the week of June 1st 2015, as well as a free copy of the class in download format after it is complete. The question is as follows:
Given the below topology, where R4 mutually redistributes between EIGRP and OSPF, which path(s) will R1 choose to reach the network 188.8.131.52/32, and why?
- What will R2′s path selection to 184.108.40.206/32 be, and why?
- What will R3′s path selection to 220.127.116.11/32 be, and why?
- Assume R3′s link to R1 is lost. Does this affect R1′s path selection to 18.104.22.168/32? If so, how?
Tomorrow I’ll be post topology and config files for CSR1000v, VIRL, GNS3, etc. so you can try this out yourself, but first answer the question without seeing the result and see if your expected result matches the actual result!
Good luck everyone!