Troubleshooting PPTP

In previous sections in this chapter, the underlying theory of PPTP operation and its configuration were discussed. As you begin to troubleshoot PPTP, this accumulated knowledge will prove very useful.

This section goes through troubleshooting PPTP end-to-end from the remote access client/PNS to the PAC.

The flowchart in Figure 3-25 describes the troubleshooting process used with PPTP. You can use this flowchart to quickly access the section of the chapter relevant to problems you are experiencing on your network.

Figure 3-25. PPTP Troubleshooting Flowchart

[View full size image]

Note that the remote access client/PNS used in this chapter is a Microsoft Windows 2000 workstation. Client implementations are available for a wide variety of operating systems, including Windows, FreeBSD, Linux, and MacOS X. Windows 2000 is used only for illustrative purposes.

Before getting down to the nuts and bolts of troubleshooting itself, it is worthwhile to restate the sequence of events necessary to successfully complete a PPTP connection between the remote access client/PNS and the PAC:

Figure 3-26 summarizes the PPTP tunnel setup sequence.

Now that you have been reminded of the overall model for successful PPTP tunnel negotiation, you can examine some of the problems that could potentially result in a PPTP tunnel failure.

Together, Figure 3-27 and Table 3-4 illustrate some of these potential issues.

Note that many of the potential problems do not directly relate to configuration of PPTP on the PAC but are provided in Figure 3-27 and Table 3-4 for illustrative purposes only.

In the next few sections, potential PPTP issues are examined, together with their solutions, using an end-to-end troubleshooting methodology.

Control Connection and Call Session Establishment Failure

As can be seen from the summary of PPTP tunnel establishment in the previous section (Figure 3-26), the first thing that the remote access client/PNS must do to establish a PPTP tunnel is to set up a control connection to the PAC. Once the control connection has been set up, the call session can be established.

Figure 3-28 illustrates control connection and call session setup.

A number of issues can cause a control connection failure, among them the following:

• A basic IP connectivity failure. To troubleshoot this issue, simply attempt to ping the PAC from the remote access client/PNS. Also, ensure that an access list or firewall is not blocking TCP port 1723 (used by control channel packets).

  The error reported by Microsoft remote access client/PNSs in the event of a connectivity failure is as follows: Error 678: There was no answer.

• A tunnel (VPDN) protocol mismatch.

PPTP is not the only tunnel protocol that can be used to establish voluntary tunnel mode connectivity between a remote access client workstation and a Cisco router. An alternative is the L2TP. Therefore, it is possible for there to be a mismatch of tunnel protocols between the remote access client and the PAC.

Before troubleshooting this scenario, it is useful to examine an example of successful PPTP control connection and session establishment. To determine whether PPTP control messages are being received on the PAC, use the debug vpdn l2x-packets command. Note that if you are terminating a large number of PPTP tunnels on the PAC, this command may produce a large amount of output. In this case, the debug vpdn l2x-events and debug vpdn l2x-errors commands may be better alternatives.

Examples 3-6 to 3-8 show a successful control connection and session establishment between the remote access client/PNS and the PAC.

Example 3-6. Successful Control Connection and Session Setup

Arizona_PAC#debug vpdn l2x-packets
L2X control packets debugging is on
Arizona_PAC#
Jan 20 10:29:16.075 UTC: Tnl 13 PPTP: I
  009C00011A2B3C4D0001000001000000000000010000...
Jan 20 10:29:16.075 UTC: Tnl 13 PPTP: I SCCRQ
Jan 20 10:29:16.075 UTC: Tnl 13 PPTP: protocol version 100
Jan 20 10:29:16.075 UTC: Tnl 13 PPTP: framing caps 1
Jan 20 10:29:16.075 UTC: Tnl 13 PPTP: bearer caps 1
Jan 20 10:29:16.075 UTC: Tnl 13 PPTP: max channels 0
Jan 20 10:29:16.075 UTC: Tnl 13 PPTP: firmware rev 870
Jan 20 10:29:16.075 UTC: Tnl 13 PPTP: hostname ""
Jan 20 10:29:16.075 UTC: Tnl 13 PPTP: vendor "Microsoft Windows NT"
Jan 20 10:29:16.075 UTC: Tnl 13 PPTP: O SCCRP
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: I
  00A800011A2B3C4D00070000400045450000012C05F5...

Highlighted line 1 (Example 3-6) shows an incoming (I) SCCRQ message from the remote access client/PNS. Note that the line above this shows the raw data in the packet.

The following seven lines of output detail the contents (fields) of this message. Of particular interest is the Vendor field, which indicates that the remote access client/PNS is a Windows NT workstation.

Note also that the Framing and Bearer Capabilities fields are both set to a value of 1, indicating asynchronous framing and analog access support. These are simply defaults and may not in fact reflect true connectivity.

In highlighted line 2, the PAC responds to the SCCRQ by sending a SCCRP message to the remote access client/PNS. Notice that this message is outgoing (indicated by the O).

The PPTP control connection has now been set up between the remote access client/PNS and the PAC.

For more information about the fields contained within the SCCRQ and SCCRP messages, see the section entitled “PPTP Control Channel Setup” earlier in chapter.

PPTP session setup now begins, as shown in Example 3-7.

Example 3-7. Session Setup Begins

						Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: CC I OCRQ
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: call id 16384
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: serial num 17733
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: min bps 300
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: max bps 100000000
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: bearer type 3
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: framing type 3
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: recv win size 64
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: ppd 0
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: phone num len 0
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: phone num ""
Jan 20 10:29:16.095 UTC: Vi1 Tnl/Cl 13/13 PPTP: CC O OCRP
						Jan 20 10:29:16.099 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
						to up
Jan 20 10:29:16.099 UTC: Tnl 13 PPTP: I
  001800011A2B3C4D000F0000000D0000FFFFFFFFFFFFFFFF

In highlighted line 1 (Example 3-7), the PAC receives an OCRQ message. Note that the CC in the line PPTP: CC I OCRQ indicates that this message is received on the control connection (via TCP).

Below the highlighted line, fields in the OCRQ message are detailed. Note the Call-ID—this is used by the remote access client/PNS to identify the particular session within the overall tunnel, although there will be only one session because this is voluntary tunnel mode.

Other fields to note are the Bearer and Framing fields, both of which show a value of 3. This indicates that any kind of bearer and framing is acceptable. Note also that the phone num (phone number) field is blank; obviously, the remote access client/PNS is not really requesting the PAC to make an outgoing call in this case.

Highlighted line 2 shows the PAC responding with an OCRP message. The configuration from the virtual template is then cloned to virtual access interface 1, and the interface changes state to up. The PPTP session is now established.

For more information on the PPTP session setup, see the section entitled “PPTP Session Establishment” at the beginning of this chapter.

Two more control connection messages are then sent by the remote access client/PNS to the PAC, as shown in Example 3-8.

Example 3-8. The Remote Access Client/PNS Sends Two SLIs

						Jan 20 10:29:16.099 UTC: Vi1 Tnl/Cl 13/13 PPTP: CC I SLI
Jan 20 10:29:16.107 UTC: Vi1 PPTP: I, payload length 19
Jan 20 10:29:18.099 UTC: Vi1 PPTP: I, payload length 19
Jan 20 10:29:18.099 UTC: Vi1 PPTP: I, payload length 48
Jan 20 10:29:18.099 UTC: Vi1 PPTP: I, payload length 41
Jan 20 10:29:18.103 UTC: Vi1 PPTP: I, payload length 22
Jan 20 10:29:18.103 UTC: Vi1 PPTP: I, payload length 29
Jan 20 10:29:18.103 UTC: Vi1 PPTP: I, payload length 66
Jan 20 10:29:18.103 UTC: Tnl 13 PPTP: I
  001800011A2B3C4D000F0000000D00000000000000000000
Jan 20 10:29:18.103 UTC: Vi1 Tnl/Cl 13/13 PPTP: CC I SLI
Jan 20 10:29:18.127 UTC: Vi1 PPTP: I, payload length 14
Jan 20 10:29:18.127 UTC: Vi1 PPTP: I, payload length 38
Jan 20 10:29:18.127 UTC: Vi1 PPTP: I, payload length 14
Jan 20 10:29:18.127 UTC: Vi1 PPTP: I, payload length 14
Jan 20 10:29:18.131 UTC: Vi1 PPTP: I, payload length 14
Jan 20 10:29:18.131 UTC: Vi1 PPTP: I, payload length 26
Jan 20 10:29:18.135 UTC: Vi1 PPTP: I, payload length 26
Jan 20 10:29:18.247 UTC: Vi1 PPTP: I, payload length 104
Jan 20 10:29:18.251 UTC: Vi1 PPTP: I, payload length 40
Jan 20 10:29:18.251 UTC: Vi1 PPTP: I, payload length 60
Jan 20 10:29:18.911 UTC: Vi1 PPTP: I, payload length 104
Jan 20 10:29:19.123 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
						Virtual-Access1, changed state to up
Arizona_PAC#

In highlighted lines 1 and 2 (Example 3-8), the PAC receives SLI messages from the remote access client/PNS. Finally, in highlighted line 3, the line protocol on interface virtual access 1 changes state to up. The remote access client/PNS has successful connected to the PAC.

Having seen what happens if tunnel setup is successful, you can have a look at some debug output where tunnel setup is not so successful. Once again, the debug vpdn l2x-packets command is used to monitor control channel and session setup on the PNS.

Example 3-9 shows the output resulting when there is a tunnel protocol mismatch between the remote access client/PNS and the PAC.

Example 3-9. Control Connection Setup Fails

Arizona_PAC#debug vpdn l2x-packets
L2X control packets debugging is on
Arizona_PAC#
Jan 20 10:30:30.083 UTC: L2X: Parse  AVP 0, len 8, flag 0x8000 (M)
Jan 20 10:30:30.083 UTC: L2X: Parse SCCRQ
Jan 20 10:30:30.083 UTC: L2X: Parse  AVP 2, len 8, flag 0x8000 (M)
Jan 20 10:30:30.083 UTC: L2X: Protocol Ver 256
Jan 20 10:30:30.083 UTC: L2X: Parse  AVP 3, len 10, flag 0x8000 (M)
Jan 20 10:30:30.083 UTC: L2X: Framing Cap 0x1
Jan 20 10:30:30.083 UTC: L2X: Parse  AVP 4, len 10, flag 0x8000 (M)
Jan 20 10:30:30.083 UTC: L2X: Bearer Cap 0x0
Jan 20 10:30:30.083 UTC: L2X: Parse  AVP 6, len 8, flag 0x0
Jan 20 10:30:30.083 UTC: L2X: Firmware Ver 0x500
Jan 20 10:30:30.083 UTC: L2X: Parse  AVP 7, len 15, flag 0x8000 (M)
Jan 20 10:30:30.083 UTC: L2X: Hostname mlewis
Jan 20 10:30:30.083 UTC: L2X: Parse  AVP 8, len 15, flag 0x0
Jan 20 10:30:30.083 UTC: L2X: Vendor Name Microsoft
Jan 20 10:30:30.087 UTC: L2X: Parse  AVP 9, len 8, flag 0x8000 (M)
Jan 20 10:30:30.087 UTC: L2X: Assigned Tunnel ID 2
Jan 20 10:30:30.087 UTC: L2X: Parse  AVP 10, len 8, flag 0x8000 (M)
Jan 20 10:30:30.087 UTC: L2X: Rx Window Size 8
Jan 20 10:30:30.087 UTC: L2X: No missing AVPs in SCCRQ
Jan 20 10:30:30.087 UTC: L2X: I SCCRQ, flg TLS, ver 2, len 102, tnl 0, cl 0, ns 0,
  nr 0
     C8 02 00 66 00 00 00 00 00 00 00 00 80 08 00 00
     00 00 00 01 80 08 00 00 00 02 01 00 80 0A 00 00
     00 03 00 00 00 01 80 0A 00 00 00 04 00 00 00 ...
