04-13-2004 04:04 AM - edited 03-02-2019 02:57 PM
Hi,
I've an architecture in which remote site flows (ex: 1701, 1721) are collected by a central LNS.
The LNS can renegociate the PPP session on mismatch and it's my case when doing Multilink (NAS are 3COM)
The soucy is when the re-negociation occurs. The LNS is configured to accept chap and pap (in this order).
My remote site is configured to negotiate only pap as the NAS is configured with it ("ppp authentication pap" on the dialer).
When the LNS renegociates the PPP session, it's first trying "CHAP", but the remote site isntead of sending a "CONFNACK -- Authentication CHAP" to make the LNS switches on PAP, it's sending a "CONFACK -- CHAP"....so the LNS sends a chap challenge and the remote site is blocked (as it's configured only for PAP) and no connexion occurs.
Having tested it on 1701 (3 IOS), 1721 and 3725, all these remote site "modem-router" have the same behavior. They send a "CONFACK" instead of "CONFNACK"
Having tested on other equipment (bintech), their behavior is OK, they send a CONFNACK, the LNS switches on PAP and the connexion is done.
Does anybody having an idea on the reason of these behavior ?
thanks in advance
04-13-2004 01:12 PM
What you are seeing is how its supposed to be.
Basically, "ppp authentication" command determines what we insist the peer authenticate with us. So with "ppp authen pap" on dialer routers, it does not mean that we would not recognize chap coming into us from the other side at all. We sure will. So what you need in your situation is "ppp chap refuse" in addition to "ppp authen pap" on the dialer routers.
~Zulfi
04-14-2004 04:16 AM
Hi,
Do you have any links which clearly explains the behavior of the router with "ppp authentication" command?
I've checked on the site but find nothing.
thanks in advance
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide