Wednesday, January 30, 2013

Invalid Authentication Configuration

Invalid Authentication Configuration
 
Another common configuration problem is the ppp authentication direction, where your router should only authenticate to your ISP and not expect the ISP to authenticate to it as well.
 
The typical ppp authentication command under the dialer interface provides a number of supported authentication protocols (pap, chap, ms-chap, ms-chap-v2) but also allows you to control which way the authentication occurs:
 
  • R1(config-if)# ppp authentication chap ?
  • ....WORD ..... ..Use an authentication list with this name
  • ....callback .....Authenticate remote on callback only
  • ....callin .........Authenticate remote on incoming call only
  • ....callout .......Authenticate remote on outgoing call only
  • ....default .......Use the default authentication list
  • ....eap........... Extensible Authentication Protocol (EAP)
  • ....ms-chap ....Microsoft Challenge Handshake Authentication Protocol
  • ....ms-chap-v2 Microsoft CHAP Version 2 (MS-CHAP-V2)
  • ....one-time ....Allow use of username*OTP for one-time passwords
  • ....optional .....Allow peer to refuse to authenticate
  • ....pap ...........Password Authentication Protocol (PAP)
  • ....<cr>
 
Notice the 'callin' option in the above output. This option is almost always used and effectively tells the router not to expect the peer router (ISP) to authenticate back (to local router).
 
Here is the debugging output when we configure the ppp authentication method without the 'callin' parameter:
 
*Apr 26 01:16:07.647: Vi3 PPP: Outbound ip packet dropped
*Apr 26 01:16:07.651: Vi3 PPP: Outbound ip packet dropped
*Apr 26 01:16:07.651: Vi3 LCP: I CONFREJ [ACKsent] id 204 len 9
*Apr 26 01:16:07.651: Vi3 LCP: AuthProto CHAP (0x0305C22305)
*Apr 26 01:16:07.651: Vi3 LCP: O CONFREQ [ACKsent] id 205 len 15
*Apr 26 01:16:07.651: Vi3 LCP: AuthProto CHAP (0x0305C22305)
*Apr 26 01:16:07.651: Vi3 LCP: MagicNumber 0x1E7F0974 (0x05061E7F0974)
*Apr 26 01:16:08.347: Vi3 LCP: I CONFREJ [ACKsent] id 205 len 9
*Apr 26 01:16:08.347: Vi3 LCP: AuthProto CHAP (0x0305C22305)
*Apr 26 01:16:08.347: Vi3 LCP: Failed to negotiate with peer
*Apr 26 01:16:08.347: Vi3 PPP: Sending Acct Event[Down] id[2D]
*Apr 26 01:16:08.347: Vi3 LCP: O TERMREQ [ACKsent] id 206 len 4
*Apr 26 01:16:08.347: Vi3 PPP: Phase is TERMINATING
*Apr 26 01:16:08.387: Vi3 LCP: I TERMACK [TERMsent] id 206 len 4
*Apr 26 01:16:08.387: Vi3 LCP: State is Closed
*Apr 26 01:16:08.387: Vi3 PPP: Phase is DOWN
*Apr 26 01:16:08.387: Vi3 PPP: Phase is ESTABLISHING, Passive Open
*Apr 26 01:16:08.387: Vi3 LCP: State is Listen
*Apr 26 01:16:08.387: Vi3 PPP: Outbound ip packet dropped
*Apr 26 01:16:08.391: Vi3 PPP: Outbound ip packet dropped
*Apr 26 01:16:08.391: Vi3 PPP: Outbound ip packet dropped
*Apr 26 01:16:09.111: Vi3 PPP: Outbound cdp packet dropped
*Apr 26 01:16:10.547: Vi3 LCP: Timeout: State Listen
*Apr 26 01:16:10.547: Vi3 PPP: Authorization NOT required
*Apr 26 01:16:10.547: Vi3 LCP: O CONFREQ [Listen] id 207 len 15
*Apr 26 01:16:10.547: Vi3 LCP: AuthProto CHAP (0x0305C22305)
 
So always ensure that you add the 'callin' parameter at the end of the 'ppp authentication' command.
 
Further analysing the authentication protocol, generally all ISPs support CHAP primarily and PAP as a secondary option. However, due to the large amount of security breaches on accounts, PAP support is being dropped as it sends all account details in clear text, without any type of encryption.
 
CHAP authentication on the other hand sends a hashed result of the stored password. The router sends its hashed result to the ISP so it may compare it. If the calculated hash is identical to the one received by the ISP router, that means the password stored by each matches the other.
 
Following is the recommended ppp authentication options for most ISPs:
 
ppp chap hostname firewallcx@otenet.gr password
 
Of course, if your ISP supports CHAP, you can safely remove all references to the PAP authentication method.
Article Summary
 
This article showed you how to configure and troubleshoot your PPP connection on your Cisco router. We covered the most common problems found in PPP connections, how to identify them and successfully resolve them and also provided general information about PPP which can be used to troubleshoot other similar scenarios.
 
If you have found the article useful, we would really appreciate you sharing it with others by using the provided services on the top left corner of this article. Sharing our articles takes only a minute of your time and helps Firewall.cx reach more people through such services.
 
 
 

No comments:

Post a Comment