Jan 20 10:30:30.087 UTC: L2TP: I SCCRQ from mlewis tnl 2
Jan 20 10:30:31.075 UTC: L2X: Parse  AVP 0, len 8, flag 0x8000 (M)
Jan 20 10:30:31.075 UTC: L2X: Parse SCCRQ
Jan 20 10:30:31.075 UTC: L2X: Parse  AVP 2, len 8, flag 0x8000 (M)
Jan 20 10:30:31.075 UTC: L2X: Protocol Ver 256
Jan 20 10:30:31.075 UTC: L2X: Parse  AVP 3, len 10, flag 0x8000 (M)
Jan 20 10:30:31.075 UTC: L2X: Framing Cap 0x1
Jan 20 10:30:31.075 UTC: L2X: Parse  AVP 4, len 10, flag 0x8000 (M)
Jan 20 10:30:31.075 UTC: L2X: Bearer Cap 0x0
Jan 20 10:30:31.075 UTC: L2X: Parse  AVP 6, len 8, flag 0x0
Jan 20 10:30:31.075 UTC: L2X: Firmware Ver 0x500
Jan 20 10:30:31.075 UTC: L2X: Parse  AVP 7, len 15, flag 0x8000 (M)
Jan 20 10:30:31.075 UTC: L2X: Hostname mlewis
Jan 20 10:30:31.079 UTC: L2X: Parse  AVP 8, len 15, flag 0x0
Jan 20 10:30:31.079 UTC: L2X: Vendor Name Microsoft
Jan 20 10:30:31.079 UTC: L2X: Parse  AVP 9, len 8, flag 0x8000 (M)
Jan 20 10:30:31.079 UTC: L2X: Assigned Tunnel ID 2
Jan 20 10:30:31.079 UTC: L2X: Parse  AVP 10, len 8, flag 0x8000 (M)
Jan 20 10:30:31.079 UTC: L2X: Rx Window Size 8
Jan 20 10:30:31.079 UTC: L2X: No missing AVPs in SCCRQ
Arizona_PAC#

In highlighted line 1, the PAC parses a SCCRQ from the remote access client/PNS. This seems OK, but then in highlighted line 2, if you look closely you can see that the SCCRQ is an L2TP SCCRQ.

“Hold on,” you might be thinking, “isn't the SCCRQ a PPTP message?” It is, but it is also a message type used in L2TP. This is no surprise, as L2TP incorporates the best features of both PPTP and L2F. Unfortunately, it is backward-compatible with neither.

At this point, it is interesting to note a fundamental difference in voluntary mode session setup between PPTP and L2TPv2. In PPTP, the remote access client sends an OCRQ to initiate session setup, and the router responds with an OCRP. In L2TPv2, on the other hand, the remote access client sends an L2TP Incoming-Call-Request (ICRQ), the router responds with an Incoming-Call-Reply (ICRP), and the session setup is completed when the remote access client sends an Incoming-Call-Connected (ICCN). PPTP also uses ICRQ, ICRP, and ICCN messages but only in compulsory tunnel mode. Interestingly, the first Microsoft L2TPv2 voluntary tunnel mode client also used outgoing call messages (in a very similar way to PPTP). But when Microsoft engineers arrived at an early vendor inter-operability test (called a bakeoff), they discovered that most other vendors had implemented voluntary tunnel mode in the opposite way (using incoming call messages), and so modified their client code to make it work in the same way as other vendor implementations. So, there's been a certain amount of confusion regarding PPTP and L2TPv2 voluntary tunnel mode, but it's really just terminological confusion (neither protocol is inhibited in operation).

To resolve this issue, the remote access client tunnel protocol needs to be reconfigured as PPTP. Once the remote access client is reconfigured (not shown), the PPTP tunnel is successfully established. This is verified using the show vpdn tunnel all command, as shown in Example 3-10.

Example 3-10. Verifying the PPTP Tunnel

Arizona_PAC#show vpdn tunnel all
%No active L2TP tunnels
%No active L2F tunnels
PPTP Tunnel Information Total tunnels 1 sessions 1
Tunnel id 14, 1 active sessions
  Tunnel state is estabd, time since change 00:00:28
  Remote tunnel name is
    Internet Address 172.16.1.2, port 2085
  Local tunnel name is Arizona_PAC
    Internet Address 10.10.10.100, port 1723
  16 packets sent, 54 received, 562 bytes sent, 5159 received
%No active PPPoE tunnels
Arizona_PAC#

As you can see from the output, one PPTP tunnel has been established, and within it one session (highlighted line 1).

Highlighted lines 2 and 3 show the remote access client/PNS's and PAC's IP addresses, together with the TCP ports used for control connection connectivity.

Note that the error reported by Microsoft remote access client/PNSs (Windows 2000) in the event of a tunnel protocol mismatch is as follows:

Error 678: There was no answer.

Virtual Access Interface Is Not Cloned

Once the PPTP tunnel and session have been established, the virtual access interface is cloned from the virtual template.

Use the debug vtemplate command to verify that the virtual access interface is correctly cloned from the virtual template as shown in Example 3-11.

Example 3-11. Virtual Access Interface Is Correctly Cloned

Arizona_PAC#debug vtemplate
Virtual Template debugging is on
Arizona_PAC#
*Aug 17 21:04:07.983 UTC: Vi1 VTEMPLATE: Reuse Vi1, recycle queue size 0
*Aug 17 21:04:07.983 UTC: Vi1 VTEMPLATE: Hardware address 00d0.6354.7000
*Aug 17 21:04:07.983 UTC: Vi1 VTEMPLATE: Has a new cloneblk vtemplate, now it has
  vtemplate
*Aug 17 21:04:07.983 UTC: Vi1 VTEMPLATE: ************* CLONE VACCESS1
  *****************
*Aug 17 21:04:07.983 UTC: Vi1 VTEMPLATE: Clone from Virtual-Template1
						interface Virtual-Access1
default ip address
no ip address
encap ppp
ip unnumbered Ethernet1/1
end
*Aug 17 21:04:08.003 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
						to up
						*Aug 17 21:04:11.027 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
						Virtual-Access1, changed state to up
Arizona_PAC#

In highlighted lines 1 and 2, configuration is copied from virtual template interface 1 to virtual access interface 1. The following four lines show the configuration copied to the virtual access interface. The virtual access interface and line protocol change state to up in highlighted lines 3 and 4. In this case, the virtual access interface has been successful cloned.

If the debug vtemplate command produces no output, verify that the virtual template is correctly referenced under the VPDN group using the show running-config command. This is shown in Example 3-12. Note that only the relevant portion of the output is shown.

Example 3-12. Verifying the VPDN Group

!
vpdn-group 1
! Default PPTP VPDN group
 accept-dialin
  protocol pptp
  virtual-template 1
!

In this example, the virtual template is correctly referenced under the VPDN group.

If you have user-specific configuration stored on a AAA server, be sure to verify this configuration as you troubleshoot PPP.

LCP Negotiation Failure

Once the virtual access interface has been cloned, PPP negotiation begins. PPP negotiation consists of LCP negotiation, PPP authentication, and NCP negotiation. This section examines what happens if LCP negotiation fails.

Authentication protocol mismatch is a common cause of LCP negotiation failure. For example, if the remote access client/PNS is configured to authenticate using only the Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), and the PAC is configured only for standard Message Digest 5 Challenge Handshake Authentication Protocol (MD5 CHAP), authentication protocol negotiation failure will occur.

Figure 3-29 illustrates LCP negotiation.

To begin with, it is worthwhile examining successful LCP negotiation (including the negotiation of authentication protocols). Use the debug ppp negotiation command to examine LCP negotiation between the remote access client/PNS and the PAC.

Examples 3-13 to 3-21 show a successful LCP negotiation sequence.

Example 3-13. Successful LCP Negotiation

Arizona_PAC#debug ppp negotiation
PPP protocol negotiation debugging is on
Arizona_PAC#
Jan 20 10:37:11.443 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
						to up
Jan 20 10:37:11.443 UTC: Vi1 PPP: Treating connection as a dedicated line
Jan 20 10:37:11.443 UTC: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load]
					

In the first highlighted line, virtual interface 1 changes state to up. This means that the control channel is established, and that OCRQ and OCRP messages have been exchanged. At this point, PPP phase changes to ESTABLISHING. LCP negotiation is about to begin.

In Example 3-14, the PAC sends an outgoing (O) Configure-Request (CONFREQ) to the remote access client/PNS. This is used to inform the remote access client/PNS of the LCP options that the PAC would like to use.

Example 3-14. PAC Sends a CONFREQ

						Jan 20 10:37:11.443 UTC: Vi1 LCP: O CONFREQ [Closed] id 41 len 15
Jan 20 10:37:11.443 UTC: Vi1 LCP:    AuthProto MS-CHAP (0x0305C22380)
Jan 20 10:37:11.443 UTC: Vi1 LCP:    MagicNumber 0xD091B3B6 (0x0506D091B3B6)

In Example 3-14, the CONFREQ includes two options: option 0x03, Authentication Protocol, and option 0x05, Magic Number. The authentication protocol specified is MS-CHAPv1 (0xC22380), and the Magic Number is 0xD091B3B6. Note that the Magic Number is random and is used to detect error conditions such as a looped back line.

It might be interesting to note the format of the options specified. The format is option type, length, and any associated data. The raw options are shown in brackets. The option type, length, and associated data format is common to PPP options.

An incoming (I) Configure-Ack (CONFACK) message is then received from the remote access client/PNS as demonstrated in Example 3-15. This is good news; it means that the remote access client/PNS has accepted the options sent in the initial CONFREQ message (Example 3-14). The accepted options are repeated in the CONFACK, as you can see.

Example 3-15. Remote Access Client/PNS Responds with a CONFACK

						Jan 20 10:37:11.451 UTC: Vi1 LCP: I CONFACK [REQsent] id 41 len 15
Jan 20 10:37:11.451 UTC: Vi1 LCP:    AuthProto MS-CHAP (0x0305C22380)
Jan 20 10:37:11.451 UTC: Vi1 LCP:    MagicNumber 0xD091B3B6 (0x0506D091B3B6)
Jan 20 10:37:13.443 UTC: Vi1 LCP: TIMEout: State ACKrcvd

In Example 3-16, the PAC sends another CONFREQ to the remote access client/PNS. This contains the same options as the first CONFREQ (see Example 3-14). This is sent because LCP timed out in Example 3-15 (see the final line in the output).

