From: Brian Dennis (bdennis@internetworkexpert.com)
Date: Sun Apr 17 2005 - 14:23:51 GMT-3
I would recommend that you try the "callin" option out. I can tell you
from experience that the documentation isn't 100% correct.
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
bdennis@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 775-745-6404 (Outside the US and Canada)
-----Original Message-----
From: Linkova, Evgenia [mailto:jen@amt.ru]
Sent: Sunday, April 17, 2005 4:40 AM
To: Brian Dennis
Cc: ccielab@groupstudy.com
Subject: RE: PPP authentication very stupid question ;-)
Hi!
> A good portion of the CCIE lab is a lot of simple tasks
> put together to make a larger complicated task. You need to
> be able to break these complicated tasks apart so that not
> only will it be easier to configure but it will make it
> easier for verification and troubleshooting.
>
> So let's just take the complicated task you have and
> break it down into simpler tasks (steps).
Wow ;-) Very good explanation ;-)
> <Task>
> R4 should authenticate R5 using chap, but should refuse to be
> authenticated via CHAP or PAP. R5 should attempt to
> authenticate R4 via CHAP and PAP, but allow peer to refuse
> authentication.
> </Task>
>
> ****************************************************
>
> Step 1:
> R4 should authenticate R5 using chap
>
> Solution to Step 1:
> R4 & R5 - encapsulation ppp
> R4 - ppp authentication chap
>
> ****************************************************
>
> Step 2:
> but should refuse to be authenticated via CHAP or PAP
>
> Solution to Step 2:
> R4 - ppp chap refuse
> R4 - ppp pap refuse
Hm..But why you don't use "callin" options?
I've read "Understanding and Configuring PPP CHAP Authentication" from
www.cisco.com
(http://www.cisco.com/en/US/partner/tech/tk713/tk507/technologies_tech_n
ote09186a00800b4131.shtml):
ppp chap refuse [callin]
This command disables remote authentication by a peer (default
enabled). With this command, CHAP authentication is disabled for all
calls, which means that all attempts by the peer to force the user to
authenticate with the help of CHAP are refused.
The callin option specifies that the router refuses to answer CHAP
authentication challenges received from the peer, but still requires the
peer to answer any CHAP challenges that the router sends.
If I'm not mistaken, with "ppp chap refuse" R4 will not send CHAP
challenge to R5 and will not answer to R% challenge. So, R4 will not
authenticate or be authenticated.
And with "callin" option R4 will authenticate R5, but will not be
authenticated by R5.
Am I right? Because task requirement is "R4 should authenticate R5
using chap, but should refuse to be authenticated via CHAP or PAP" I
suppose "callin" should be used, shouldn't it?
Sorry if my question is so silly, I'm overloaded with information a
little bit ;-)
=====
SY, Jen Linkova
AMT Group
Phone: +7 095 725 7660
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> Behalf Of Linkova, Evgenia
> Sent: Saturday, April 16, 2005 11:27 AM
> To: security@groupstudy.com
> Subject: PPP authentication very stupid question ;-)
>
> Hi All!
>
> I have to configure ISDN DDR between two routers (assume R4
> with dialer profile and R5 with legacy DDR).
> R4 should authenticate R5 using chap, but should refuse to be
> authenticated via CHAP or PAP. R5 should attemp to
> authenticate R4 via CHAP and PAP, but allow peer to refuse
> authentication.
>
> So, I create folowing configuration:
> R4:
> username R5-CHAP password 0 CHAP-PW
> interface BRI0/0
> no ip address
> encapsulation ppp
> dialer pool-member 14
> isdn switch-type basic-net3
> ppp authentication chap
>
> interface Dialer128
> ip address 174.14.45.4 255.255.255.0
> encapsulation ppp
> dialer pool 14
> dialer remote-name R5-CHAP
> dialer string 600
> dialer-group 128
> ppp authentication chap
> ppp chap refuse callin
> ppp pap refuse callin
>
> dialer-list 128 protocol ip permit
>
> R5:
> interface BRI0/0
> ip address 174.14.45.5 255.255.255.0
> encapsulation ppp
> dialer map ip 174.14.45.4 broadcast 602 dialer-group 128
> isdn switch-type basic-net3 ppp authentication chap pap
> optional ppp chap hostname R5-CHAP ppp chap password 0 CHAP-PW
>
> dialer-list 128 protocol ip permit
>
> AFAIK,
> ppp chap refuse callin
> ppp pap refuse callin
> Have to make R4 to refuse to be authenticated, but still
> allow authenticate peer. Am I right?
> But in debug messages I can see that R5 tries to authenticate R4 via
> CHAP:
> CCIE-R4#deb ppp authentication
> PPP authentication debugging is on
> CCIE-R4#ping 174.14.45.5
> <skip>
> *Mar 1 00:21:38.764: BR0/0:1 CHAP: I CHALLENGE id 36 len 28
> from "R5-CHAP"
> *Mar 1 00:21:38.768: BR0/0:1 CHAP: Using hostname from
> unknown source *Mar 1 00:21:38.768: BR0/0:1 CHAP: Using
> password from AAA *Mar 1 00:21:38.768: BR0/0:1 CHAP: O
> RESPONSE id 36 len 28 from "CCIE-R4"
> *Mar 1 00:21:38.788: BR0/0:1 CHAP: I FAILURE id 36 len 26
> msg is "Authentication failure"
> <skip>
>
> And on R5:
> *Mar 1 03:03:13.941: BR0/0:1 PPP: Authorization required
> *Mar 1 03:03:13.953: BR0/0:1 CHAP: O CHALLENGE id 40 len 28
> from "R5-CHAP"
> *Mar 1 03:03:13.957: BR0/0:1 CHAP: I CHALLENGE id 17 len 28
> from "CCIE-R4"
> *Mar 1 03:03:13.957: BR0/0:1 CHAP: Waiting for Peer to
> authenticate first *Mar 1 03:03:13.973: BR0/0:1 CHAP: I
> RESPONSE id 40 len 28 from "CCIE-R4"
> *Mar 1 03:03:13.977: BR0/0:1 PPP: Sent CHAP LOGIN Request to
> AAA *Mar 1 03:03:13.977: BR0/0:1 PPP: Received LOGIN
> Response from AAA = FAIL *Mar 1 03:03:13.977: BR0/0:1 CHAP:
> O FAILURE id 40 len 26 msg is "Authentication failure"
>
> If I change authentication method on R5 to "ppp
> authentication chap callout" and try to make a call to R5 (or
> "ppp authentication chap callin" and make a call from R5 to R4) - so
> R4 isn't authenticated by R5 - all works fine..
>
> What's wrong with my understanging of ppp authentication? Or
> with my configs? ;-)
>
> =====
> SY, Jen Linkova
> AMT Group
> Phone: +7 095 725 7660
This archive was generated by hypermail 2.1.4 : Tue May 03 2005 - 07:54:59 GMT-3