Sooo…. Picking back up where we left off yesterday. We we last left our heroes they were in a bind because we had mentioned that there was going to be authentication on the links but we spent too much time trying to PING with ourselves. (We did wash our hands, right?)
To get you back on track with the configurations up to this point:
So. Let’s see. Some lab requirements to make the authentication (that’s why we picked PPPoFR to begin with) more entertaining.
Lab:
1. R3 should authenticate R5 using a secure protocol. Make sure R5 uses the username INE-Rocks and a password of CISCO.
2. R5 should authenticate R3 using a different secure protocol. Make sure that R3 uses its hostname and a password of CISCO.
Now, we can do everything all at once if we feel like it (feeling lucky, punk?) but I would strongly advise NOT doing that! Complicated configurations can be done step by step. In doing so, at least in conjunction with testing properly, we can narrow down the scope of troubleshooting in case something goes horribly wrong.
But we just will plan to not have any errors, right?
(Keep telling yourself that!)
So let’s start with task number on there. R3 to authenticate R5. Secure protocol. Well, the first one that leaps to mind is CHAP. So cool, let’s go for it.
Now, here’s a question. Exactly where do we PUT the configuration for this? Would it go on the serial interface or the virtual template? Follow the packets. Conversations will go through the Virtual interfaces.
R3
int virtual-template 35
ppp authentication chap
username INE-Rocks password CISCO
And immediately we should see an effect.
R5
int s0/0/0
shut
Wow. That got us far. But here’s a question. Do we put the configuration under the Virtual-Template interface or the Multilink interface? That’s a tough one!
Let’s try the multilink interface and see what happens. It’s where our IP address is at anyway!
R5
int multilink 53
ppp chap hostname INE-rocks
ppp chap password CISCO
Notice that there is no “ppp authentication” command going on here. Authenticate is, by default, a unidirectional challenge. A router will always respond to a challenge, but does not need any specific configuration to do so (other than user/password info!). Since we aren’t using our default username, we have to manually specify it.
In addition, our configuration on the multilink interface worked just fine. Notice in the debug output all of the “I” and “O” messages. These are Incoming and Outgoing messages. So we can see what’s going on and which order it occurs.
Cool. ONE way is done. Now, the other way. We want to use a DIFFERENT secure authentication protocol now. Do we have Super-CHAP?
While PAP and CHAP are in the Dial Technologies Configuration Guide – PPP Configuration – Configuring Media-Independent PPP and Multilnk PPP section, EAP is not. EAP can be found in the Security Configuration Guide: Securing User Services – Authentication, Authorization and Accounting – Authentication – RADIUS EAP Support. Go figure.
R5 is going to be the server here, so we’ll configure the client side first (no interruption that way).
R3
interface virtual-template 35
ppp eap identity INE-R3
ppp eap password CISCO
There is no default hostname used in EAP like there would be in CHAP, so even though we thought we’d get off easy, it’s still a configuration task! Now we can go get things moving on R5 though!
R5
username INE-R3 password CISCO
interface multilink 53
ppp eap local
ppp authentication eap
And we still have our debug running, so we should be good to go!
Cool, huh? That’s likely as complicated an authentication scenario that we’d run across in the CCIE R&S lab. One last thing to point out. If you have trouble with your authentication coming up, but your configuration looks good… It’s most likely a password error. Even if you don’t SEE the problem. If you tend to go through configurations using the “?” often, whenever you get to the end of a link and see ““, you generally do exactly that, and hit Enter! However, the trailing space just became part of your line.
Most of the time this isn’t a problem, except where names are involved. Names like passwords, or key-string names or other obnoxious things like that! So write your config in notepad then, kill it from the router and re-paste it into both sides with the password WITHOUT a space. All should be good then!
Happy Configuring!
To get you back on track with the configurations up to this point:
INE-R3(config-if)#do sh run | s host|Serial1/0|Virtual|Loop hostname INE-R3 interface Loopback0 ip address 173.100.0.3 255.255.255.0 interface Serial1/0 no ip address encapsulation frame-relay frame-relay interface-dlci 305 ppp Virtual-Template35 interface Virtual-Template35 ip unnumbered Loopback0 ppp multilink INE-R3(config-if)# INE-R5(config-if)#do sh run | s host|Serial0/0/0|Virtual|Loop|Multi hostname INE-R5 interface Multilink53 ip address 173.100.0.5 255.255.255.0 ppp multilink ppp multilink group 53 interface Serial0/0/0 no ip address encapsulation frame-relay frame-relay interface-dlci 503 ppp Virtual-Template53 frame-relay lmi-type cisco interface Virtual-Template53 no ip address ppp multilink ppp multilink group 53 INE-R5(config-if)#
So. Let’s see. Some lab requirements to make the authentication (that’s why we picked PPPoFR to begin with) more entertaining.
Lab:
1. R3 should authenticate R5 using a secure protocol. Make sure R5 uses the username INE-Rocks and a password of CISCO.
2. R5 should authenticate R3 using a different secure protocol. Make sure that R3 uses its hostname and a password of CISCO.
Now, we can do everything all at once if we feel like it (feeling lucky, punk?) but I would strongly advise NOT doing that! Complicated configurations can be done step by step. In doing so, at least in conjunction with testing properly, we can narrow down the scope of troubleshooting in case something goes horribly wrong.
But we just will plan to not have any errors, right?
(Keep telling yourself that!)So let’s start with task number on there. R3 to authenticate R5. Secure protocol. Well, the first one that leaps to mind is CHAP. So cool, let’s go for it.
Now, here’s a question. Exactly where do we PUT the configuration for this? Would it go on the serial interface or the virtual template? Follow the packets. Conversations will go through the Virtual interfaces.
R3
int virtual-template 35
ppp authentication chap
username INE-Rocks password CISCO
And immediately we should see an effect.
*Dec 3 17:42:24.191: %LINK-3-UPDOWN: Interface Virtual-Access3, changed state to down *Dec 3 17:42:25.039: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to down *Dec 3 17:42:25.191: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to down INE-R3(config)#Perhaps not the intended effect, but an effect nonetheless! So let’s configure the other side? We’re going to enable some debugs though. And to minimize the mind-numbing effect of repeated failures, we’ll shut down the serial link while we configure!
R5
int s0/0/0
shut
Wow. That got us far. But here’s a question. Do we put the configuration under the Virtual-Template interface or the Multilink interface? That’s a tough one!
Let’s try the multilink interface and see what happens. It’s where our IP address is at anyway!
R5
int multilink 53
ppp chap hostname INE-rocks
ppp chap password CISCO
Notice that there is no “ppp authentication” command going on here. Authenticate is, by default, a unidirectional challenge. A router will always respond to a challenge, but does not need any specific configuration to do so (other than user/password info!). Since we aren’t using our default username, we have to manually specify it.
INE-R5(config-if)#do deb ppp auth PPP authentication debugging is on INE-R5(config-if)#int s0/0/0 INE-R5(config-if)#no shut INE-R5(config-if)# *Dec 3 18:51:53.163: %LINK-3-UPDOWN: Interface Serial0/0/0, changed state to up *Dec 3 18:51:53.171: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up *Dec 3 18:51:53.171: Vi2 PPP: Using default call direction *Dec 3 18:51:53.171: Vi2 PPP: Treating connection as a dedicated line *Dec 3 18:51:53.171: Vi2 PPP: Session handle[3E00009B] Session id[150] *Dec 3 18:51:53.171: Vi2 PPP: Authorization required *Dec 3 18:51:54.163: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0, changed state to up *Dec 3 18:52:04.635: Vi2 PPP: No authorization without authentication *Dec 3 18:52:04.647: Vi2 CHAP: I CHALLENGE id 141 len 27 from "INE-R3" *Dec 3 18:52:04.647: Vi2 CHAP: Using hostname from interface CHAP *Dec 3 18:52:04.647: Vi2 CHAP: Using password from interface CHAP *Dec 3 18:52:04.647: Vi2 CHAP: O RESPONSE id 141 len 30 from "INE-rocks" *Dec 3 18:52:04.663: Vi2 CHAP: I SUCCESS id 141 len 4 *Dec 3 18:52:04.663: %FR-3-MLPOFR_ERROR: MLPoFR not configured properly on Link Virtual-Access2 Bundle Multilink53 :Frame Relay traffic shaping must be enabled *Dec 3 18:52:04.671: %LINK-3-UPDOWN: Interface Multilink53, changed state to up *Dec 3 18:52:05.663: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up *Dec 3 18:52:05.671: %LINEPROTO-5-UPDOWN: Line protocol on Interface Multilink53, changed state to up INE-R5(config-if)#So a couple of things here. In case you didn’t notice, I deliberately changed the capitalization of INE-Rocks (on R3) to INE-rocks (on R5), and we came up regardless. Not all versions of IOS work this way with CHAP!
In addition, our configuration on the multilink interface worked just fine. Notice in the debug output all of the “I” and “O” messages. These are Incoming and Outgoing messages. So we can see what’s going on and which order it occurs.
Cool. ONE way is done. Now, the other way. We want to use a DIFFERENT secure authentication protocol now. Do we have Super-CHAP?
INE-R5(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) INE-R5(config-if)#Well, I’d probably argue that MS-CHAP and MS-CHAPv2 are not significantly “different” from CHAP to meet the need of the task. That leaves us EAP. How’s that work anyway?
While PAP and CHAP are in the Dial Technologies Configuration Guide – PPP Configuration – Configuring Media-Independent PPP and Multilnk PPP section, EAP is not. EAP can be found in the Security Configuration Guide: Securing User Services – Authentication, Authorization and Accounting – Authentication – RADIUS EAP Support. Go figure.
R5 is going to be the server here, so we’ll configure the client side first (no interruption that way).
R3
interface virtual-template 35
ppp eap identity INE-R3
ppp eap password CISCO
There is no default hostname used in EAP like there would be in CHAP, so even though we thought we’d get off easy, it’s still a configuration task! Now we can go get things moving on R5 though!
R5
username INE-R3 password CISCO
interface multilink 53
ppp eap local
ppp authentication eap
And we still have our debug running, so we should be good to go!
INE-R5(config-if)# *Dec 3 19:04:24.047: Vi2 PPP: Authorization required *Dec 3 19:04:24.055: %LINK-3-UPDOWN: Interface Multilink53, changed state to down *Dec 3 19:04:25.047: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to down *Dec 3 19:04:25.055: %LINEPROTO-5-UPDOWN: Line protocol on Interface Multilink53, changed state to down *Dec 3 19:04:28.079: Vi2 EAP: O REQUEST IDENTITY id 1 len 5 *Dec 3 19:04:28.091: Vi2 CHAP: I CHALLENGE id 143 len 27 from "INE-R3" *Dec 3 19:04:28.091: Vi2 EAP: I RESPONSE IDENTITY id 1 len 11 from "INE-R3" *Dec 3 19:04:28.091: Vi2 EAP: O REQUEST MD5 id 2 len 28 from "INE-R5" *Dec 3 19:04:28.091: Vi2 CHAP: Using hostname from interface CHAP *Dec 3 19:04:28.091: Vi2 CHAP: Using password from AAA *Dec 3 19:04:28.095: Vi2 CHAP: O RESPONSE id 143 len 30 from "INE-rocks" *Dec 3 19:04:28.103: Vi2 EAP: I RESPONSE MD5 id 2 len 28 from "INE-R3" *Dec 3 19:04:28.107: Vi2 PPP: Sent CHAP LOGIN Request *Dec 3 19:04:28.107: Vi2 PPP: Received LOGIN Response PASS *Dec 3 19:04:28.107: Vi2 CHAP: I SUCCESS id 143 len 4 *Dec 3 19:04:28.107: Vi2 PPP: Sent LCP AUTHOR Request *Dec 3 19:04:28.111: Vi2 PPP: Sent MLP AUTHOR Request *Dec 3 19:04:28.111: Vi2 LCP: Received AAA AUTHOR Response PASS *Dec 3 19:04:28.111: Vi2 MLP: Received AAA AUTHOR Response PASS *Dec 3 19:04:28.111: Vi2 EAP: O SUCCESS id 2 len 4 *Dec 3 19:04:28.115: %FR-3-MLPOFR_ERROR: MLPoFR not configured properly on Link Virtual-Access2 Bundle Multilink53 :Frame Relay traffic shaping must be enabled *Dec 3 19:04:28.123: %LINK-3-UPDOWN: Interface Multilink53, changed state to up *Dec 3 19:04:28.123: Mu53 PPP: Sent IPCP AUTHOR Request *Dec 3 19:04:28.123: Mu53 PPP: Sent CDPCP AUTHOR Request *Dec 3 19:04:28.127: Mu53 IPCP: Received AAA AUTHOR Response PASS *Dec 3 19:04:28.127: Mu53 CDPCP: Received AAA AUTHOR Response PASS *Dec 3 19:04:28.135: Mu53 PPP: Sent IPCP AUTHOR Request *Dec 3 19:04:29.111: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up *Dec 3 19:04:29.123: %LINEPROTO-5-UPDOWN: Line protocol on Interface Multilink53, changed state to up INE-R5(config-if)#Yup, lots of output there. And we’ll have to sort through it a little to pull apart the CHAP parts versus the EAP parts! But it works! And as a note, we need that “ppp eap local” to tell the router to use the local authentication database (username commands). Otherwise EAP as a specification requires RADIUS.
INE-R5(config-if)#do ping 173.100.0.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 173.100.0.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 28/30/32 ms INE-R5(config-if)#do ping 173.100.0.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 173.100.0.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/60/60 ms INE-R5(config-if)#Hey, look at that! I can still ping the other side and myself. And we’re doing it authenticated now! CHAP one way, and EAP the other.
Cool, huh? That’s likely as complicated an authentication scenario that we’d run across in the CCIE R&S lab. One last thing to point out. If you have trouble with your authentication coming up, but your configuration looks good… It’s most likely a password error. Even if you don’t SEE the problem. If you tend to go through configurations using the “?” often, whenever you get to the end of a link and see ““, you generally do exactly that, and hit Enter! However, the trailing space just became part of your line.
Most of the time this isn’t a problem, except where names are involved. Names like passwords, or key-string names or other obnoxious things like that! So write your config in notepad then, kill it from the router and re-paste it into both sides with the password WITHOUT a space. All should be good then!
Happy Configuring!
0 comments:
Post a Comment