Example 3-16. PAC Sends Another CONFREQ

						Jan 20 10:37:13.443 UTC: Vi1 LCP: O CONFREQ [ACKrcvd] id 42 len 15
Jan 20 10:37:13.443 UTC: Vi1 LCP:    AuthProto MS-CHAP (0x0305C22380)
Jan 20 10:37:13.443 UTC: Vi1 LCP:    MagicNumber 0xD091B3B6 (0x0506D091B3B6)

The remote access client/PNS acknowledges the CONFREQ in Example 3-16 with a CONFACK, as shown in Example 3-17.

Example 3-17. Remote Access Client/PNS Sends a CONFACK

Jan 20 10:37:13.443 UTC: Vi1 LCP: I CONFACK [REQsent] id 42 len 15
Jan 20 10:37:13.443 UTC: Vi1 LCP:    AuthProto MS-CHAP (0x0305C22380)
Jan 20 10:37:13.443 UTC: Vi1 LCP:    MagicNumber 0xD091B3B6 (0x0506D091B3B6)

In Example 3-18, an incoming (I) CONFREQ is received from the remote access client/PNS. The options specified in the message are shown in the following eight lines.

Example 3-18. Remote Access Client/PNS Sends a CONFREQ

						Jan 20 10:37:13.451 UTC: Vi1 LCP: I CONFREQ [ACKrcvd] id 1 len 44
Jan 20 10:37:13.451 UTC: Vi1 LCP:    MagicNumber 0x75674EB0 (0x050675674EB0)
Jan 20 10:37:13.451 UTC: Vi1 LCP:    PFC (0x0702)
Jan 20 10:37:13.451 UTC: Vi1 LCP:    ACFC (0x0802)
Jan 20 10:37:13.451 UTC: Vi1 LCP:    Callback 6  (0x0D0306)
Jan 20 10:37:13.451 UTC: Vi1 LCP:    MRRU 1614 (0x1104064E)
Jan 20 10:37:13.451 UTC: Vi1 LCP:    EndpointDisc 1 Local
Jan 20 10:37:13.455 UTC: Vi1 LCP:     (0x1317011CCDA40A14674B1C963C4A1AC1)
Jan 20 10:37:13.455 UTC: Vi1 LCP:     (0x03DF730000000E)

The first option specified in the CONFREQ shown in Example 3-18 is another Magic Number, followed by Protocol Field Compression (PFC, LCP option 0x07). This indicates that the remote access client/PNS is capable of receiving compressed PPP protocol fields. The next option is Address and Control Field Compression (ACFC) (option 0x08). The inclusion of this option indicates that the remote access client/PNS would like to receive PPP frames without the leading HDLC Address and Control fields.

The final three options included are Callback (option 0x0D), Maximum-Reconstructed-Receive-Unit (MRRU) (option 0x11), and Endpoint-Discriminator (ED, option 0x13).

The Callback option is used by the end system to request that the system terminating the link call it back. MRRU and ED are both used in a Multilink PPP (MP) environment. Note that Callback and MP are not supported for PPTP on IOS routers.

The PAC now sends a Configure-Reject (CONFREJ) message, which is used to indicate to the remote access client/PNS that Callback and MRRU options are unacceptable or not understood. This CONFREJ message is shown in Example 3-19.

Example 3-19. PAC Rejects Callback and MRRU

						Jan 20 10:37:13.455 UTC: Vi1 LCP: O CONFREJ [ACKrcvd] id 1 len 11
Jan 20 10:37:13.455 UTC: Vi1 LCP:    Callback 6  (0x0D0306)
Jan 20 10:37:13.455 UTC: Vi1 LCP:    MRRU 1614 (0x1104064E)

Having received the CONFREJ, the remote access client/PNS now sends another CONFREQ, as shown in Example 3-20. This CONFREQ specifies all of the options included in its previous CONFREQ in Example 3-18 minus those rejected by the PAC in Example 3-19.

Example 3-20. Remote Access Client/PNS Sends a Second CONFREQ

						Jan 20 10:37:13.455 UTC: Vi1 LCP: I CONFREQ [ACKrcvd] id 2 len 37
Jan 20 10:37:13.455 UTC: Vi1 LCP:    MagicNumber 0x75674EB0 (0x050675674EB0)
Jan 20 10:37:13.455 UTC: Vi1 LCP:    PFC (0x0702)
Jan 20 10:37:13.455 UTC: Vi1 LCP:    ACFC (0x0802)
Jan 20 10:37:13.455 UTC: Vi1 LCP:    EndpointDisc 1 Local
Jan 20 10:37:13.455 UTC: Vi1 LCP:     (0x1317011CCDA40A14674B1C963C4A1AC1)
Jan 20 10:37:13.455 UTC: Vi1 LCP:     (0x03DF730000000E)

In Example 3-21, the PAC responds with a CONFACK.

Example 3-21. PAC Responds with a CONFACK

						Jan 20 10:37:13.455 UTC: Vi1 LCP: O CONFACK [ACKrcvd] id 2 len 37
Jan 20 10:37:13.455 UTC: Vi1 LCP:    MagicNumber 0x75674EB0 (0x050675674EB0)
Jan 20 10:37:13.455 UTC: Vi1 LCP:    PFC (0x0702)
Jan 20 10:37:13.455 UTC: Vi1 LCP:    ACFC (0x0802)
Jan 20 10:37:13.455 UTC: Vi1 LCP:    EndpointDisc 1 Local
Jan 20 10:37:13.455 UTC: Vi1 LCP:     (0x1317011CCDA40A14674B1C963C4A1AC1)
Jan 20 10:37:13.455 UTC: Vi1 LCP:     (0x03DF730000000E)
Jan 20 10:37:13.455 UTC: Vi1 LCP: State is Open
					

The CONFACK sent by the PAC (Example 3-21, highlighted line 1) serves to acknowledge and accept the options contained in the remote access client/PNS's last CONFREQ (Example 3-20). Finally, the LCP state changes to Open (highlighted line 2), and LCP negotiation is complete.

When LCP negotiation is not successful, the output of the debug ppp negotiation command is somewhat different.

Examples 3-22 to 3-24 show an unsuccessful LCP negotiation sequence.

Example 3-22. LCP Negotiation Is Unsuccessful

Arizona_PAC#debug ppp negotiation
PPP protocol negotiation debugging is on
Arizona_PAC#
Jan 20 10:39:50.247 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
						to up
Jan 20 10:39:50.247 UTC: Vi1 PPP: Treating connection as a dedicated line
Jan 20 10:39:50.247 UTC: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load]
						Jan 20 10:39:50.247 UTC: Vi1 LCP: O CONFREQ [Closed] id 49 len 15
Jan 20 10:39:50.247 UTC: Vi1 LCP:    AuthProto CHAP (0x0305C22305)
Jan 20 10:39:50.247 UTC: Vi1 LCP:    MagicNumber 0xD094200D (0x0506D094200D)
Jan 20 10:39:50.251 UTC: Vi1 LCP: I CONFNAK [REQsent] id 49 len 9
Jan 20 10:39:50.251 UTC: Vi1 LCP:    AuthProto CHAP/129 (0x0305C22381)

In highlighted line 1 (Example 3-22), virtual access interface 1 changes state to up. This indicates that the control channel and the session have both been successfully negotiated between the remote access client/PNS and the PAC. The PPP phase then changes to ESTABLISHING (highlighted line 2). LCP negotiation is about to begin.

The PAC sends a CONFREQ to the remote access client/PNS in highlighted line 3. In it, the PAC specifies two LCP options, Authentication Protocol (option 0x03), and Magic Number (option 0x05). The authentication protocol specified by the PAC is standard MD5 CHAP (CHAP, option 0xC22305).

In the third highlighted line, the remote access client/PNS responds with a Configure-Nak (CONFNAK), which indicates that while CHAP is unacceptable, MS-CHAPv2 (CHAP/129, 0xC22381) would be acceptable instead.

The debug output in Example 3-22 does not explicitly show MS-CHAPv2 and, instead, shows CHAP/129 because the particular (old) version of Cisco IOS used in this example does not support MS-CHAPv2. But it is fairly easy to work out that MS-CHAPv2 is indicated from the hexadecimal (0xc22381, shown in brackets in the last line of Example 3-23). The 0xc223 (in 0xc22381) indicates CHAP of some kind, and the final two numerals indicate the specific CHAP algorithm—in this case, MS-CHAPv2 (0x81). 0x81 is 129 in decimal hence the CHAP/129.

The PAC then tries again to negotiate standard MD5 CHAP with the remote access client/PNS, as shown in Example 3-23.

Example 3-23. PAC Tries Again, and Again

						Jan 20 10:39:50.251 UTC: Vi1 LCP: O CONFREQ [REQsent] id 50 len 15
Jan 20 10:39:50.251 UTC: Vi1 LCP:    AuthProto CHAP (0x0305C22305)
Jan 20 10:39:50.255 UTC: Vi1 LCP:    MagicNumber 0xD094200D (0x0506D094200D)
Jan 20 10:39:50.255 UTC: Vi1 LCP: I CONFNAK [REQsent] id 50 len 9
Jan 20 10:39:50.255 UTC: Vi1 LCP:    AuthProto MS-CHAP (0x0305C22380)
Jan 20 10:39:50.255 UTC: Vi1 LCP: O CONFREQ [REQsent] id 51 len 15
Jan 20 10:39:50.255 UTC: Vi1 LCP:    AuthProto CHAP (0x0305C22305)
Jan 20 10:39:50.255 UTC: Vi1 LCP:    MagicNumber 0xD094200D (0x0506D094200D)
Jan 20 10:39:50.255 UTC: Vi1 LCP: I CONFNAK [REQsent] id 51 len 9
Jan 20 10:39:50.255 UTC: Vi1 LCP:    AuthProto MS-CHAP (0x0305C22380)
Jan 20 10:39:50.255 UTC: Vi1 LCP: O CONFREQ [REQsent] id 52 len 15
Jan 20 10:39:50.255 UTC: Vi1 LCP:    AuthProto CHAP (0x0305C22305)
Jan 20 10:39:50.259 UTC: Vi1 LCP:    MagicNumber 0xD094200D (0x0506D094200D)
Jan 20 10:39:50.259 UTC: Vi1 LCP: I CONFNAK [REQsent] id 52 len 9
Jan 20 10:39:50.259 UTC: Vi1 LCP:    AuthProto MS-CHAP (0x0305C22380)
Jan 20 10:39:50.259 UTC: Vi1 LCP: O CONFREQ [REQsent] id 53 len 15
Jan 20 10:39:50.259 UTC: Vi1 LCP:    AuthProto CHAP (0x0305C22305)
Jan 20 10:39:50.259 UTC: Vi1 LCP:    MagicNumber 0xD094200D (0x0506D094200D)
Jan 20 10:39:50.259 UTC: Vi1 LCP: I CONFNAK [REQsent] id 53 len 9
Jan 20 10:39:50.259 UTC: Vi1 LCP:    AuthProto MS-CHAP (0x0305C22380)

In Example 3-23, the PAC again tries to negotiate standard MD5 CHAP by sending four more CONFREQs in highlighted lines 1, 3, 5, and 7.

The remote access client/PNS again rejects each attempt to negotiate standard CHAP by sending CONFNAKs in highlighted lines 2, 4, 6, and 8.

