Troubleshooting PPP Internet Connection On A Cisco Router

The Point-to-Point Protocol is one of the most popular protocols around used by engineers, ISPs and companies around the globe for authentication of remote users & router equipment.

The most common application of PPP is your ISP dialup account, whether it be ADSL, ISDN or even the good old analog modems - PPP is found in all of these connectivity methods.

PPP is a non-proprietary protocol, which also explains its wide adoption by vendors around the world.

Example Scenario

In this example, we'll be dealing with the PPP connection to our ISP. We are using a Cisco 2811 ISR router equipped with an HWIC-ADSLI card, which means we are connecting via ADSL and therefore using a virtual Dialer interface configured with our ISP account.

We will examine how to verify the connection to our ISP account and explain the steps that should be followed in case we are unable to connect. There are many reasons why a router might not be able to log in to the ISP account so we will cover the most common problems, which include: Incorrect username, incorrect password, invalid IP address & invalid authentication configuration.

Troubleshooting these possibilities will provide you with enough experience and information to help you deal with other similar problems that can occur during the ppp negotiation process.

Remember, the goal here is to cover these problematic cases, but most importantly - gear you up with enough experience and troubleshooting skills to help you tackle similar situations.

PPP Authentication - Incorrect Username or Password

This is a typical errors. You've mismatched the username and password, therefore unable to connect to the ISP account.

Under normal operation, you wouldn't be able to detect that your router is unable to connect to your ISP account. The results (e.g no Internet connection) will surely start making you wonder and start searching until you find out what's happening.

A quick check on the Dialer0 interface will confirm that there is a problem, as you notice there is no IP address assigned to it:

To check whether there is an issue with the ISP account and get a deeper insight to the source of the problem, issue the following debug command:

This debugging provides quite a bit of information during the authentication process and we've only included a portion of it. We don't want to analyse everything here, because later on we will deal with all this information without choice :)

In our lab, we've deliberately set an incorrect password to force these errors, and unfortunately the ISP response is not being specific on where the problem is. The response 'user unknown' tells us that either our username, This email address is being protected from spambots. You need JavaScript enabled to view it., or password is incorrect.

At this point, we at least know one of the two is causing the problem.

You can check your username by viewing the dialer configuration and try re-inserting your password, just in case you mistyped it the first time. If this gives the same result, then obviously the account credentials you've got are incorrect.

Thankfully most ISPs have a customer web-portal that allows them to log into their account and change usernames and passwords. If you've got this capability, use it. If not, a quick call to your ISP will prove most useful.

Lastly, if you would like to check you have inserted the correct account password, under your dialer interface, copy the type 7 password value from the dialer configuration:

Next, visit our Cisco Type 7 Password Decrypt / Decoder / Cracker Tool and insert the hashed password so it can reveal it:

Incorrect Configured IP Address on Dialer Interface

In many cases, engineers might select to statically configure the static IP address, purchased from the ISP, directly on the dialer interface. If all settings are correct and the ISP has provided the correct IP address you should expect no surprises.

It happens many times though, that the incorrect IP address has been provided and when the router authenticates to the ISP it is unable to route any packets towards the Internet.

The short and effective way around this problem is to never assign any IP address to the Dialer interface unless it's required. Services such as Crypto VPN tunnels to remote offices, various Internet services served to the Public (mail, web etc.) do not usually require you to configure the statically assigned IP address directly to the Dialer interface.

Allowing the ISP take care of the IP address assignment to your Dialer interface will in many cases help you avoid these problems completely.

For the purpose of our example, assuming we've got an incorrect IP address configured, following is the repeated behaviour we would encounter:

The router will continuously install and remove the default route provided by the ISP. The Virtual-Access interface is then shutdown and brought back up. This behavior will continue non-stop until you either shutdown the Dialer interface or correct the problem.

Changing our tactic, we decide to correct this problem and let the Dialer interface negotiate the IP address from our ISP:

On the next cycle of negotiation, the Dialer interface is assigned its IP address:

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:

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:

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:

Of course, if your ISP supports CHAP, you can safely remove all references to the PAP authentication method.

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.