|
|
Case StudiesThis section contains solutions for other issues not covered in the main troubleshooting section. Case Study 1: MPPE Attributes Are Not Returned from the RADIUS ServerWhen using MPPE in conjunction with a RADIUS server, you must be careful to ensure that Microsoft vendor-specific attributes are correctly configured. If these attributes are incorrectly configured, MPPE negotiation may fail between the remote access client/PNS and the PAC. Figure 3-33 illustrates the topology used in this case study. Figure 3-33. Topology for Case Study 1
In this scenario, the Microsoft MPPE vendor-specific attributes have been incorrectly configured on the RADIUS server. The first command to use when troubleshooting this issue is debug ppp negotiation, as shown in Examples 3-70 to 3-72. Only the relevant output is shown. Example 3-70. PPP Negotiation FailsArizona_PAC#debug ppp negotiation Jan 22 17:17:37.347 UTC: Vi1 PPP: Phase is UP [0 sess, 1 load] Jan 22 17:17:37.347 UTC: Vi1 IPCP: O CONFREQ [Not negotiated] id 5 len 10 Jan 22 17:17:37.347 UTC: Vi1 IPCP: Address 192.168.1.1 (0x0306C0A80101) Jan 22 17:17:37.347 UTC: Vi1 CCP: O CONFREQ [Closed] id 5 len 10 Jan 22 17:17:37.347 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020) Jan 22 17:17:37.351 UTC: Vi1 CCP: I CONFREQ [REQsent] id 5 len 10 Jan 22 17:17:37.351 UTC: Vi1 CCP: MS-PPC supported bits 0x010000B1 (0x1206010000B1) Jan 22 17:17:37.351 UTC: Vi1 CCP: O CONFNAK [REQsent] id 5 len 10 Jan 22 17:17:37.351 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020) Jan 22 17:17:37.351 UTC: Vi1 IPCP: I CONFREQ [REQsent] id 6 len 34 Jan 22 17:17:37.351 UTC: Vi1 IPCP: Address 0.0.0.0 (0x030600000000) Jan 22 17:17:37.351 UTC: Vi1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) Jan 22 17:17:37.351 UTC: Vi1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) Jan 22 17:17:37.355 UTC: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) Jan 22 17:17:37.355 UTC: Vi1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) Jan 22 17:17:37.355 UTC: Vi1 AAA/AUTHOR/IPCP: Start. Her address 0.0.0.0, we want 0.0.0.0 Jan 22 17:17:37.355 UTC: Vi1 AAA/AUTHOR/IPCP: Done. Her address 0.0.0.0, we want 0.0.0.0 Jan 22 17:17:37.355 UTC: Vi1 IPCP: Pool returned 192.168.2.1 Jan 22 17:17:37.355 UTC: Vi1 IPCP: O CONFREJ [REQsent] id 6 len 16 Jan 22 17:17:37.355 UTC: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) Jan 22 17:17:37.355 UTC: Vi1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) Jan 22 17:17:37.355 UTC: Vi1 IPCP: I CONFACK [REQsent] id 5 len 10 Jan 22 17:17:37.355 UTC: Vi1 IPCP: Address 192.168.1.1 (0x0306C0A80101) In highlighted line 1, the PPP phase changes state to UP. NCP negotiation is about to begin. Immediately after that, in highlighted line 2, CCP negotiation begins with the PAC sending a CONFREQ to the remote access client/PNS. Notice that this CONFREQ is used to request configuration of MS-PPC with supported bits 0x01000020. If you have read the section "MPPE Negotiation Failure," you will know that this indicates support for stateless encryption and 40-bit session keys. The remote access client/PNS then responds with a CONFREQ (highlighted line 3), again requesting configuration of MS-PPC but with supported bits 0x010000B1. These bits indicate support for stateless encryption, 56- and 40-bit session keys, and MS-PPC itself. The PAC then sends a CONFNACK in highlighted line 4, indicating that some of the options in the remote access client/PNS's CONFREQ (highlighted line 3) are recognized but not acceptable. The PAC again specifies supported bits 0x01000020 as a hint to the remote access client/PNS as to what would be acceptable (that is, stateless encryption and 40-bit session keys only). In Example 3-71 CCP negotiation continues. Example 3-71. CCP Negotiation ContinuesJan 22 17:17:37.355 UTC: Vi1 CCP: I CONFACK [REQsent] id 5 len 10 Jan 22 17:17:37.355 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020) Jan 22 17:17:37.359 UTC: Vi1 CCP: I CONFREQ [ACKrcvd] id 7 len 10 Jan 22 17:17:37.359 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020) Jan 22 17:17:37.359 UTC: Vi1 CCP: O CONFACK [ACKrcvd] id 7 len 10 Jan 22 17:17:37.359 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020) Jan 22 17:17:37.359 UTC: Vi1 CCP: State is Open In highlighted line 1 (Example 3-71), the remote access client/PNS continues CCP (MS-PPC/MPPE) negotiation by sending a CONFACK to acknowledge that stateless encryption and 40-bit session keys are acceptable. Then in highlighted line 2, the remote access client/PNS sends a CONFREQ, again specifying stateless encryption and 40-bit session keys, which the PAC acknowledges with a CONFACK in highlighted line 3. The CCP state then changes to Open. CCP has apparently been successfully negotiated. Unfortunately, PPP negotiation now fails, as shown in Example 3-72. Example 3-72. PPP Negotiation FailsJan 22 17:17:37.359 UTC: Vi1 CCP: O TERMREQ [Open] id 6 len 4 Jan 22 17:17:37.359 UTC: Vi1 PPP: Phase is TERMINATING [0 sess, 2 load] Jan 22 17:17:37.359 UTC: Vi1 IPCP: PPP phase is TERMINATING, discarding packet Jan 22 17:17:37.363 UTC: Vi1 CCP: PPP phase is TERMINATING, discarding packet Jan 22 17:17:37.371 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down Jan 22 17:17:37.371 UTC: Vi1 IPCP: State is Closed Jan 22 17:17:37.371 UTC: Vi1 CCP: State is Closed Jan 22 17:17:37.371 UTC: Vi1 MPPE: Required encryption not negotiated Jan 22 17:17:37.371 UTC: Vi1 LCP: O TERMREQ [Open] id 45 len 4 Jan 22 17:17:37.371 UTC: Vi1 LCP: State is Closed Jan 22 17:17:37.371 UTC: Vi1 PPP: Phase is DOWN [0 sess, 2 load] Jan 22 17:17:39.371 UTC: Vi1 LCP: Missed link down notification Jan 22 17:17:39.371 UTC: Vi1 LCP: State is Closed Arizona_PAC# Everything looked good until the PAC suddenly sends a TERMREQ (highlighted line 1 in Example 3-72). Things then start to go downhill at a rapid rate. In highlighted line 2, the PAC reports MPPE: Required encryption not negotiated. Finally, the PPP phase changes to DOWN in highlighted line 3. Why did the connection suddenly terminate? CCP (including MS-PPC/MPPE) was looking good, and then it all went wrong. Because MPPE attributes are configured on the RADIUS server, the debug radius command is used, as shown in Examples 3-73 to 3-74. Example 3-73. Output of the debug radius CommandArizona_PAC#debug radius Radius protocol debugging is on Arizona_PAC# Jan 22 17:24:22.882 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up Jan 22 17:24:24.905 UTC: RADIUS: ustruct sharecount=1 Jan 22 17:24:24.905 UTC: Radius: radius_port_info() success=1 radius_nas_port=1 Jan 22 17:24:24.905 UTC: RADIUS: Initial Transmit Virtual-Access1 id 27 192.168.1.2:1645, Access-Request, len 132 Jan 22 17:24:24.905 UTC: Attribute 4 6 C0A80101 Jan 22 17:24:24.909 UTC: Attribute 5 6 00000001 Jan 22 17:24:24.909 UTC: Attribute 61 6 00000005 Jan 22 17:24:24.909 UTC: Attribute 1 8 6D6A6C6E Jan 22 17:24:24.909 UTC: Attribute 26 16 000001370B0A26A4 Jan 22 17:24:24.909 UTC: Attribute 26 58 0000013701341C01 Jan 22 17:24:24.909 UTC: Attribute 6 6 00000002 Jan 22 17:24:24.909 UTC: Attribute 7 6 00000001 In highlighted line 1, virtual access interface 1 changes state to up. The remote access client/PNS is connected to the PAC. The PAC then sends an Access-Request message to the RADIUS server (highlighted line 2). This message is used to request authentication (and authorization) for the remote access client/PNS. It contains a number of attributes, which are listed below the highlighted line. These include the remote access client/PNS's username and password. In Example 3-74, the RADIUS server responds with an Access-Accept message. Example 3-74. RADIUS Server Responds with an Access-Accept MessageJan 22 17:24:24.921 UTC: RADIUS: Received from id 27 192.168.1.2:1645, Access-Accept, len 68 Jan 22 17:24:24.921 UTC: Attribute 6 6 00000002 Jan 22 17:24:24.921 UTC: Attribute 7 6 00000001 Jan 22 17:24:24.921 UTC: Attribute 8 6 FFFFFFFF Jan 22 17:24:24.921 UTC: Attribute 25 30 43495343 Jan 22 17:24:24.929 UTC: RADIUS: allowing negotiated framed address Jan 22 17:24:24.941 UTC: RADIUS: allowing negotiated framed address Jan 22 17:24:24.953 UTC: RADIUS: allowing negotiated framed address Jan 22 17:24:24.977 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down Arizona_PAC# The RADIUS server responds with the Access-Accept message indicating that authentication for the remote access client/PNS has succeeded (highlighted line 1, Example 3-74). A number of RADIUS attributes are also contained within this message, and they are listed in highlighted lines 2 to 5. These attributes (6, 7, 8, and 25) are Service-Type, Framed-Protocol, Framed-IP-Address, and Class. The attributes for MPPE that may be sent by the RADIUS server are as follows: vendor-specific attribute 26, vendor-ID 311 (Microsoft), with subattributes 007 (MS-MPPE-Encryption-Policy), 008 (MS-MPPE-Encryption-Types), 012 (MS-CHAP-MPPE-Keys), and optionally 016 (MS-MPPE-Send-Key) and 017 (MS-MPPE-Recv-Key). The problem here is that none of these Microsoft vendor-specific attributes are included in the Access-Accept message from the RADIUS server in Example 3-74. This is ultimately the reason for the PPP authentication failure. Now that the cause of the connection failure has been discovered, it is easy to resolve. The RADIUS server must be configured to supply MPPE attributes for the remote access client/PNS. In this case, a CiscoSecure ACS 3.0 server is being used, and although MPPE attributes have been configured under Interface Configuration, they have not been enabled in the group under which the user mjlnet has been configured. Under Group Configuration, Microsoft RADIUS attributes (vendor-specific attribute 26, vendor-ID 311) 007, 008, 012 are configured as shown in Figure 3-34. Figure 3-34. MPPE Attributes Under Group Configuration Note that subattribute 7 (MS-MPPE-Encryption-Policy) is used to specify whether an MPPE encryption policy is allowed or required. Subattribute 8 (MS-MPPE-Encryption-Types) is used to specify the types of encryption available (40 or 128-bit encryption). Subattribute 12 (MS-CHAP-MPPE-Keys) contains session keys used by MPPE. Finally, subattributes 17 and 16 specify session keys for encrypting packets sent to and from the PAC, respectively. Once the RADIUS server has been reconfigured, the remote access client/PNS successfully connects. This is verified using the show vpdn session all command, as shown in Example 3-75. Example 3-75. Verifying PPTP Session EstablishmentArizona_PAC#show vpdn session all %No active L2TP tunnels %No active L2F tunnels PPTP Session Information Total tunnels 1 sessions 1 Call id 11 is up on tunnel id 11 Remote tunnel name is Internet Address is 172.16.1.2 Session username is mjlnet, state is estabd Time since change 00:00:14, interface Vi1 Remote call id is 49152 22 packets sent, 37 received, 1362 bytes sent, 2986 received Ss 23, Sr 37, Remote Nr 22, peer RWS 64 0 out of order packets Flow alarm is clear. %No active PPPoE tunnels Arizona_PAC# As you can see, a remote access client/PNS with IP address 172.16.1.2 (highlighted line 1) has successfully established a PPTP tunnel with the PAC, and a session has been started with user mjlnet (highlighted line 2). NOTE Note that starting in Cisco IOS Software Release 12.2(4)T, RADIUS attributes are decoded in the output of the debug radius command. You can also use the Output Interpreter on the Cisco Web site to verify the meaning of the output of the debug radius command. The Output Interpreter is available at the following URL (requires a CCO account): https://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl For more details on Microsoft vendor-specific attributes, see RFC 2548. See also RFC 2865 for more information about RADIUS in general. Case Study 2: Split TunnelAlthough not a problem directly associated with a Cisco PAC or its configuration, this issue is briefly mentioned here because it is so often the cause of problems after a PPTP tunnel has been established from a Microsoft remote access client/PNS. A split tunnel is an issue that causes Microsoft remote access client/PNSs to lose Internet connectivity. After a PPTP tunnel has been established with the PAC, Microsoft remote access client/PNSs modify their routing tables so that the default route points to the PAC (via the tunnel) instead of pointing to the NAS to which the client established initial connectivity (that is, their ISP NAS). The solution to this issue is to modify the remote access client/PNS routing table so that the default route points to the NAS instead of the PAC. This can be accomplished using the following sequence of commands (on the Windows workstation). Example 3-76 shows the sequence of commands necessary to resolve the split tunnel issue on a Windows workstation. Example 3-76. Resolving a Split Tunnel Issue on Microsoft Remote Access Client/PNSroute delete 0.0.0.0 route add 0.0.0.0 mask 0.0.0.0 interface address metric 1 route add enterprise network mask net.mask tunnel interface address metric 1 Once these commands are entered, the remote access client/PNS will be able to both connect to hosts within the corporate (enterprise) network over the PPTP tunnel and to the Internet via its local ISP NAS. Note that you should always check your organization's security policy before implementing this solution. This solution might open a back door into your corporate network via your PPTP tunnel for other users on the Internet (that is, hackers). One possible way to prevent this is by installing a personal firewall on all remote access clients.  |
|
|