LCP negotiation now fails, and the PPP phase changes to DOWN, as demonstrated in Example 3-24.

Example 3-24. PPP Phase Changes to DOWN

						Jan 20 10:39:50.259 UTC: Vi1 LCP: Failed to negotiate with peer
Jan 20 10:39:50.259 UTC: Vi1 LCP: State is Closed
Jan 20 10:39:50.263 UTC: Vi1 PPP: Phase is DOWN [0 sess, 1 load]
Jan 20 10:39:50.263 UTC: Vi1 PPP: Phase is ESTABLISHING, Passive Open [0 sess, 1 load]
Jan 20 10:39:50.263 UTC: Vi1 LCP: State is Listen
Jan 20 10:39:52.263 UTC: Vi1 LCP: Missed link down notification
Jan 20 10:39:52.263 UTC: Vi1 LCP: State is Closed
Jan 20 10:39:52.263 UTC: Vi1 PPP: Phase is DOWN [0 sess, 1 load]
Arizona_PAC#

In highlighted line 1 (Example 3-24), the output indicates that LCP negotiation with the remote access client/PNS has failed. In highlighted line 2, the PPP phase changes state to DOWN.

PPP negotiation has now ended. It is pretty clear, however, what the problem is: The PAC wants to use standard MD5 CHAP and the remote access client/PNS wants to use MS-CHAP. The PAC virtual template configuration needs to be examined. This is done using the show running-config command.

Example 3-25 shows the configuration of the virtual template on the PAC. Only the relevant portion of the output is shown.

Example 3-25. Verifying the Configuration of the Virtual Template

Arizona_PAC#show running-config
!
interface Virtual-Template1
 ip unnumbered Ethernet1/1
 peer default ip address pool PPTPPool
 ppp encrypt mppe 40 required
 ppp authentication chap
!

It is no surprise that the only authentication protocol configured on the virtual template interface is CHAP. To resolve this, authentication protocols must be modified on either the remote access client/PNS or PAC. In this case, the authentication protocol on the PAC is changed to support MS-CHAPv1 (the remote access client supports MS-CHAP versions 1 and 2).

Example 3-26 shows the reconfiguration of the PPP authentication protocol on the virtual template interface.

Example 3-26. MS-CHAP Is Configured on the Virtual Template

Arizona_PAC#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Arizona_PAC(config)#interface virtual-template 1
Arizona_PAC(config-if)#ppp authentication ms-chap
Arizona_PAC(config-if)#exit
Arizona_PAC#

The remote access client/PNS now successfully connects to the PAC. This is verified using the show vpdn tunnel all command, as shown in Example 3-27.

Example 3-27. Verifying PPTP Tunnel Status

Arizona_PAC#show vpdn tunnel all
%No active L2TP tunnels
%No active L2F tunnels
PPTP Tunnel Information Total tunnels 1 sessions 1
Tunnel id 18, 1 active sessions
  Tunnel state is estabd, time since change 00:00:15
  Remote tunnel name is
    Internet Address 172.16.1.2, port 2089
  Local tunnel name is Arizona_PAC
    Internet Address 10.10.10.100, port 1723
  14 packets sent, 42 received, 498 bytes sent, 3506 received
%No active PPPoE tunnels
Arizona_PAC#

The output in Example 3-27 shows that the tunnel has been successfully established from a remote access client/PNS with IP address 172.16.1.2 (highlighted line 1).

Error 734: The PPP link control protocol was terminated.

Error 691: The specified port is not connected.

PPP Authentication Failure

Once successful LCP negotiation has taken place, and assuming an authentication protocol was negotiated, the next stage is PPP authentication.

Authentication failure is the result of a mismatch of the username, the password, or both between the remote access client/PNS and the PAC (assuming local authentication).

Figure 3-30 shows the PPP authentication phase.

In the following scenario, authentication fails on the PAC.

Before looking at an authentication failure, however, it is worthwhile to examine a successful authentication sequence. The debug ppp negotiation command is used here to examine PPP authentication. Note that the debug ppp authentication command can also be used for this purpose.

Example 3-28 shows a successful authentication phase. Only the relevant portion of the output is shown.

Example 3-28. PPP Authentication Succeeds

Arizona_PAC#debug ppp negotiation
						Jan 20 10:45:47.947 UTC: Vi1 LCP: State is Open
						Jan 20 10:45:47.947 UTC: Vi1 PPP: Phase is AUTHENTICATING, by this end
						[0 sess, 1 load]
						Jan 20 10:45:47.947 UTC: Vi1 MS-CHAP: O CHALLENGE id 14 len 24 from "Arizona_PAC"
Jan 20 10:45:47.951 UTC: Vi1 LCP: I IDENTIFY [Open] id 3 len 18 magic 0x182F4EAA
  MSRASV5.00
Jan 20 10:45:47.951 UTC: Vi1 LCP: I IDENTIFY [Open] id 4 len 25 magic 0x182F4EAA
  MSRAS-1-MLEWIS
Jan 20 10:45:47.951 UTC: Vi1 MS-CHAP: I RESPONSE id 14 len 62 from "mjlnet"
						Jan 20 10:45:47.967 UTC: Vi1 MS-CHAP: O SUCCESS id 14 len 4
					

Highlighted line 1 shows that LCP negotiation has been completed (the LCP state is Open).

The PPP phase changes to AUTHENTICATING in highlighted line 2. Authentication is about to begin.

A MS-CHAP challenge is then sent by the PAC to the remote access client/PNS in highlighted line 3. Note that the PAC identifies itself as Arizona_PAC.

After the MS-CHAP challenge has been sent to the remote access client/PNS, two Identification options are received from the remote access client/PNS. These identify the RAS version (5.00) and computer name (MLEWIS).

In highlighted line 4, a response message is received from the remote access client/PNS. The username specified by the remote access client/PNS is visible in the message as mjlnet.

Finally, the PAC sends a MS-CHAP success message to the remote access client/PNS (highlighted line 5) indicating that authentication has been successful.

Having seen a successful authentication sequence, it is now time to look at an unsuccessful authentication sequence.

Example 3-29 shows an authentication failure.

Example 3-29. PPP Authentication Failure

Arizona_PAC#debug ppp negotiation
PPP protocol negotiation debugging is on
Arizona_PAC#
Jan 20 10:46:59.591 UTC: Vi1 LCP: State is Open
Jan 20 10:46:59.591 UTC: Vi1 PPP: Phase is AUTHENTICATING, by this end
						[0 sess, 1 load]
						Jan 20 10:46:59.591 UTC: Vi1 MS-CHAP: O CHALLENGE id 15 len 24 from "Arizona_PAC"
Jan 20 10:46:59.595 UTC: Vi1 LCP: I IDENTIFY [Open] id 3 len 18 magic 0x2A134EF8
  MSRASV5.00
Jan 20 10:46:59.595 UTC: Vi1 LCP: I IDENTIFY [Open] id 4 len 25 magic 0x2A134EF8
  MSRAS-1-MLEWIS
Jan 20 10:46:59.595 UTC: Vi1 MS-CHAP: I RESPONSE id 15 len 62 from "mjlnet"
						Jan 20 10:46:59.615 UTC: Vi1 MS-CHAP: O FAILURE id 15 len 25 msg is
						"MD/DES compare failed"
Jan 20 10:46:59.615 UTC: Vi1 PPP: Phase is TERMINATING [0 sess, 2 load]
Jan 20 10:46:59.615 UTC: Vi1 LCP: O TERMREQ [Open] id 60 len 4
						Jan 20 10:46:59.623 UTC: Vi1 LCP: I TERMACK [TERMsent] id 60 len 4
Jan 20 10:46:59.623 UTC: Vi1 LCP: State is Closed
Jan 20 10:46:59.623 UTC: Vi1 PPP: Phase is DOWN [0 sess, 2 load]
Jan 20 10:46:59.623 UTC: Vi1 PPP: Phase is ESTABLISHING, Passive Open [0 sess, 2 load]
Jan 20 10:46:59.623 UTC: Vi1 LCP: State is Listen
Jan 20 10:47:01.623 UTC: Vi1 LCP: Missed link down notification
Jan 20 10:47:01.623 UTC: Vi1 LCP: State is Closed
Jan 20 10:47:01.623 UTC: Vi1 PPP: Phase is DOWN [0 sess, 2 load]
Arizona_PAC#

In highlighted line 1, the PPP phase changes to AUTHENTICATING—authentication is about to begin.

A MS-CHAP challenge message is sent to the remote access client/PNS in the second highlighted line.

As before, two LCP messages are then received from the remote access client/PNS that identify the RAS version and computer name.

An MS-CHAP response message is received from the remote access client/PNS (mjlnet, highlighted line 3).

Immediately following this, in highlighted line 4, the PAC sends a MS-CHAP failure message to the remote access client/PNS.

In highlighted line 5, the PAC initiates termination of the connection using a Terminate-Request (TERMREQ) message, and in highlighted line 6, the remote access client/PNS acknowledges this with a Terminate-Ack (TERMACK) message.

Finally, the PPP phase changes state to DOWN in highlighted line 7.

As previously described, authentication failure can be caused by a mismatched username, password, or both. In this case, the user confirms that the correct username and password are being used on the remote access client/PNS, and, therefore, the only possibility is that either the username or the password is incorrectly configured on the PAC. This is corrected as shown in Example 3-30.

Example 3-30. Reconfiguration of the Remote Access Client's Username and Password

Arizona_PAC#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Arizona_PAC(config)#username mjlnet password cisco
Arizona_PAC(config)#exit
Arizona_PAC#

Once the username and password is reconfigured correctly, the remote access client/PNS reconnects and authentication succeeds. This is verified using the show vpdn session all command, as shown in Example 3-31.

Example 3-31. Verifying PPTP Session Setup

Arizona_PAC#show vpdn session all
%No active L2TP tunnels
%No active L2F tunnels
PPTP Session Information Total tunnels 1 sessions 1
Call id 26 is up on tunnel id 26
Remote tunnel name is
  Internet Address is 172.16.1.2
						Session username is mjlnet, state is estabd
    Time since change 00:00:15, interface Vi1
    Remote call id is 32768
    14 packets sent, 43 received, 498 bytes sent, 3722 received
      Ss 15, Sr 43, Remote Nr 14, peer RWS 64
      0 out of order packets
      Flow alarm is clear.
%No active PPPoE tunnels
Arizona_PAC#

Note that there is now one PPTP tunnel with one session within it (highlighted line 1).

In highlighted line 2, the address of the remote access client/PNS is shown to be 172.16.1.2, and finally in highlighted line 3, the username mjlnet can be seen.

Error 691: Access was denied because the username and/or password was invalid in the domain.

If you are using remote AAA, ensure that the AAA server is reachable and that the key is correctly specified on both the PAC and the AAA server. Also ensure that the user password is correctly configured.

Finally, if you are using a RADIUS server, ensure that attribute type 6 (Service-Type) is configured as Framed, and that attribute type 7 (Framed-Protocol) is configured as PPP in settings associated with the user account. These can be found under group setup if you are using Cisco Secure ACS.

NCP Negotiation Failure

Once PPP authentication has succeeded, NCP negotiation can begin. During this phase, protocols such as the Compression Control Protocol (CCP), the IP Control Protocol (IPCP), and IPX Control Protocol (IPXCP) are negotiated.

