CCNA Exploration: Accessing the WAN Chapter 2 Case Study
advertisement
CCNA Exploration: Accessing the WAN Chapter 2 Case Study Objectives: Troubleshooting PPP (LCP negotiation). Intro: Redish Inc. Is experiencing problems with its VPN access structure and called you for help. The Scenario: Redish Inc has a Cisco router (VPN-RTR) which is responsible for terminating all VPN sessions from remote users. Redish VPN structure uses PPP to encapsulate frames into a PPTP/GRE tunnel. The relevant portion of Redish Topology is shown below: Note: Even though PPTP and GRE tunnels are topics not fully covered up to this point in the course, the knowledge of such protocols is not vital when studying this document. PPTP/GRE tunnel was only mentioned here to build a more complete scenario. For more information on Cisco PPTP tunnels , please refer to: http://www.cisco.com/en/US/tech/tk827/tk369/technologies_configuration_example09186a00801e51e2.s html Topology: © 2009 Cisco Learning Institute CCNA Exploration: Accessing the WAN Chapter 2 Case Study Step 1 – Identifying the problem As you know, a virtual private network (VPN) is a computer network in which some of the links between nodes are carried by open connections or virtual circuits in some larger network (e.g., the Internet). The link-layer protocols of the virtual network are said to be tunneled through the larger network when this is the case. One common application is secure communications through the public Internet, but a VPN need not have explicit security features, such as authentication or content encryption. VPNs, for example, can be used to separate the traffic of different user communities over an underlying network with strong security features. For some reason Redish Inc. VPN is not working. Remote users trying to establish a VPN connection between their remote computers and VPN-RTR get an error back and no VPN is established. Redish Helpdesk staff enabled a few debug commands on VPN-RTR and added the output to the reports given to you. Since you have full debugs outputs on you, you decide to take a look at them before you go to Redish main office. The first thing that catches your eyes is an output of a debug ppp negotiation command. As stated on the reports, Redish uses Point to Point Tunnel Protocol (PPTP) and Generic Routing Encapsulation (GRE) to build a tunnel and Point to Point Protocol (PPP) to encapsulate the frames before sending them through the built tunnel. The first 12 lines of the debug ppp negotiation output reveal important information. The fact those 12 lines exist alone is already important. Such lines are shown below: Output 1: *May 28 22:05:26.143: ppp170 PPP: Send Message[Dynamic Bind Response] *May 28 22:05:26.143: ppp170 PPP: Using vpn set call direction *May 28 22:05:26.143: ppp170 PPP: Treating connection as a callin *May 28 22:05:26.147: ppp170 PPP: Session handle[FD0000A8] Session id[170] *May 28 22:05:26.147: ppp170 PPP: Phase is ESTABLISHING, Passive Open *May 28 22:05:26.147: ppp170 LCP: State is Listen *May 28 22:05:26.203: ppp170 LCP: I CONFREQ [Listen] id 0 len 21 *May 28 22:05:26.203: ppp170 LCP: MRU 1400 (0x01040578) *May 28 22:05:26.203: ppp170 LCP: MagicNumber 0x24C667BB (0x050624C667BB) *May 28 22:05:26.203: ppp170 LCP: PFC (0x0702) *May 28 22:05:26.203: ppp170 LCP: ACFC (0x0802) *May 28 22:05:26.203: ppp170 LCP: Callback 6 (0x0D0306) © 2009 Cisco Learning Institute CCNA Exploration: Accessing the WAN Chapter 2 Case Study Question 1: Why the existence of such 12 lines is so important? Answer: A PPTP/GRE tunnel, while being established, creates two channels: a data and a control channel. Redish employs PPP to encapsulate user data into the data channel. In PPTP tunnels, link-layer data encapsulation protocol negotiation (in this case PPP) only happens after PPTP/GRE tunnel is successfully established. The lines shown above show PPP-LCP already negotiating the link which means the PPTP tunnel was successfully established. Note: Even though Output 1, 2 and 3 are part of the same output, it was broken down in three parts to facilitate the troubleshooting. You decide to analyze the shown output and get even more important information: The first highlighted line shows VPN-RTR is hosting a session (receiving a connection) On the second highlighted line, PPP switches to establishing phase. LCP negotiation is about to begin. On the third highlighted line LCP already took control and started the link parameters negotiation and configuration. You move to the next section of the output. Starting by the point where LCP first took control, the section is shown below: Output 2: *May 28 22:05:26.147: ppp170 LCP: State is Listen *May 28 22:05:26.203: ppp170 LCP: I CONFREQ [Listen] id 0 len 21 *May 28 22:05:26.203: ppp170 LCP: MRU 1400 (0x01040578) *May 28 22:05:26.203: ppp170 LCP: MagicNumber 0x24C667BB (0x050624C667BB) *May 28 22:05:26.203: ppp170 LCP: PFC (0x0702) *May 28 22:05:26.203: ppp170 LCP: ACFC (0x0802) *May 28 22:05:26.203: ppp170 LCP: Callback 6 (0x0D0306) *May 28 22:05:26.203: ppp170 LCP: O CONFREQ [Listen] id 1 len 15 *May 28 22:05:26.203: ppp170 LCP: AuthProto MS-CHAP (0x0305C22380) *May 28 22:05:26.203: ppp170 LCP: MagicNumber 0x1A5E1754 (0x05061A5E1754) *May 28 22:05:26.203: ppp170 LCP: O CONFREJ [Listen] id 0 len 7 *May 28 22:05:26.203: ppp170 LCP: Callback 6 (0x0D0306) © 2009 Cisco Learning Institute CCNA Exploration: Accessing the WAN Chapter 2 Case Study *May 28 22:05:26.207: ppp170 LCP: I CONFNAK [REQsent] id 1 len 9 *May 28 22:05:26.207: ppp170 LCP: AuthProto MS-CHAP-V2 (0x0305C22381) *May 28 22:05:26.207: ppp170 LCP: O CONFREQ [REQsent] id 2 len 15 *May 28 22:05:26.207: ppp170 LCP: AuthProto MS-CHAP (0x0305C22380) *May 28 22:05:26.207: ppp170 LCP: MagicNumber 0x1A5E1754 (0x05061A5E1754) *May 28 22:05:26.219: ppp170 LCP: I CONFNAK [REQsent] id 2 len 9 *May 28 22:05:26.219: ppp170 LCP: AuthProto MS-CHAP-V2 (0x0305C22381) *May 28 22:05:26.219: ppp170 LCP: O CONFREQ [REQsent] id 3 len 15 *May 28 22:05:26.219: ppp170 LCP: AuthProto MS-CHAP (0x0305C22380) *May 28 22:05:26.219: ppp170 LCP: MagicNumber 0x1A5E1754 (0x05061A5E1754) The first highlighted line shows the router received an incoming (letter I) Configure-Request (CONFREQ) from the client. The following 5 indented lines represent the options supported and desired by the client: - MRU (Maximum Receive Unit) allows a peer to advertise its maximum receive unit Magic Number is a random number used to detect error conditions such as looped back lines PFC (Protocol Field Compression) indicates the client is able to receive compressed PPP protocol fields ACFC (Address and Control Fields Compression) indicates the client would like to receive PPP frames without the leading HDLC address and control fields Callback indicated the client supports callback feature. This feature allows the server to dial back to a client and assume the costs of the call. Cisco routers don’t implement this feature. Note: The hexadecimal numbers in parentheses are the actual values sent in the PPP frames’ fields. The second highlighted line shows the router sent and outgoing (O) Configuration-Request to the client. Once more the 2 following indented lines represent the options sent into the CONFREQ message: - AuthProto (authentication protocol) indicates the VPN server (the router) wants to use MS-CHAP as authentication protocol. MagicNumber generated by the server. Right after this CONFREQ message, the server sends out an outgoing message (O) Configure-Reject (CONFREJ) regarding a prior received CONFREQ. A CONFREJ message is used by LCP to indicate which suggested options were not understood or are not supported. The third highlighted line on output 2 shows the CONFREJ message and the following indented line the parameters it carries. © 2009 Cisco Learning Institute CCNA Exploration: Accessing the WAN Chapter 2 Case Study In this case, the router VPN-RTR (a Cisco router) communicates to the client it doesn’t support the PPP callback feature. The fourth highlighted line in output 2 shows LCP in router receiving a Configuration Not-Acknowledged (CONFNACK) message from the client. A CONFNACK message is used to communicate to the other peer about a non-supported option and suggest a different an alternative. In this case, the client uses a CONFNACK message to communicate MS-CHAP is not supported as authentication protocol by it to the server while at the same time suggesting the use of MS-CHAP-V2 instead of MS-CHAP. Question 2: What is the main difference between a CONFREJ PPP message and a CONFNACK PPP message? Answer: CONFREJ messages disagree about a specific parameter and don’t suggest an alternate option. CONFNAK messages also disagree about parameters being negotiated but suggest an alternate option. On the fifth highlighted line the router VPN-RTR (the VPN server) send out an outgoing (O) CONFREQ message, one more time indicating it want to use MS-CHAP as the authentication protocol. On the sixth highlighted line of output 2 the client, once more, replies with a CONFNAK message indicating it doesn’t support MS-CHAP and signals the client’s desire to use MS-CHAP-V2 as the authentication protocol. The rest of the output shows these messages being exchanged a few more times and since client and server couldn’t find an authentication protocol they both simultaneously support, LCP finally terminates the connection. Below is the portion of the output where LCP drops the connection: Output 3: *May 28 22:05:26.235: ppp170 LCP: O CONFREQ [ACKsent] id 10 len 15 *May 28 22:05:26.235: ppp170 LCP: AuthProto MS-CHAP (0x0305C22380) *May 28 22:05:26.235: ppp170 LCP: MagicNumber 0x1A5E1754 (0x05061A5E1754) *May 28 22:05:26.235: ppp170 LCP: I CONFNAK [ACKsent] id 10 len 9 *May 28 22:05:26.235: ppp170 LCP: AuthProto MS-CHAP-V2 (0x0305C22381) *May 28 22:05:26.235: ppp170 LCP: Failed to negotiate with peer *May 28 22:05:26.235: ppp170 PPP: Sending Acct Event[Down] id[AE] *May 28 22:05:26.235: ppp170 LCP: O TERMREQ [ACKsent] id 11 len 4 *May 28 22:05:26.235: ppp170 PPP: Phase is TERMINATING © 2009 Cisco Learning Institute CCNA Exploration: Accessing the WAN Chapter 2 Case Study *May 28 22:05:26.235: ppp170 LCP: I TERMACK [TERMsent] id 11 len 4 *May 28 22:05:26.235: ppp170 LCP: State is Closed *May 28 22:05:26.239: ppp170 PPP: Phase is DOWN *May 28 22:05:26.239: ppp170 PPP: Send Message[Disconnect] Step 2 – The Solution After analyzing the Redish Inc. reports, the problem becomes clear: The endpoints of the VPN connection (server and client) are not able to find an authentication protocol which both ends support and the connection is terminated. When you get to Redish main office, you already know what the problem is. After a quick conversation with Redish IT staff, you learn the rather have MS-CHAP-V2 than MS-CHAP running on their VPNs. You connect your laptop to the VPN-RTR console port and change the authentication protocol configured in the router. The commands are listed below for future reference: VPN-RTR(config)# interface Virtual-Template1 VPN-RTR(config-if)# no ppp authentication ms-chap VPN-RTR(config-if)# ppp authentication ms-chap-v2 Once the commands are entered you enable the command debug ppp negotiation again and try to establish a VPN from your laptop. The VPN is successfully established this time. The output presented on the console window is listed below for future reference: *May 29 18:24:55.887: ppp7 PPP: Send Message[Dynamic Bind Response] *May 29 18:24:55.887: ppp7 PPP: Using vpn set call direction *May 29 18:24:55.887: ppp7 PPP: Treating connection as a callin *May 29 18:24:55.887: ppp7 PPP: Session handle[3400000D] Session id[7] *May 29 18:24:55.887: ppp7 PPP: Phase is ESTABLISHING, Passive Open *May 29 18:24:55.887: ppp7 LCP: State is Listen *May 29 18:24:55.895: ppp7 LCP: I CONFREQ [Listen] id 0 len 21 *May 29 18:24:55.895: ppp7 LCP: MRU 1400 (0x01040578) *May 29 18:24:55.895: ppp7 LCP: MagicNumber 0x163B146D (0x0506163B146D) *May 29 18:24:55.895: ppp7 LCP: PFC (0x0702) © 2009 Cisco Learning Institute CCNA Exploration: Accessing the WAN Chapter 2 Case Study *May 29 18:24:55.895: ppp7 LCP: ACFC (0x0802) *May 29 18:24:55.895: ppp7 LCP: Callback 6 (0x0D0306) *May 29 18:24:55.895: ppp7 LCP: O CONFREQ [Listen] id 1 len 15 *May 29 18:24:55.895: ppp7 LCP: AuthProto MS-CHAP-V2 (0x0305C22381) *May 29 18:24:55.899: ppp7 LCP: MagicNumber 0x1A77A3F9 (0x05061A77A3F9) *May 29 18:24:55.899: ppp7 LCP: O CONFREJ [Listen] id 0 len 7 *May 29 18:24:55.899: ppp7 LCP: Callback 6 (0x0D0306) *May 29 18:24:55.899: ppp7 LCP: I CONFACK [REQsent] id 1 len 15 *May 29 18:24:55.899: ppp7 LCP: AuthProto MS-CHAP-V2 (0x0305C22381) *May 29 18:24:55.899: ppp7 LCP: MagicNumber 0x1A77A3F9 (0x05061A77A3F9) *May 29 18:24:55.899: ppp7 LCP: I CONFREQ [ACKrcvd] id 1 len 18 *May 29 18:24:55.899: ppp7 LCP: MRU 1400 (0x01040578) *May 29 18:24:55.899: ppp7 LCP: MagicNumber 0x163B146D (0x0506163B146D) *May 29 18:24:55.899: ppp7 LCP: PFC (0x0702) *May 29 18:24:55.899: ppp7 LCP: ACFC (0x0802) *May 29 18:24:55.899: ppp7 LCP: O CONFNAK [ACKrcvd] id 1 len 8 *May 29 18:24:55.899: ppp7 LCP: MRU 1500 (0x010405DC) *May 29 18:24:55.899: ppp7 LCP: I CONFREQ [ACKrcvd] id 2 len 18 *May 29 18:24:55.899: ppp7 LCP: MRU 1400 (0x01040578) *May 29 18:24:55.903: ppp7 LCP: MagicNumber 0x163B146D (0x0506163B146D) *May 29 18:24:55.903: ppp7 LCP: PFC (0x0702) *May 29 18:24:55.903: ppp7 LCP: ACFC (0x0802) *May 29 18:24:55.903: ppp7 LCP: O CONFNAK [ACKrcvd] id 2 len 8 *May 29 18:24:55.903: ppp7 LCP: MRU 1500 (0x010405DC) *May 29 18:24:55.903: ppp7 LCP: I CONFREQ [ACKrcvd] id 3 len 18 *May 29 18:24:55.903: ppp7 LCP: MRU 1500 (0x010405DC) *May 29 18:24:55.903: ppp7 LCP: MagicNumber 0x163B146D (0x0506163B146D) *May 29 18:24:55.903: ppp7 LCP: PFC (0x0702) © 2009 Cisco Learning Institute CCNA Exploration: Accessing the WAN Chapter 2 Case Study *May 29 18:24:55.903: ppp7 LCP: ACFC (0x0802) *May 29 18:24:55.903: ppp7 LCP: O CONFACK [ACKrcvd] id 3 len 18 *May 29 18:24:55.903: ppp7 LCP: MRU 1500 (0x010405DC) *May 29 18:24:55.903: ppp7 LCP: MagicNumber 0x163B146D (0x0506163B146D) *May 29 18:24:55.903: ppp7 LCP: PFC (0x0702) *May 29 18:24:55.903: ppp7 LCP: ACFC (0x0802) *May 29 18:24:55.903: ppp7 LCP: State is Open *May 29 18:24:55.903: ppp7 PPP: Phase is AUTHENTICATING, by this end *May 29 18:24:55.903: ppp7 MS-CHAP-V2: O CHALLENGE id 1 len 23 from "VPN-RTR" *May 29 18:24:55.907: ppp7 LCP: I IDENTIFY [Open] id 4 len 18 magic 0x163B146D M SRASV5.10 *May 29 18:24:55.907: ppp7 LCP: I IDENTIFY [Open] id 5 len 29 magic 0x163B146D M SRAS-0-RFLORIANO-CLI *May 29 18:24:55.907: ppp7 MS-CHAP-V2: I RESPONSE id 1 len 61 from "rem-user1" *May 29 18:24:55.907: ppp7 PPP: Phase is FORWARDING, Attempting Forward *May 29 18:24:55.907: ppp7 PPP: Phase is AUTHENTICATING, Unauthenticated User *May 29 18:24:55.923: ppp7 PPP: Phase is FORWARDING, Attempting Forward *May 29 18:24:55.923: ppp7 PPP: Send Message[Connect Local] *May 29 18:24:55.923: Vi3 PPP: Phase is DOWN, Setup *May 29 18:24:55.927: ppp7 PPP: Bind to [Virtual-Access3] *May 29 18:24:55.927: Vi3 PPP: Send Message[Static Bind Response] *May 29 18:24:55.931: %LINK-3-UPDOWN: Interface Virtual-Access3, changed state t o up *May 29 18:24:55.931: Vi3 PPP: Phase is AUTHENTICATING, Authenticated User *May 29 18:24:55.931: Vi3 MS-CHAP-V2: O SUCCESS id 1 len 46 msg is "S=53DC7F42D6 75C5FA2A6BAFB30EAA0E9A0100B0A3" *May 29 18:24:55.931: Vi3 PPP: Phase is UP *May 29 18:24:55.931: Vi3 IPCP: O CONFREQ [Closed] id 1 len 10 © 2009 Cisco Learning Institute CCNA Exploration: Accessing the WAN Chapter 2 Case Study *May 29 18:24:55.931: Vi3 IPCP: Address 192.168.171.52 (0x0306C0A8AB34) *May 29 18:24:55.931: Vi3 CCP: O CONFREQ [Closed] id 1 len 10 *May 29 18:24:55.931: Vi3 CCP: MS-PPC supported bits 0x01000020 (0x1206010000 20) *May 29 18:24:55.931: Vi3 PPP: Process pending ncp packets *May 29 18:24:55.939: Vi3 CCP: I CONFREQ [REQsent] id 6 len 10 *May 29 18:24:55.939: Vi3 CCP: MS-PPC supported bits 0x010000E1 (0x1206010000 E1) *May 29 18:24:55.939: Vi3 CCP: O CONFNAK [REQsent] id 6 len 10 *May 29 18:24:55.939: Vi3 CCP: MS-PPC supported bits 0x01000020 (0x1206010000 20) *May 29 18:24:55.939: Vi3 CCP: I CONFACK [REQsent] id 1 len 10 *May 29 18:24:55.939: Vi3 CCP: MS-PPC supported bits 0x01000020 (0x1206010000 20) *May 29 18:24:55.939: Vi3 IPCP: I CONFREQ [REQsent] id 7 len 34 *May 29 18:24:55.939: Vi3 IPCP: Address 0.0.0.0 (0x030600000000) *May 29 18:24:55.939: Vi3 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) *May 29 18:24:55.939: Vi3 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) *May 29 18:24:55.939: Vi3 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) *May 29 18:24:55.939: Vi3 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) *May 29 18:24:55.939: Vi3 IPCP: Pool returned 10.0.0.1 *May 29 18:24:55.939: Vi3 IPCP: O CONFREJ [REQsent] id 7 len 28 *May 29 18:24:55.939: Vi3 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) *May 29 18:24:55.939: Vi3 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) *May 29 18:24:55.939: Vi3 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) *May 29 18:24:55.939: Vi3 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) *May 29 18:24:55.939: Vi3 IPCP: I CONFACK [REQsent] id 1 len 10 *May 29 18:24:55.939: Vi3 IPCP: Address 192.168.171.52 (0x0306C0A8AB34) © 2009 Cisco Learning Institute CCNA Exploration: Accessing the WAN Chapter 2 Case Study *May 29 18:24:55.943: Vi3 CCP: I CONFREQ [ACKrcvd] id 8 len 10 *May 29 18:24:55.943: Vi3 CCP: MS-PPC supported bits 0x01000020 (0x1206010000 20) *May 29 18:24:55.943: Vi3 CCP: O CONFACK [ACKrcvd] id 8 len 10 *May 29 18:24:55.943: Vi3 CCP: MS-PPC supported bits 0x01000020 (0x1206010000 20) *May 29 18:24:55.943: Vi3 CCP: State is Open *May 29 18:24:55.943: Vi3 IPCP: I CONFREQ [ACKrcvd] id 9 len 10 *May 29 18:24:55.943: Vi3 IPCP: Address 0.0.0.0 (0x030600000000) *May 29 18:24:55.943: Vi3 IPCP: O CONFNAK [ACKrcvd] id 9 len 10 *May 29 18:24:55.943: Vi3 IPCP: Address 10.0.0.1 (0x03060A000001) *May 29 18:24:55.947: Vi3 IPCP: I CONFREQ [ACKrcvd] id 10 len 10 *May 29 18:24:55.947: Vi3 IPCP: Address 10.0.0.1 (0x03060A000001) *May 29 18:24:55.947: Vi3 IPCP: O CONFACK [ACKrcvd] id 10 len 10 *May 29 18:24:55.947: Vi3 IPCP: Address 10.0.0.1 (0x03060A000001) *May 29 18:24:55.947: Vi3 IPCP: State is Open *May 29 18:24:55.947: Vi3 IPCP: Install route to 10.0.0.1 *May 29 18:24:56.931: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Ac cess3, changed state to up © 2009 Cisco Learning Institute
