Problem on negociation of PPP authentication

[valtazou]

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

[zahmed]

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

[valtazou]

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