Microsoft Point-to-Point Encryption (MPPE) is often used to encrypt PPTP tunnel traffic. MPPE is negotiated via the CCP. A number of MPPE configuration options are available, so careful attention must be paid to avoid problems.

Figure 3-31 illustrates NCP negotiation.

MPPE Negotiation Failure

MPPE negotiation can fail in a number of different ways:

• When using MPPE, MS-CHAP must also be configured, or negotiation will fail.

• Either 40-bit or 128-bit encryption is possible, and the remote access client/PNS and the PAC must agree on this.

• Either the remote access client/PNS or the PAC can be configured to require encryption, and if the peer system is not configured for MPPE, negotiation failure will result.

As previously mentioned, one way in which tunnel establishment can fail is if MPPE is configured, but MS-CHAP is not specified as the authentication protocol.

Before taking a look at MPPE negotiation failure, it is useful to have a look at MPPE negotiation when it is successful, using the debug ppp negotiation command.

Examples 3-32 to 3-36 show a successful MPPE negotiation sequence. Only the relevant portion of the output is shown.

Example 3-32. Successful MPPE Negotiation

Arizona_PAC#debug ppp negotiation
							Jan 21 20:51:03.823 UTC: Vi1 LCP: State is Open
							Jan 21 20:51:03.823 UTC: Vi1 PPP: Phase is AUTHENTICATING, by this end
							[0 sess, 1 load]
							Jan 21 20:51:03.823 UTC: Vi1 MS-CHAP: O CHALLENGE id 4 len 24 from "Arizona_PAC"
Jan 21 20:51:03.827 UTC: Vi1 LCP: I IDENTIFY [Open] id 3 len 18 magic 0x6BAF1C08
  MSRASV5.00
Jan 21 20:51:03.827 UTC: Vi1 LCP: I IDENTIFY [Open] id 4 len 25 magic 0x6BAF1C08
  MSRAS-1-MLEWIS
Jan 21 20:51:06.823 UTC: Vi1 PPP: Replace CHAP code 2 id 4 with id 4
Jan 21 20:51:06.823 UTC: Vi1 MS-CHAP: I RESPONSE id 4 len 62 from "mjlnet"
							Jan 21 20:51:06.843 UTC: Vi1 MS-CHAP: O SUCCESS id 4 len 4
						

As you can see, in highlighted line 1, the LCP state is Open, indicating that LCP negotiation has completed successfully.

Immediately after this, the PPP phase changes to AUTHENTICATING (highlighted line 2), and authentication begins.

In highlighted line 3, the PAC sends a MS-CHAP challenge to the remote access client/PNS. The PAC's hostname is identifiable as Arizona_PAC.

A MS-CHAP response message is received from the remote access client/PNS (username mjlnet) in highlighted line 4.

The PAC then sends a MS-CHAP success message to the remote access client/PNS (highlighted line 4). MS-CHAP authentication has succeeded.

NCP negotiation now begins, as shown in Example 3-33.

Example 3-33. NCP (Including CCP) Negotiation Begins

							Jan 21 20:51:06.843 UTC: Vi1 PPP: Phase is UP [0 sess, 1 load]
Jan 21 20:51:06.843 UTC: Vi1 IPCP: O CONFREQ [Not negotiated] id 4 len 10
Jan 21 20:51:06.843 UTC: Vi1 IPCP:    Address 192.168.1.1 (0x0306C0A80101)
Jan 21 20:51:06.843 UTC: Vi1 CCP: O CONFREQ [Not negotiated] id 4 len 10
Jan 21 20:51:06.843 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000020 (0x120601000020)

In highlighted line 1 (Example 3-33), the PPP phase changes to UP, and NCP negotiation begins.

The PAC sends a CONFREQ to the remote access client/PNS specifying Microsoft Point-to-Point Compression (MS-PPC) in highlighted line 2. This is significant because MPPE is a suboption of MS-PPC.

Have a close look at the supported bits specified in this CONFREQ: 0x01000020. Here the PAC is specifying that it supports stateless encryption (indicated by the most significant octet, 0x01), and that it also supports 40-bit MPPE session keys (least significant octet, 0x20). Note that stateless encryption means that session keys are calculated on a packet-by-packet basis.

Before continuing, it is worth briefly examining the MS-PPC supported bits.

Figure 3-32 illustrates the supported bits format.

The supported bits field is four octets in length. Only the H (first octet), M, S, L, D, and C (least significant octet) bits have any meaning.

The H bit indicates support for stateless encryption. The M bit indicates support for 56-bit session keys, the S bit support for 128-bit session keys, and the L bit support for 40-bit session keys. The D bit is obsolete, and the C bit indicates support for MS-PPC.

The supported bit values can be easily calculated using binary to hexadecimal conversion. Should the PAC be configured to support both 40-bit and 128-bit session keys, the least significant octet would have a value of 0x60. If only 128-bit encryption was supported, the value would be 0x40. These values assume that no support for MS-PPC is specified.

Now back to the debug output in Example 3-34 (continued from Example 3-33).

Example 3-34. CCP Negotiation Continues

							Jan 21 20:51:06.851 UTC: Vi1 CCP: I CONFREQ [REQsent] id 5 len 10
Jan 21 20:51:06.851 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000001 (0x120601000001)
Jan 21 20:51:06.851 UTC: Vi1 CCP: O CONFNAK [REQsent] id 5 len 10
Jan 21 20:51:06.851 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 21 20:51:06.851 UTC: Vi1 IPCP: I CONFREQ [REQsent] id 6 len 34
Jan 21 20:51:06.851 UTC: Vi1 IPCP:    Address 0.0.0.0 (0x030600000000)
Jan 21 20:51:06.851 UTC: Vi1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Jan 21 20:51:06.851 UTC: Vi1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Jan 21 20:51:06.851 UTC: Vi1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 21 20:51:06.851 UTC: Vi1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Jan 21 20:51:06.851 UTC: Vi1 IPCP: Pool returned 192.168.2.1
Jan 21 20:51:06.851 UTC: Vi1 IPCP: O CONFREJ [REQsent] id 6 len 16
Jan 21 20:51:06.851 UTC: Vi1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 21 20:51:06.851 UTC: Vi1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Jan 21 20:51:06.851 UTC: Vi1 IPCP: I CONFACK [REQsent] id 4 len 10
Jan 21 20:51:06.851 UTC: Vi1 IPCP:    Address 192.168.1.1 (0x0306C0A80101)

In highlighted line 1 (Example 3-34), the remote access client/PNS sends a CONFREQ to the PAC. Once again, MS-PPC is specified, and the supported bits are 01000001. This indicates support for stateless encryption and MS-PPC. Note that no session key lengths (40, 56 , 128) are specified.

The PAC then sends a CONFNACK in highlighted line 2, which again specifies stateless encryption and 40-bit session key support.

A CCP CONFACK and CONFREQ are now received from the remote access client/PNS, as demonstrated in Example 3-35.

Example 3-35. Inbound CCP CONFACK and CONFREQ

							Jan 21 20:51:06.851 UTC: Vi1 CCP: I CONFACK [REQsent] id 4 len 10
Jan 21 20:51:06.851 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 21 20:51:06.855 UTC: Vi1 CCP: I CONFREQ [ACKrcvd] id 7 len 10
Jan 21 20:51:06.855 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000020 (0x120601000020)

In highlighted line 1 (Example 3-35), a CONFACK is received from the remote access client/PNS acknowledging support for stateless encryption and 40-bit session keys. This is followed, in highlighted line 2, by a CONFREQ, which requests configuration of the same.

In Example 3-36, CCP negotiation succeeds.

Example 3-36. CCP Negotiation Succeeds

							Jan 21 20:51:06.855 UTC: Vi1 CCP: O CONFACK [ACKrcvd] id 7 len 10
Jan 21 20:51:06.855 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 21 20:51:06.855 UTC: Vi1 CCP: State is Open
Arizona_PAC#

The PAC now sends a CONFACK to the remote access client/PNS acknowledging configuration of stateless encryption and 40-bit session keys (highlighted line 1, Example 3-36).

In highlighted line 2, the CCP state changes to Open. MPPE encryption has been successfully negotiated.

Having seen successful MPPE negotiation, it is now time to have a look at what happens when MPPE negotiation fails.

As previously mentioned, if MS-CHAP authentication is not specified, MPPE negotiation will fail. The output of the debug ppp negotiation command in Examples 3-37 to 3-41 show what happens if MS-CHAP authentication is not specified. Once again, for the sake of clarity, only the relevant section of the output is shown.

Example 3-37. MPPE Negotiation Fails

Arizona_PAC#debug ppp negotiation
							Jan 21 20:52:38.571 UTC: Vi1 LCP: State is Open
							Jan 21 20:52:38.571 UTC: Vi1 PPP: Phase is AUTHENTICATING, by this end
							[0 sess, 1 load]
							Jan 21 20:52:38.571 UTC: Vi1 CHAP: O CHALLENGE id 5 len 32 from "Arizona_PAC"
Jan 21 20:52:38.575 UTC: Vi1 LCP: I IDENTIFY [Open] id 3 len 18 magic 0x244B5803
  MSRASV5.00
Jan 21 20:52:38.575 UTC: Vi1 LCP: I IDENTIFY [Open] id 4 len 25 magic 0x244B5803
  MSRAS-1-MLEWIS
Jan 21 20:52:38.575 UTC: Vi1 CHAP: I RESPONSE id 5 len 29 from "mjlnet"
							Jan 21 20:52:38.575 UTC: Vi1 CHAP: O SUCCESS id 5 len 4
						

In highlighted line 1, the LCP state changes to Open. This indicates successful LCP negotiation.

The PPP phase changes to AUTHENTICATING in highlighted line 2.

A CHAP challenge is then sent to the remote access client/PNS in highlighted line 3. A response is received (highlighted line 4), and in highlighted line 5, a success message is sent to the remote access client/PNS. Authentication has succeeded.

NCP negotiation begins in Example 3-38.

Example 3-38. NCP (Including CCP) Negotiation Begins

							Jan 21 20:52:38.575 UTC: Vi1 PPP: Phase is UP [0 sess, 1 load]
Jan 21 20:52:38.575 UTC: Vi1 IPCP: O CONFREQ [Not negotiated] id 5 len 10
Jan 21 20:52:38.575 UTC: Vi1 IPCP:    Address 192.168.1.1 (0x0306C0A80101)
Jan 21 20:52:38.575 UTC: Vi1 CCP: O CONFREQ [Closed] id 5 len 4
						

The PPP phase changes to UP in highlighted line 1 (Example 3-38). NCP negotiation is about to begin.

A CCP CONFREQ is sent to the remote access client/PNS in highlighted line 2. This seems good, but a close examination reveals that no options (MS-PPC) are sent with it (notice that the length [len] is only four octets). There's something funny going on here.

CCP negotiation continues in Example 3-39.

Example 3-39. CCP Negotiation Continues

							Jan 21 20:52:38.579 UTC: Vi1 CCP: I CONFREQ [REQsent] id 5 len 10
Jan 21 20:52:38.579 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000001 (0x120601000001)
Jan 21 20:52:38.583 UTC: Vi1 CCP: O CONFNAK [REQsent] id 5 len 10
Jan 21 20:52:38.583 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 21 20:52:38.583 UTC: Vi1 IPCP: I CONFREQ [REQsent] id 6 len 34
Jan 21 20:52:38.583 UTC: Vi1 IPCP:    Address 0.0.0.0 (0x030600000000)
Jan 21 20:52:38.583 UTC: Vi1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Jan 21 20:52:38.583 UTC: Vi1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Jan 21 20:52:38.583 UTC: Vi1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 21 20:52:38.583 UTC: Vi1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Jan 21 20:52:38.583 UTC: Vi1 IPCP: Pool returned 192.168.2.1
Jan 21 20:52:38.583 UTC: Vi1 IPCP: O CONFREJ [REQsent] id 6 len 16
Jan 21 20:52:38.583 UTC: Vi1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 21 20:52:38.583 UTC: Vi1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Jan 21 20:52:38.583 UTC: Vi1 IPCP: I CONFACK [REQsent] id 5 len 10
Jan 21 20:52:38.583 UTC: Vi1 IPCP:    Address 192.168.1.1 (0x0306C0A80101)

In highlighted line 1 (Example 3-39), a CCP CONFREQ is received from the remote access client/PNS. In it, MS-PPC is specified, with supported bits 0x01000001. If you refer back to the previous description of supported bits, you will see that this indicates support for stateless encryption and MS-PPC itself but does not specify any session key length.

The PAC then sends a CCP CONFNACK to the remote access client/PNS (highlighted line 2). In it, supported bits 0x010000020 are specified (stateless encryption and 40-bit session keys).

MPPE negotiation now fails, as shown in Example 3-40.

Example 3-40. MPPE Negotiation Fails

							Jan 21 20:52:38.583 UTC: Vi1 CCP: I CONFACK [REQsent] id 5 len 4
							Jan 21 20:52:38.583 UTC: Vi1 CCP: I CONFREQ [ACKrcvd] id 7 len 4
							Jan 21 20:52:38.587 UTC: Vi1 CCP: O CONFACK [ACKrcvd] id 7 len 4
Jan 21 20:52:38.587 UTC: Vi1 CCP: State is Open
Jan 21 20:52:38.587 UTC: Vi1 MPPE: Required encryption not negotiated
Jan 21 20:52:38.587 UTC: Vi1 IPCP: State is Closed
Jan 21 20:52:38.587 UTC: Vi1 CCP: State is Closed
Jan 21 20:52:38.587 UTC: Vi1 MPPE: Required encryption not negotiated

In Example 3-40, the PAC receives a CCP CONFACK from the remote access client/PNS (highlighted line 1), but again, there are no options specified. In highlighted line 2, another CCP CONFREQ is received from the remote access client/PNS. Once again, no options are specified. The PAC then responds with a CCP CONFACK (highlighted line 3). This specifies no options either. This definitely does not look like a healthy MPPE negotiation exchange.

In highlighted line 4, the message Jan 21 20:52:38.587 UTC: Vi1 MPPE: Required encryption not negotiated reveals that MPPE has not been negotiated, and in highlighted line 5, the CCP state changes to Closed.

In Example 3-41, PPP negotiation is terminated.

Example 3-41. PPP Negotiation Is Terminated

							Jan 21 20:52:38.587 UTC: Vi1 PPP: Phase is TERMINATING [0 sess, 2 load]
							Jan 21 20:52:38.587 UTC: Vi1 LCP: O TERMREQ [Open] id 23 len 4
Jan 21 20:52:38.587 UTC: Vi1 LCP: State is Closed
Jan 21 20:52:38.587 UTC: Vi1 PPP: Phase is DOWN [0 sess, 2 load]
Jan 21 20:52:38.587 UTC: Vi1 PPP: Phase is ESTABLISHING, Passive Open [0 sess, 2 load]
Jan 21 20:52:38.587 UTC: Vi1 LCP: State is Listen
Jan 21 20:52:40.587 UTC: Vi1 LCP: Missed link down notification
Jan 21 20:52:40.587 UTC: Vi1 LCP: State is Closed
Jan 21 20:52:40.587 UTC: Vi1 PPP: Phase is DOWN [0 sess, 2 load]
Arizona_PAC#

The PPP phase now changes to TERMINATING (highlighted line 1, Example 3-41).

Then in highlighted line 2, the PAC sends a Terminate-Request (TERMREQ) to the remote access client/PNS, and in highlighted line 3, the PPP phase changes to DOWN. PPP negotiation has been unsuccessful.

What went wrong? A close look at highlighted lines 3, 4, and 5 all the way back in Example 3-37 reveals that the authentication protocol in use is regular MD-5 CHAP, not the MS-CHAP essential for successful MPPE negotiation.

The remote access client/PNS user confirms that MS-CHAP is specified as an authentication protocol on the remote access client/PNS. This leaves only one possibility: MS-CHAP is not specified as an authentication protocol on the PAC. You can confirm the authentication protocol that is configured using the show running-config command.

Example 3-42 shows the configuration of the virtual template interface.

Example 3-42. Virtual Template Configuration

Arizona_PAC#show running-config
!
interface Virtual-Template1
 ip unnumbered Ethernet1/1
 peer default ip address pool PPTPPool
 ppp encrypt mppe 40 required
 ppp authentication chap
!

As you can see from the configuration, only standard MD5 CHAP is specified, not MS-CHAP. The configuration is then modified to allow MS-CHAP authentication.

Example 3-43 shows the reconfiguration of authentication protocols on the virtual template interface.

Example 3-43. MS-CHAP Authentication Is Configured on the Virtual Template

Arizona_PAC#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Arizona_PAC(config)#interface virtual-template 1
Arizona_PAC(config-if)#ppp authentication ms-chap
Arizona_PAC(config-if)#exit
Arizona_PAC#

The remote access client/PNS then successfully reconnects.

Successful PPTP session establishment is verified using the show vpdn session all command, as shown in Example 3-44.

Example 3-44. Verifying PPTP Session Establishment

Arizona_PAC#show vpdn session all
%No active L2TP tunnels
%No active L2F tunnels
PPTP Session Information Total tunnels 1 sessions 1
Call id 9 is up on tunnel id 9
Remote tunnel name is
  Internet Address is 172.16.1.2
							Session username is mjlnet, state is estabd
    Time since change 00:00:15, interface Vi1
    Remote call id is 49152
    14 packets sent, 39 received, 498 bytes sent, 3194 received
      Ss 15, Sr 39, Remote Nr 14, peer RWS 64
      0 out of order packets
      Flow alarm is clear.
%No active PPPoE tunnels
Arizona_PAC#

In highlighted line 1, you can see that one PPTP tunnel and one session have been successfully established.

Then in highlighted lines 2 and 3, you can see the IP address (172.16.1.2) and username (mjlnet) of the remote access client/PNS.

Note that the error reported by Microsoft remote access client/PNSs in the event of a MPPE failure due to the lack of MS-CHAP authentication is as follows:

Error 619: The specified port is not connected.

As previously noted, if the required keyword is specified with the ppp encrypt mppe command under the virtual template, and MPPE encryption is not configured on the remote access client/PNS, MPPE negotiation will also fail. In this case, the error reported by Microsoft (Windows 2000) client/PNSs will again be:

Error 619: The specified port is not connected.

If a Microsoft remote access client/PNS is configured to require data encryption (the Require data encryption box is checked under the Security tab of the Network/Dial-Up connection configuration in Windows 2000), but the PAC is not configured for MPPE, MPPE negotiation will fail. The error seen on the remote access client will be as follows:

Error 742: The remote computer does not support the required data encryption type.

Finally, if you are using remote AAA, also see “Case Study 1: MPPE Attributes Are Not Returned from the RADIUS Server.”

IPCP Negotiation Failure

Once LCP negotiation and authentication have taken place, the IPCP can be negotiated.

Two common reasons for IPCP negotiation failure are:

• No IP address has been configured on the virtual template interface associated with the PPTP VPDN group.

• No IP address is supplied by the PAC to the remote access client/PNS.

Before examining what happens when IPCP negotiation is unsuccessful, it is useful to first have a look at a successful IPCP negotiation sequence.

Use the debug ppp negotiation command to examine IPCP negotiation as shown in Examples 3-45 to 3-53. Only the relevant output is shown.

Example 3-45. Successful IPCP Negotiation

Arizona_PAC#debug ppp negotiation
Arizona_PAC#
Jan 20 10:37:13.479 UTC: Vi1 PPP: Phase is UP [0 sess, 1 load]
							Jan 20 10:37:13.479 UTC: Vi1 IPCP: O CONFREQ [Not negotiated] id 12 len 10
Jan 20 10:37:13.479 UTC: Vi1 IPCP:    Address 192.168.1.1 (0x0306C0A80101)
Jan 20 10:37:13.479 UTC: Vi1 CCP: O CONFREQ [Not negotiated] id 4 len 10
Jan 20 10:37:13.479 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 10:37:13.483 UTC: Vi1 CCP: I CONFREQ [REQsent] id 5 len 10
Jan 20 10:37:13.483 UTC: Vi1 CCP:    MS-PPC supported bits 0x010000B1 (0x1206010000B1)
Jan 20 10:37:13.483 UTC: Vi1 CCP: O CONFNAK [REQsent] id 5 len 10
Jan 20 10:37:13.483 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000020 (0x120601000020)

In highlighted line 1, the PPP phase changes to UP. NCP negotiation is about to begin.

In highlighted line 2, the PAC sends a CONFREQ including IPCP option 0x03 (IP-Address). This is used to specify the PAC's own IP address (192.16.1.1).

The remote access client/PNS now sends a CONFREQ as shown in Example 3-46.

Example 3-46. Remote Access Client Sends a CONFREQ and an IP Address Is Obtained

							Jan 20 10:37:13.483 UTC: Vi1 IPCP: I CONFREQ [REQsent] id 6 len 34
Jan 20 10:37:13.483 UTC: Vi1 IPCP:    Address 0.0.0.0 (0x030600000000)
Jan 20 10:37:13.483 UTC: Vi1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Jan 20 10:37:13.483 UTC: Vi1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Jan 20 10:37:13.487 UTC: Vi1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 20 10:37:13.487 UTC: Vi1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Jan 20 10:37:13.487 UTC: Vi1 IPCP: Pool returned 192.168.2.1
						

In Example 3-46, the PAC receives a CONFREQ from the remote access client/PNS (highlighted line 1). This CONFREQ includes Address, Primary DNS, Primary WINS, Secondary DNS, and Secondary WINS IPCP options (0x03, 0x81, 0x82, 0x83, and 0x84, respectively).

Note that all of these options specify a 0.0.0.0 address. This is used by the remote access client/PNS to indicate to the PAC that these addresses should be supplied.

In highlighted line 2, the PAC obtains an IP address (for the remote access client/PNS) from the IP address pool.

The PAC then sends a CONFREJ to the remote access client/PNS rejecting usage of the Secondary DNS and Secondary WINS options, as shown in Example 3-47. This is because, in this example, the PAC is not configured to supply these options.

Example 3-47. PAC Rejects Configuration of Secondary DNS and WINS Servers

							Jan 20 10:37:13.487 UTC: Vi1 IPCP: O CONFREJ [REQsent] id 6 len 16
Jan 20 10:37:13.487 UTC: Vi1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 20 10:37:13.487 UTC: Vi1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)

In Example 3-48, the remote access client/PNS acknowledges the PAC's IP address by sending a CONFACK. Note that the ID (12) of this CONFACK is the same as the ID specified in the CONFREQ sent by the PAC in Example 3-45.

Example 3-48. Remote Access Client Acknowledges the PAC's IP Address

							Jan 20 10:37:13.487 UTC: Vi1 IPCP: I CONFACK [REQsent] id 12 len 10
Jan 20 10:37:13.487 UTC: Vi1 IPCP:    Address 192.168.1.1 (0x0306C0A80101)
Jan 20 10:37:13.487 UTC: Vi1 CCP: I CONFACK [REQsent] id 4 len 10
Jan 20 10:37:13.487 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 10:37:13.487 UTC: Vi1 CCP: I CONFREQ [ACKrcvd] id 7 len 10
Jan 20 10:37:13.487 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 10:37:13.487 UTC: Vi1 CCP: O CONFACK [ACKrcvd] id 7 len 10
Jan 20 10:37:13.487 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 10:37:13.487 UTC: Vi1 CCP: State is Open

In Example 3-49, the remote access client/PNS sends another CONFREQ message with the IP Address, Primary DNS Server, and Primary WINS Server options specified (all other options in the last IPCP CONFREQ having been rejected by the PAC in Example 3-47). Again, these addresses are specified as 0.0.0.0 to indicate to the PAC that these options should be supplied.

Example 3-49. Remote Access Client/PNS Sends Another CONFREQ

							Jan 20 10:37:13.491 UTC: Vi1 IPCP: I CONFREQ [ACKrcvd] id 8 len 22
Jan 20 10:37:13.491 UTC: Vi1 IPCP:    Address 0.0.0.0 (0x030600000000)
Jan 20 10:37:13.491 UTC: Vi1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Jan 20 10:37:13.491 UTC: Vi1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)

The PAC then responds by sending a CONFNACK message to the remote access client/PNS, as shown in Example 3-50. Included are the IP address obtained from the IP pool in Example 3-46, as well as DNS server and WINS server addresses requested by the remote access client/PNS in Example 3-49.

Example 3-50. PAC Supplies an IP Address and DNS and WINS Server Addresses

							Jan 20 10:37:13.491 UTC: Vi1 IPCP: O CONFNAK [ACKrcvd] id 8 len 22
Jan 20 10:37:13.491 UTC: Vi1 IPCP:    Address 192.168.2.1 (0x0306C0A80201)
Jan 20 10:37:13.491 UTC: Vi1 IPCP:    PrimaryDNS 192.168.1.10 (0x8106C0A8010A)
Jan 20 10:37:13.491 UTC: Vi1 IPCP:    PrimaryWINS 192.168.1.12 (0x8206C0A8010C)

In Example 3-51, the remote access client/PNS sends a third CONFREQ message to the PAC. Included in the CONFREQ are the addresses previously supplied by the PAC in Example 3-50.

Example 3-51. Remote Access Client Sends a Third CONFREQ

							Jan 20 10:37:13.495 UTC: Vi1 IPCP: I CONFREQ [ACKrcvd] id 9 len 22
Jan 20 10:37:13.495 UTC: Vi1 IPCP:    Address 192.168.2.1 (0x0306C0A80201)
Jan 20 10:37:13.495 UTC: Vi1 IPCP:    PrimaryDNS 192.168.1.10 (0x8106C0A8010A)
Jan 20 10:37:13.495 UTC: Vi1 IPCP:    PrimaryWINS 192.168.1.12 (0x8206C0A8010C)

The PAC then acknowledges the remote access client/PNS's CONFREQ in Example 3-51 by sending a CONFACK, as shown in Example 3-52.

Example 3-52. PAC Acknowledges the Remote Access Client/PNS's CONFREQ

							Jan 20 10:37:13.495 UTC: Vi1 IPCP: O CONFACK [ACKrcvd] id 9 len 22
Jan 20 10:37:13.495 UTC: Vi1 IPCP:    Address 192.168.2.1 (0x0306C0A80201)
Jan 20 10:37:13.495 UTC: Vi1 IPCP:    PrimaryDNS 192.168.1.10 (0x8106C0A8010A)
Jan 20 10:37:13.495 UTC: Vi1 IPCP:    PrimaryWINS 192.168.1.12 (0x8206C0A8010C)

In Example 3-53, the IPCP negotiation succeeds.

Example 3-53. IPCP State Changes to Open, and the Interface Changes State to Up

							Jan 20 10:37:13.495 UTC: Vi1 IPCP: State is Open
							Jan 20 10:37:13.495 UTC: Vi1 IPCP: Install route to 192.168.2.1
							Jan 20 10:37:14.479 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
							Virtual-Access1, changed state to up
Arizona_PAC#

In highlighted line 1 (Example 3-53), the IPCP state changes to Open, indicating that IPCP negotiation has succeeded.

A host route to the remote access client/PNS (192.168.2.1) is installed (highlighted line 2), and the line protocol on virtual access interface 1 changes state to up (highlighted line 3).

IPCP Negotiation Fails Because of a Missing IP Address on the Virtual Template Interface

As mentioned previously, one possible reason for IPCP negotiation failure is the lack of an IP address on the virtual template interface. Again, because IPCP negotiation forms part of the overall PPP negotiation sequence, the debug ppp negotiation command can be used to examine this issue.

Examples 3-54 to 3-56 show the failure of IPCP negotiation between the remote access client/PNS and PAC. Only the relevant output is shown.

In highlighted line 1, the PPP phase changes to UP. NCP negotiation is about to begin.

Example 3-54. IPCP Negotiation Fails

Arizona_PAC#debug ppp negotiation
Arizona_PAC#
Jan 20 22:35:27.779 UTC: Vi1 PPP: Phase is UP [0 sess, 1 load]
Jan 20 22:35:27.779 UTC: Vi1 CCP: O CONFREQ [Not negotiated] id 4 len 10
Jan 20 22:35:27.779 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 22:35:27.783 UTC: Vi1 CCP: I CONFREQ [REQsent] id 5 len 10
Jan 20 22:35:27.783 UTC: Vi1 CCP:    MS-PPC supported bits 0x010000B1 (0x1206010000B1)
Jan 20 22:35:27.783 UTC: Vi1 CCP: O CONFNAK [REQsent] id 5 len 10
Jan 20 22:35:27.783 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 22:35:27.783 UTC: Vi1 IPCP: I CONFREQ [Not negotiated] id 6 len 34
Jan 20 22:35:27.783 UTC: Vi1 IPCP:    Address 0.0.0.0 (0x030600000000)
Jan 20 22:35:27.783 UTC: Vi1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Jan 20 22:35:27.783 UTC: Vi1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Jan 20 22:35:27.783 UTC: Vi1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 20 22:35:27.783 UTC: Vi1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)

In highlighted line 2, IPCP negotiation begins with the remote access client/PNS sending a CONFREQ to the PAC. This CONFREQ specifies the IP address (option 0x03), Primary DNS address (option 0x81), Primary NetBIOS Name Server address (NBNS or WINS server address, option 0x82), Secondary DNS server address (option 0x83), and finally Secondary NBNS Server address (option 0x84).

All the options are specified as 0.0.0.0. This is an indication to the PAC that it should supply these addresses.

Significantly, however, the PAC now sends a Protocol-Reject (PROTREJ) message to the remote access client/PNS indicating that the PAC does not understand or support IPCP. This PROTREJ message is shown in Example 3-55.

Example 3-55. PAC Rejects Configuration of IPCP

								Jan 20 22:35:27.783 UTC: Vi1 LCP: O PROTREJ [Open] id 10 len 40 protocol IPCP
Jan 20 22:35:27.783 UTC: Vi1 LCP:  (0x80210106002203060000000081060000)
Jan 20 22:35:27.783 UTC: Vi1 LCP:  (0x00008206000000008306000000008406)
Jan 20 22:35:27.783 UTC: Vi1 LCP:  (0x00000000)
Jan 20 22:35:27.787 UTC: Vi1 CCP: I CONFACK [REQsent] id 4 len 10
Jan 20 22:35:27.787 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 22:35:27.787 UTC: Vi1 CCP: I CONFREQ [ACKrcvd] id 7 len 10
Jan 20 22:35:27.787 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 22:35:27.787 UTC: Vi1 CCP: O CONFACK [ACKrcvd] id 7 len 10
Jan 20 22:35:27.787 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 22:35:27.787 UTC: Vi1 CCP: State is Open
Jan 20 22:35:27.803 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
  to down
Jan 20 22:35:27.803 UTC: Vi1 CCP: State is Closed
Jan 20 22:35:27.803 UTC: Vi1 MPPE: Required encryption not negotiated

PPP negotiation is now terminated, as demonstrated in Example 3-56.

Example 3-56. PPP Negotiation Is Terminated

								Jan 20 22:35:27.803 UTC: Vi1 PPP: Phase is TERMINATING [0 sess, 2 load]
								Jan 20 22:35:27.803 UTC: Vi1 LCP: O TERMREQ [Open] id 11 len 4
Jan 20 22:35:27.803 UTC: Vi1 LCP: State is Closed
Jan 20 22:35:27.803 UTC: Vi1 PPP: Phase is DOWN [0 sess, 2 load]
Jan 20 22:35:29.803 UTC: Vi1 LCP: Missed link down notification
Jan 20 22:35:29.803 UTC: Vi1 LCP: State is Closed
Arizona_PAC#

In highlighted line 1 (Example 3-56), the PPP phase changes to TERMINATING.

The PAC sends a Terminate-Request (TERMREQ, highlighted line 2) to the remote access client/PNS. This indicates that the PAC is terminating the PPP connection.

The PPP phase then changes to DOWN in highlighted line 3.

Why exactly did the PAC inform the remote access client/PNS that it did not understand or support IPCP (in Example 3-55)? The title and introduction to this section may be a bit of a giveaway. The PAC's configuration is examined using the show running-config command, as shown in Example 3-57.

Example 3-57. Verifying the Virtual Template Configuration

Arizona_PAC#show running-config
!
interface Virtual-Template1
 no ip address
 peer default ip address pool PPTPPool
 ppp encrypt mppe 40 required
 ppp authentication ms-chap
!

As you can see, the virtual template interface has not been configured with an IP address. This can be easily resolved.

Example 3-58 shows the configuration of ip unnumbered on the virtual template interface.

Example 3-58. IP Address Is Configured on the Virtual Template

Arizona_PAC#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Arizona_PAC(config)#interface virtual-template 1
Arizona_PAC(config-if)#ip unnumbered ethernet 1/1
Arizona_PAC(config-if)#exit
Arizona_PAC#

ip unnumbered is configured on the virtual template interface in Example 3-58. The remote access client/PNS now successfully connects to the PAC.

Example 3-59 shows the successful session establishment from the remote access client/PNS (verified using the show vpdn session all command).

Example 3-59. Verifying Successful PPTP Session Establishment

Arizona_PAC#show vpdn session all
%No active L2TP tunnels
%No active L2F tunnels
PPTP Session Information Total tunnels 1 sessions 1
Call id 6 is up on tunnel id 6
Remote tunnel name is
  Internet Address is 172.16.1.2
								Session username is mjlnet, state is estabd
    Time since change 00:00:30, interface Vi1
    Remote call id is 49152
    16 packets sent, 50 received, 562 bytes sent, 4695 received
      Ss 17, Sr 50, Remote Nr 16, peer RWS 64
      0 out of order packets
      Flow alarm is clear.
%No active PPPoE tunnels
Arizona_PAC#

As you can see, a PPTP tunnel is established from IP address 172.16.1.2 (highlighted line 1). One session is established within that tunnel, and the username associated with this session is mjlnet (highlighted line 2). The issue has been resolved.

Note that the error reported by Microsoft (Windows 2000) remote access client/PNSs in the event of this type of IPCP failure is as follows:

TCP/IP CP reported error 733: Your computer and the remote computer could not agree on PPP
 control protocols.

IPCP Negotiation Fails Because of Insufficient IP Addresses or a Missing IP Address Pool

A second reason that IPCP negotiation can fail between the remote access client/PNS and the PAC is insufficient IP addresses within the IP address pool, or the lack of a configured IP address pool.

IP addresses can be supplied to remote access client/PNSs using DHCP or even using IP addresses supplied by an AAA server. If DHCP or the AAA server fails to supply an IP address, the same kind of IPCP negotiation failure can result.

Note that in this scenario, the lack of a local IP address pool is used to illustrate this problem.

The debug ppp negotiation command is again used to examine the IPCP negotiation failure as shown in Examples 3-60 to 3-66. Only the relevant portion of the output is shown.

Example 3-60. IPCP Negotiation Fails

Arizona_PAC#debug ppp negotiation
Arizona_PAC#
Jan 20 22:42:48.323 UTC: Vi1 PPP: Phase is UP [0 sess, 2 load]
								Jan 20 22:42:48.323 UTC: Vi1 IPCP: O CONFREQ [Not negotiated] id 8 len 10
Jan 20 22:42:48.323 UTC: Vi1 IPCP:    Address 192.168.1.1 (0x0306C0A80101)
Jan 20 22:42:48.323 UTC: Vi1 CCP: O CONFREQ [Not negotiated] id 8 len 10
Jan 20 22:42:48.323 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 22:42:48.327 UTC: Vi1 CCP: I CONFREQ [REQsent] id 5 len 10
Jan 20 22:42:48.327 UTC: Vi1 CCP:    MS-PPC supported bits 0x010000B1 (0x1206010000B1)
Jan 20 22:42:48.327 UTC: Vi1 CCP: O CONFNAK [REQsent] id 5 len 10
Jan 20 22:42:48.327 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000020 (0x120601000020)

In highlighted line 1 (Example 3-60), the PPP phase changes to UP. NCP negotiation is about to begin.

IPCP negotiation starts with the PAC sending a CONFREQ to the remote access client/PNS specifying its own IP address (IPCP option 0x03, highlighted line 2).

In Example 3-61, the remote access client/PNS sends a CONFREQ.

Example 3-61. Remote Access Client/PNS Sends a CONFREQ

								Jan 20 22:42:48.327 UTC: Vi1 IPCP: I CONFREQ [REQsent] id 6 len 34
Jan 20 22:42:48.327 UTC: Vi1 IPCP:    Address 0.0.0.0 (0x030600000000)
Jan 20 22:42:48.327 UTC: Vi1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Jan 20 22:42:48.327 UTC: Vi1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Jan 20 22:42:48.327 UTC: Vi1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 20 22:42:48.327 UTC: Vi1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Jan 20 22:42:48.327 UTC: Vi1 IPCP: Cannot satisfy pool request
Jan 20 22:42:48.327 UTC: Vi1 IPCP: Neither side knows remote address

In highlighted line 1 (Example 3-61), the remote access client/PNS sends an CONFREQ to the PAC, in which it specifies IP address (0x03), Primary DNS server address (0x81), Primary WINS (0x82), Secondary DNS server address (0x83), and lastly Secondary WINS address (0x84). All of these options are set to 0.0.0.0, indicating to the PAC that they should be supplied to the remote access client/PNS.

Something very interesting now happens: In highlighted line 2, the message IPCP: Cannot satisfy pool request appears. This is a pretty clear indication that the PAC cannot supply the required IP address to the remote access client/PNS.

In Example 3-62, the PAC communicates this problem to the remote access client/PNS by sending a CONFREJ. This message rejects configuration of IP address, Secondary DNS Server, and Secondary WINS Server options on this link.

Example 3-62. PAC Rejects Configuration of IP Address and Secondary DNS and WINS Server Addresses

								Jan 20 22:42:48.327 UTC: Vi1 IPCP: O CONFREJ [REQsent] id 6 len 22
Jan 20 22:42:48.327 UTC: Vi1 IPCP:    Address 0.0.0.0 (0x030600000000)
Jan 20 22:42:48.327 UTC: Vi1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 20 22:42:48.327 UTC: Vi1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)

In Example 3-63, the remote access client/PNS sends a CONFACK to acknowledge the PAC's CONFREQ sent in Example 3-60 (highlighted line 2).

Example 3-63. Remote Access Client/PNS Acknowledges the PAC's CONFREQ

								Jan 20 22:42:48.331 UTC: Vi1 IPCP: I CONFACK [REQsent] id 8 len 10
Jan 20 22:42:48.331 UTC: Vi1 IPCP:    Address 192.168.1.1 (0x0306C0A80101)
Jan 20 22:42:48.331 UTC: Vi1 CCP: I CONFACK [REQsent] id 8 len 10
Jan 20 22:42:48.331 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 22:42:48.331 UTC: Vi1 CCP: I CONFREQ [ACKrcvd] id 7 len 10
Jan 20 22:42:48.331 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 22:42:48.331 UTC: Vi1 CCP: O CONFACK [ACKrcvd] id 7 len 10
Jan 20 22:42:48.331 UTC: Vi1 CCP:    MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 22:42:48.331 UTC: Vi1 CCP: State is Open

Notwithstanding the CONFREJ sent by the PAC in Example 3-62, the remote access client/PNS makes another attempt to request an IP address by sending a CONFREQ in Example 3-64 (highlighted line 1).

In highlighted line 2, the PAC again indicates that it cannot satisfy this request.

Example 3-64. Remote Access Client/PNS Sends Another CONFREQ

								Jan 20 22:42:48.335 UTC: Vi1 IPCP: I CONFREQ [ACKrcvd] id 8 len 10
Jan 20 22:42:48.335 UTC: Vi1 IPCP:    Address 0.0.0.0 (0x030600000000)
Jan 20 22:42:48.335 UTC: Vi1 IPCP: Cannot satisfy pool request
Jan 20 22:42:48.335 UTC: Vi1 IPCP: Neither side knows remote address

Configuration of an IP address is again rejected when the PAC sends another CONFREJ to the remote access client/PNS, as shown in Example 3-65.

Example 3-65. PAC Again Rejects Configuration of an IP Address

								Jan 20 22:42:48.335 UTC: Vi1 IPCP: O CONFREJ [ACKrcvd] id 8 len 10
Jan 20 22:42:48.335 UTC: Vi1 IPCP:    Address 0.0.0.0 (0x030600000000)

PPP negotiation is now terminated, as demonstrated in Example 3-66.

Example 3-66. PPP Negotiation Is Terminated

								Jan 20 22:42:48.335 UTC: Vi1 IPCP: I TERMREQ [ACKrcvd] id 9 len 16
								(0x5176655B003CCD74000002E2)
								Jan 20 22:42:48.335 UTC: Vi1 IPCP: O TERMACK [ACKrcvd] id 9 len 4
Jan 20 22:42:48.347 UTC: Vi1 LCP: I TERMREQ [Open] id 10 len 16
  (0x5176655B003CCD7400000000)
Jan 20 22:42:48.347 UTC: Vi1 LCP: O TERMACK [Open] id 10 len 4
Jan 20 22:42:48.347 UTC: Vi1 PPP: Phase is TERMINATING [0 sess, 1 load]
Jan 20 22:42:48.351 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
  to down
Jan 20 22:42:48.351 UTC: Vi1 LCP: State is Closed
Jan 20 22:42:48.351 UTC: Vi1 IPCP: State is Closed
Jan 20 22:42:48.351 UTC: Vi1 CCP: State is Closed
Jan 20 22:42:48.351 UTC: Vi1 MPPE: Required encryption not negotiated
Jan 20 22:42:48.351 UTC: Vi1 PPP: Phase is DOWN [0 sess, 1 load]
Arizona_PAC#

In Example 3-66, the remote access client/PNS initiates termination of IPCP negotiation by sending a Terminate-Request (TERMREQ) in highlighted line 1. The PAC responds with a Terminate-Ack (TERMACK) in line 2. Finally, in highlighted line 3, the PPP phase changes to DOWN. PPP negotiation has failed.

One thing to note is that the connection is not necessarily terminated if IPCP negotiation fails. If, for example, another NCP, such as IPXCP, is successfully negotiated, the connection is not terminated.

The PAC's configuration is then examined using the show running-config command.

Example 3-67 shows the PAC's configuration.

Example 3-67. Verifying the PAC's Configuration

Arizona_PAC#show running-config
!
interface Virtual-Template1
 ip unnumbered Ethernet1/1
 peer default ip address pool PPTPPool
 ppp encrypt mppe 40 required
 ppp authentication ms-chap
!

As you can see, the PAC is configured to supply an IP address to the remote access client/PNS (peer default ip address pool PPTPPool), but unfortunately, the IP address pool PPTPPool does not exist.

The IP address pool is then configured, as shown in Example 3-68.

Example 3-68. IP Address Pool Is Configured on the PAC

Arizona_PAC#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Arizona_PAC(config)#ip local pool PPTPPool 192.168.2.1 192.168.2.10
Arizona_PAC(config)#exit
Arizona_PAC#

Once an IP address pool has been configured, PPTP tunnel and session setup succeeds.

Successful tunnel and session setup between the remote access client/PNS and the PAC is now verified using the show vpdn session all command, as shown in Example 3-69.

Example 3-69. Verifying PPTP Session Setup

Arizona_PAC#show vpdn session all
%No active L2TP tunnels
%No active L2F tunnels
PPTP Session Information Total tunnels 1 sessions 1
Call id 10 is up on tunnel id 10
Remote tunnel name is
  Internet Address is 172.16.1.2
								Session username is mjlnet, state is estabd
    Time since change 00:00:28, interface Vi1
    Remote call id is 49152
    15 packets sent, 52 received, 530 bytes sent, 4906 received
      Ss 16, Sr 52, Remote Nr 15, peer RWS 64
      0 out of order packets
      Flow alarm is clear.
%No active PPPoE tunnels
Arizona_PAC#

Highlighted line 1 shows that a PPTP tunnel has been established from a remote access client/PNS with IP address 172.16.1.2. A session has been established within that tunnel, with username mjlnet (highlighted line 2).

Note that the error reported by Microsoft (Windows 2000) remote access client/PNSs in the event of an IP address assignment failure is as follows:

TCP/IP CP reported error 738: The server did not assign an address.