Troubleshooting vpn

1. Table of Contents 1Troubleshooting Virtual Private Networks ........................................................................................................................ 2Table of Contents ................................................................................................................................................................................. 4Copyright ..................................................................................................................................................................................................... 7About the Author ................................................................................................................................................................................... 8About the Technical Reviewers .................................................................................................................................................... 9Acknowledgments ................................................................................................................................................................................ 10Icons Used in This Book .............................................................................................................................................................. 11Command Syntax Conventions .............................................................................................................................................. 12Introduction ............................................................................................................................................................................................. 13Motivation for the Book ................................................................................................................................................................. 14Audience .............................................................................................................................................................................................. 15Organization ...................................................................................................................................................................................... 17Chapter 1. Basic Troubleshooting Methodology ..................................................................................................... 18Preparatory Steps: Baselining Your Network ....................................................................................................................... 19What to Do When Problems Occur ......................................................................................................................................... 20Open Systems Interconnection Model ................................................................................................................................... 21End-to-End, Bottom-Up (or Top-Down) Troubleshooting ................................................................................................ 23Troubleshooting Tools .................................................................................................................................................................... 25Summary ............................................................................................................................................................................................. 26Chapter 2. Troubleshooting Layer Two Forwarding Protocol VPNs ........................................................ 27Technical Overview of L2F .......................................................................................................................................................... 44Configuring L2F ................................................................................................................................................................................ 55Troubleshooting L2F ....................................................................................................................................................................... 94Case Studies ..................................................................................................................................................................................... 111Additional Commands for Troubleshooting ........................................................................................................................ 115Error Messages .............................................................................................................................................................................. 118show and debug Command Summary ................................................................................................................................ 119Review Questions ......................................................................................................................................................................... 120Troubleshooting Practice Labs ............................................................................................................................................... 123Chapter 3. Troubleshooting Point-to-Point Tunneling Protocol VPNs ................................................ 125Technical Overview of PPTP .................................................................................................................................................. 140Configuring PPTP ........................................................................................................................................................................ 145Troubleshooting PPTP ............................................................................................................................................................... 170Case Studies .................................................................................................................................................................................. 175Additional Troubleshooting Commands .............................................................................................................................. 180show and debug Command Summary ................................................................................................................................ 181Review Questions ........................................................................................................................................................................ 182Chapter 4. Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs ............................. 185L2TPv2 Technical Overview .................................................................................................................................................... 251Case Studies .................................................................................................................................................................................. 272Additional L2TP Troubleshooting Commands .................................................................................................................. 277Error Messages ............................................................................................................................................................................. 280%VPDN-6-DOWN ........................................................................................................................................................................ 281show and debug Command Summary ................................................................................................................................ 282Review Questions ........................................................................................................................................................................ 283L2TP Troubleshooting Practice Labs ................................................................................................................................... 286Chapter 5. Troubleshooting L2TPv3 Based VPNs ............................................................................................. 288Technical Overview of L2TPv3 .............................................................................................................................................. 303Configuring L2TPv3 .................................................................................................................................................................... 313Troubleshooting L2TPv3 ...........................................................................................................................................................

2. 329Other Commands ......................................................................................................................................................................... 335Command Summary ................................................................................................................................................................... 336Review Questions ........................................................................................................................................................................ 337Chapter 6. Troubleshooting Multiprotocol Label Switching Layer 3 VPNs ..................................... 339Technical Overview ..................................................................................................................................................................... 356Configuring MPLS VPNs ........................................................................................................................................................... 368Configuring MVPNs ..................................................................................................................................................................... 372Configuring TE Tunnels to Carry MPLS VPN Traffic .................................................................................................... 377Troubleshooting MPLS VPNs .................................................................................................................................................. 429Case Studies .................................................................................................................................................................................. 447Additional Troubleshooting Commands .............................................................................................................................. 454show and debug Command Summary ................................................................................................................................ 457Review Questions ........................................................................................................................................................................ 458MPLS VPN Troubleshooting Practice Labs ....................................................................................................................... 461Chapter 7. Troubleshooting Any Transport over MPLS Based VPNs ................................................. 462Technical Overview of AToM ................................................................................................................................................... 470Configuring AToM ......................................................................................................................................................................... 484Troubleshooting AToM ................................................................................................................................................................ 516Other AToM Troubleshooting Commands .......................................................................................................................... 521Troubleshooting AToM: Command Summary .................................................................................................................. 523Review Questions ........................................................................................................................................................................ 524Chapter 8. Troubleshooting IPSec VPNs .................................................................................................................. 525Technical Overview of IPSec .................................................................................................................................................. 536Configuring IPSec VPNs ........................................................................................................................................................... 553Troubleshooting IPSec VPNs .................................................................................................................................................. 586Case Studies .................................................................................................................................................................................. 595Additional Troubleshooting Commands .............................................................................................................................. 599show and debug Command Summary ................................................................................................................................ 600Review Questions ........................................................................................................................................................................ 601Practice Labs .................................................................................................................................................................................. 604Appendix A. Review Questions and Answers ......................................................................................................... 605Chapter 2 Review Questions & Answers ............................................................................................................................ 606Chapter 3 Review Questions & Answers ............................................................................................................................ 608Chapter 4 Review Questions & Answers ............................................................................................................................ 609Chapter 5 Review Questions & Answers ............................................................................................................................ 610Chapter 6 Review Questions & Answers ............................................................................................................................ 611Chapter 7 Review Questions & Answers ............................................................................................................................ 612Chapter 8 Review Questions & Answers ............................................................................................................................ 613Appendix B. Lab Instructions and Solutions ............................................................................................................ 614Setting Up Your Routers and Loading the Configuration Files ................................................................................. 618Chapter 2: L2F Troubleshooting Lab Solutions ............................................................................................................... 619Chapter 4: L2TPv2 Troubleshooting Lab Solutions ....................................................................................................... 620Chapter 6: MPLS Layer 3 VPN Troubleshooting Lab Solutions ............................................................................... 621Chapter 8: IPSec Troubleshooting Lab Solutions ........................................................................................................... 622Index ......................................................................................................................................................................................................... 623SYMBOL ........................................................................................................................................................................................... 624A ........................................................................................................................................................................................................... 627B ........................................................................................................................................................................................................... 628C .......................................................................................................................................................................................................... 632D .......................................................................................................................................................................................................... 635E ........................................................................................................................................................................................................... 637F ........................................................................................................................................................................................................... 638G .......................................................................................................................................................................................................... 639H .......................................................................................................................................................................................................... 3. 640I ............................................................................................................................................................................................................ 642K ........................................................................................................................................................................................................... 643L ........................................................................................................................................................................................................... 645M .......................................................................................................................................................................................................... 648N .......................................................................................................................................................................................................... 649O .......................................................................................................................................................................................................... 650P ........................................................................................................................................................................................................... 653Q .......................................................................................................................................................................................................... 654R .......................................................................................................................................................................................................... 656S ........................................................................................................................................................................................................... 660T ........................................................................................................................................................................................................... 661U .......................................................................................................................................................................................................... 662V ........................................................................................................................................................................................................... 664W ......................................................................................................................................................................................................... 665Z ........................................................................................................................................................................................................... 4. Troubleshooting Virtual Private Networks By Mark Lewis ............................................... Publisher: Cisco Press Pub Date: May 27, 2004 Print ISBN: 1-58705-104-4 Pages: 840 Table of Contents | Index Master advanced troubleshooting techniques for IPSec, MPLS Layer-3, MPLS Layer-2 (AToM), L2TPv3, L2TPv2, PPTP, and L2F VPNs Learn the step-by-step, end-to-end methodology essential for troubleshooting virtual private networks (VPNs) Gain the in-depth knowledge necessary for fast and efficient troubleshooting of IPSec, MPLS Layer-3, MPLS Layer-2 (AToM), L2TPv3, L2TPv2, PPTP, and L2F VPNs Master advanced troubleshooting tools and techniques for all applicable VPN types Debug and fix IPSec site-to-site and remote access VPN issues, such as IKE (ISAKMP) phase 1 and phase 2 negotiation failure, ESP and AH traffic drops, certificate enrollment failures, and maximum transmission unit (MTU) problems Locate and resolve MPLS Layer-3 VPN problems, such as those involving route exchange and label switched path (LSP) failure, MPLS VPN over traffic engineering tunnels, and Multicast VPNs (MVPN) Discover solutions for issues in AToM and L2TPv3-based Layer-2 VPNs, including pseudowire setup failures, attachment circuit problems, and MTU issues Obtain answers for L2TPv2, PPTP, and L2F control connection establishment, session setup, PPP negotiation, and VPN performance issues Refer to specially designed flowcharts to identify issues and find solutions fast Consolidate VPN troubleshooting knowledge through bonus hands-on labs Read and understand detailed analysis of all relevant VPN show and debug command output Troubleshooting Virtual Private Networks presents a systematic troubleshooting methodology for network engineers, administrators, and architects tasked with managing and deploying Cisco IOS VPNs. With eight self-contained chapters designed to facilitate rapid and straightforward troubleshooting, this book provides detailed information on addressing all common and not-so-common issues with IPSec VPNs, MPLS Layer-3 VPNs, Any Transport over MPLS (AToM)-based Layer-2 VPNs, L2TP Version 3 (L2TPv3)-based Layer-2 VPNs, L2TP Version 2 (L2TPv2) VPNs, PPTP VPNs, and L2F VPNs. This book not only shows you how to correct problems but also how to avoid them in the first place with expert VPN configuration guidance and optimization tips. Each chapter in Troubleshooting Virtual Private Networks includes a step-by-step, end-to-end troubleshooting approach to a different VPN technology. In-depth technical discussions and configuration reviews orient you to the VPN technology and get you ready to work. To help you access the answers you need, you'll find flowcharts in each chapter that provide a roadmap for rapid issue resolution. Solutions to complex or unusual issues can be found in case studies at the end of each chapter, along with review questions that test your knowledge. Bonus troubleshooting labs are also included to help you consolidate the skills learned throughout the book. Whether you are looking to update or hone your skills, Troubleshooting Virtual Private Networks is your first and last reference for mastering advanced VPN troubleshooting. This book is part of the Networking Technology Series from Cisco Press which offers networking professionals valuable information for constructing efficient networks, understanding new technologies, and building successful careers. Troubleshooting Virtual Private Networks 1 / 665 5. Troubleshooting Virtual Private Networks By Mark Lewis ............................................... Publisher: Cisco Press Pub Date: May 27, 2004 Print ISBN: 1-58705-104-4 Pages: 840 Table of Contents | Index Copyright About the Author About the Technical Reviewers Acknowledgments Icons Used in This Book Command Syntax Conventions Introduction Motivation for the Book Audience Organization Chapter 1. Basic Troubleshooting Methodology Preparatory Steps: Baselining Your Network What to Do When Problems Occur Open Systems Interconnection Model End-to-End, Bottom-Up (or Top-Down) Troubleshooting Troubleshooting Tools Summary Chapter 2. Troubleshooting Layer Two Forwarding Protocol VPNs Technical Overview of L2F Configuring L2F Troubleshooting L2F Case Studies Additional Commands for Troubleshooting Error Messages show and debug Command Summary Review Questions Troubleshooting Practice Labs Chapter 3. Troubleshooting Point-to-Point Tunneling Protocol VPNs Technical Overview of PPTP Configuring PPTP Troubleshooting PPTP Case Studies Additional Troubleshooting Commands show and debug Command Summary Review Questions Chapter 4. Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs L2TPv2 Technical Overview Case Studies Additional L2TP Troubleshooting Commands Error Messages %VPDN-6-DOWN show and debug Command Summary Review Questions L2TP Troubleshooting Practice Labs Chapter 5. Troubleshooting L2TPv3 Based VPNs Technical Overview of L2TPv3 Configuring L2TPv3 Troubleshooting Virtual Private Networks 2 / 665 6. Troubleshooting L2TPv3 Other Commands Command Summary Review Questions Chapter 6. Troubleshooting Multiprotocol Label Switching Layer 3 VPNs Technical Overview Configuring MPLS VPNs Configuring MVPNs Configuring TE Tunnels to Carry MPLS VPN Traffic Troubleshooting MPLS VPNs Case Studies Additional Troubleshooting Commands show and debug Command Summary Review Questions MPLS VPN Troubleshooting Practice Labs Chapter 7. Troubleshooting Any Transport over MPLS Based VPNs Technical Overview of AToM Configuring AToM Troubleshooting AToM Other AToM Troubleshooting Commands Troubleshooting AToM: Command Summary Review Questions Chapter 8. Troubleshooting IPSec VPNs Technical Overview of IPSec Configuring IPSec VPNs Troubleshooting IPSec VPNs Case Studies Additional Troubleshooting Commands show and debug Command Summary Review Questions Practice Labs AppendixA. Review Questions and Answers Chapter 2 Review Questions & Answers Chapter 3 Review Questions & Answers Chapter 4 Review Questions & Answers Chapter 5 Review Questions & Answers Chapter 6 Review Questions & Answers Chapter 7 Review Questions & Answers Chapter 8 Review Questions & Answers Appendix B. Lab Instructions and Solutions Setting Up Your Routers and Loading the Configuration Files Chapter 2: L2F Troubleshooting Lab Solutions Chapter 4: L2TPv2 Troubleshooting Lab Solutions Chapter 6: MPLS Layer 3 VPN Troubleshooting Lab Solutions Chapter 8: IPSec Troubleshooting Lab Solutions Index Troubleshooting Virtual Private Networks 3 / 665 7. Copyright Copyright 2004 Cisco Systems, Inc. Published by: Cisco Press 800 East 96th Street Indianapolis, IN 46240 USA All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without written permission from the publisher, except for the inclusion of brief quotations in a review. Printed in the United States of America 1 2 3 4 5 6 7 8 9 0 First Printing June 2004 Library of Congress Cataloging-in-Publication Number: 2002104703 Warning and Disclaimer This book is designed to provide information about troubleshooting virtual private networks. Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. The information is provided on an "as is" basis. The authors, Cisco Press, and Cisco Systems, Inc. shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book or from the use of the discs or programs that may accompany it. The opinions expressed in this book belong to the author and are not necessarily those of Cisco Systems, Inc. Trademark Acknowledgments All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Cisco Press or Cisco Systems, Inc. cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark. Feedback Information At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each book is crafted with care and precision, undergoing rigorous development that involves the unique expertise of members from the professional technical community. Readers' feedback is a natural continuation of this process. If you have any comments regarding how we could improve the quality of this book, or otherwise alter it to better suit your needs, you can contact us through e-mail at [email protected]. Please make sure to include the book title and ISBN in your message. We greatly appreciate your assistance. Corporate and Government Sales Troubleshooting Virtual Private Networks 4 / 665 8. Cisco Press offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales. For more information please contact: U.S. Corporate and Government Sales 1-800-382-3419 [email protected] For sales outside the U.S. please contact: International Sales [email protected] Credits Publisher John Wait Editor-in-Chief John Kane Executive Editor Brett Bartow Cisco Representative Anthony Wolfenden Cisco Press Program Manager Sonia Torres Chavez Acquisitions Editor Michelle Grandin Production Manager Patrick Kanouse Development Editor Christopher Cleveland Project Editor Marc Fowler Copy Editor Ginny Kaczmarek Technical Editors Henry Benjamin, Robert Brown, Nathan Lohr, Andrew Makin, van Pepelnjak, Tim Sammut, Wen Zhang Team Coordinator Tammi Barnett Book Designer Louisa Adair Cover Designer Louisa Adair Composition Argosy Indexer Larry Sweazy Corporate Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA95134-1706 USA www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 526-4100 European Headquarters Cisco Systems International BV Haarlerbergpark Haarlerbergweg 3-19 1101 CH Amsterdam Troubleshooting Virtual Private Networks 5 / 665 9. The Netherlands www-europe.cisco.com Tel: 31 0 20 357 1000 Fax: 31 0 20 357 1100 Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA95134-1706 USA www.cisco.com Tel: 408 526-7660 Fax: 408 527-0883 Asia Pacific Headquarters Cisco Systems, Inc. Capital Tower 168 Robinson Road #22-01 to #29-01 Singapore 068912 www.cisco.com Tel: +65 6317 7777 Fax: +65 6317 7799 Cisco Systems has more than 200 offices in the following countries and regions. Addresses, phone numbers, and fax numbers are listed on the Cisco.com Web site at www.cisco.com/go/offices. Argentina Australia Austria Belgium Brazil Bulgaria Canada Chile China PRC Colombia Costa Rica Croatia Czech Republic Denmark Dubai, UAE Finland France Germany Greece Hong Kong SAR Hungary India Indonesia Ireland Israel Italy Japan Korea Luxembourg Malaysia Mexico The Netherlands New Zealand Norway Peru Philippines Poland Portugal Puerto Rico Romania Russia Saudi Arabia Scotland Singapore Slovakia Slovenia South Africa Spain Sweden Switzerland Taiwan Thailand Turkey Ukraine United Kingdom United States Venezuela Vietnam Zimbabwe Copyright 2003 Cisco Systems, Inc. All rights reserved. CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, the Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing, FormShare, iQ Net Readiness Scorecard, Networking Academy, and ScriptShare are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, The Fastest Way to Increase Your Internet Quotient, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, LightStream, MGX, MICA, the Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast, SMARTnet, Strata View Plus, Stratm, SwitchProbe, TeleRouter, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries. All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0303R) Printed in the USA Troubleshooting Virtual Private Networks 6 / 665 10. About the Author Mark Lewis, CCIE No. 6280, is technical director of MJL Network Solutions (www.mjlnet.com), a leading provider of internetworking solutions that focuses on helping service and enterprise provider customers to implement cutting edge technologies, deploy security solutions, and optimize their networks, as well as providing them with advanced training. Mark specializes in VPN technologies and has many years of experience designing, implementing, and troubleshooting IP networks. He is also an MCSE+I and a certified Cisco Systems instructor. Mark can be contacted at [email protected]. Troubleshooting Virtual Private Networks 7 / 665 11. About the Technical Reviewers Henry Benjamin, CCIE No. 4695, holds three CCIE certifications (Routing and Switching, ISP Dial, and Communications and Services). He has more than 10 years experience with Cisco networks and recently worked for Cisco in the internal IT department helping to design and implement networks throughout Australia and Asia. Henry was a key member of the CCIE global team, where he was responsible for writing new laboratory examinations and questions for the CCIE exams. Henry is an independent consultant with a large security firm in Australia. Robert Brown, CCIE No. 7309, is developer and technical leader of Cisco Output Interpreter, a powerful online troubleshooting tool that diagnoses and provides troubleshooting recommendations for Catalyst, IOS and PIX devices. He spent 10 years in the United States Air Force as a Cryptographic Electronic Technician and Telephone Systems Specialist. He worked for TRW, Litton PRC and International Network Services before joining Cisco Systems. He enjoys spending time with family in Round Rock, TX, and fulfills his fishing needs by competing in professional bass tournaments. Nathan Lohr (CISSP, CCSP, and CCNA) is president of TRL Secure Solutions, a small business based in Northern Virginia providing national and international security consulting and training services. During the past fifteen years he has designed, tested and certified VPN, firewall, intrusion detection, and incident response solutions as well as ensuring customer compliance with HIPAAand DCID requirements. Andrew Makin is a network consultant for Energis, a Cisco Gold Partner in the United Kingdom, and he currently holds the CCNP, CCDP, and CSS-1 qualifications. He designs WAN solutions for customers involving both IP and secure VPN technology across the public Internet and the Energis provider network. He lives in Harrogate with his wife, Lisa, and two daughters, Katy and Jessica. Ivan Pepelnjak, CCIE No. 1354, has more than 10 years of experience in designing, installing, troubleshooting, and operating large service provider and enterprise WAN and LAN networks and is currently chief technologies advisor at NIL Data Communications. He is the architect of NIL's Service Provider Academy program, one of the architects of the Cisco Systems Service Provider curriculum, and the lead developer of several service provider-focused courses covering MPLS, Border Gateway Protocol (BGP), and IP quality of service. Ivan is one of the Cisco Routing authorities in Europe. Tim Sammut, CCIE No. 6642, is a senior network consultant for Northrop Grumman Information Technology. Tim has served in key project roles involving technologies from LAN switching to security to SNAintegration and has helped many organizations, ranging from 100 to 130,000 users, make the most of their network investment. Tim also holds the CISSP, CCIE Security, and CCIE Communication and Services certifications. Wen Zhang has been a member of the Cisco Technical Assistance Center (TAC) in security and VPN technologies since June 1997 and a member of the TAC escalation team since August 2000. Wen is a regular contributor on Cisco Open Forum. He earned his B.S. and M.S. from Clemson University. Troubleshooting Virtual Private Networks 8 / 665 12. Acknowledgments I'd like to thank a number of people who have helped to make this project a reality. First and foremost are Michelle and Chris at Cisco Press, without whose help this book would still be on the drawing board. And I don't want to forgot all the other Cisco Press people involved with the production of this book, including: Marc, Patrick, Ginny, Tammi, Gina, Louisa, Brett, and Larrythanks! I'd also like to thank the technical reviewers, Henry Benjamin, Tim Sammut, Wen Zhang, Nathan Lohr, Ivan Pepelnjak, Robert Brown, and Andrew Makin, who contributed interesting and useful comments as I went along. Finally, I'd like to thank W. Mark Townsley for reviewing Chapter 5, as well as Glen Zorn and Luca Martini for confirming important points with regard to PPTP voluntary tunnel mode architecture and draft-martini Layer 2 MPLS transport respectively. Also, thanks to Vicky at Astricom for the loan of one of Astricom's ISDN simulators. Troubleshooting Virtual Private Networks 9 / 665 13. Icons Used in This Book Throughout the book, you will see the following icons used for networking devices: Troubleshooting Virtual Private Networks 10 / 665 14. Command Syntax Conventions The conventions used to present command syntax in this book are the same conventions used in the Cisco IOS Software Command Summary: Boldface indicates commands and keywords that are entered literally as shown. In actual configuration examples and output (not general command syntax), boldface indicates commands that are manually input by the user (such as a show command). Italics indicate arguments for which you supply actual values. Vertical bars (|) separate alternative, mutually exclusive elements. Square brackets [ ] indicate optional elements. Braces { } indicate a required choice. Braces within brackets [{ }] indicate a required choice within an optional element. Troubleshooting Virtual Private Networks 11 / 665 15. Introduction Virtual private networks (VPNs) in their many and varied guises are becoming more and more prevalent throughout the world. For the service provider and enterprise, they provide a means of enabling new services and applications over a wide-area network (WAN), while providing considerable concomitant cost savings. VPNs are complex, so when things go wrong, they can be difficult to troubleshoot. What are your options? One option is to contact Cisco TAC. Alternatively, you can buy this book, roll up your sleeves, and get to work. Armed with as much information as I could cram into 800-odd pages, you'll be well on your way to solving your problem. And if your organization is considering deploying or optimizing a VPN and wants to avoid all the issues described in this book and more, please see my company website (www.mjlnet.com) or contact me directly ([email protected]), and my very knowledgeable colleagues or I will soon be on site helping to ensure that the process goes smoothly (our services are chargeable, of course!). Furthermore, if your organization would like to improve staff productivity and expertise through advanced training, again please see the website. Anumber of RFCs and Internet Drafts are referenced in this book. You should be able to locate many of these at the IETF Web site (www.ietf.org). Internet Drafts do, however, expire, so an alternative way of locating them is to use an archive such as www.watersprings.org. Troubleshooting Virtual Private Networks 12 / 665 16. Motivation for the Book In my work designing, implementing, and troubleshooting VPNs, I noticed a lack of a single source that not only described the commands and techniques to troubleshoot VPNs, but also included the detailed protocol information necessary to correctly interpret troubleshooting command output. This book will provide you with that single source, and it will (hopefully) save you a lot of time and stress when troubleshooting your VPNs. Troubleshooting Virtual Private Networks 13 / 665 17. Audience This book covers a wide range of VPN technologies, including IPSec, MPLS, L2TP version 3, L2TP version 2, PPTP, and L2F. It is suited to network support engineers and architects, whose job is to provide day-to-day support for VPNs or deploy VPNs successfully in the first place. Because of the range of coverage, and the fact that each chapter covers not only troubleshooting, but also a technical overview and configuration guidelines, this book may be of considerable assistance to CCIE candidates preparing for the Service Provider and Security exams. Troubleshooting Virtual Private Networks 14 / 665 18. Organization This book can be read in three different ways. First, it can be read end to end. This is the approach to take if you are curious about VPN technologies in general and want to improve your internetworking skills. Asecond way of reading this book is to read a particular chapter or chapters that deals with VPN technologies deployed in your network in advance of problems occurring. This is a good ideaforewarned is forearmed, after all. Lastly, you can dip into the chapters as and when problems do crop up. Each chapter has been arranged in a manner to facilitate this as much as possible. As a bonus, a number of troubleshooting labs are included to help you develop and hone your VPN troubleshooting skills. Included on the Cisco Press Web site for this book (www.ciscopress.com/1587051044) are labs for L2F, L2TP version 2, MPLS Layer 3 VPN, and IPSec. Labs for PPTP are not included because Cisco IOS routers support only voluntary tunnel mode, and the list of possible client operating systems is extensive. Labs for L2TP version 3 and Any Transport over MPLS (AToM) are not included because the base platform required for these technologies at the time of writing is the Cisco 7200I don't imagine that many people are lucky enough to have 7200s in their lab! If and when support for L2TP version 3 and AToM is added to lower-end platforms, I may develop a few labs for these technologies. Check the Cisco Press web site in that case. You may also find one or two extra labs for the other technologies discussed in this book. The chapters are arranged in the following order: Chapter 1, "Basic Troubleshooting Methodology" This chapter introduces a basic end-to-end troubleshooting methodology that is particularly suited to VPNs. Also discussed are the tools and techniques used for troubleshooting these technologies. Chapter 2, "Troubleshooting Layer Two Forwarding Protocol VPNs" L2F was one of the first virtual private dialup network technologies to be deployed. This chapter discusses the technology, its configuration, and in-depth troubleshooting techniques. Chapter 3, "Troubleshooting Point-to-Point Tunneling Protocol VPNs" The PPTP protocol, configuration, and in-depth troubleshooting are examined in this chapter. Chapter 4, "Troubleshooting Layer 2 Tunneling Protocol Version 2 VPNs" L2TP is based on L2F and PPTP. This chapter introduces L2TP, discusses configuration, and goes on to examine in- depth L2TPv2 troubleshooting techniques. Chapter 5, "Troubleshooting L2TP v3 Based VPNs" L2TPv3 is a technology that allows the tunneling of not only PPP, but also other Layer 2 protocols, such as Ethernet, HDLC, and Frame Relay. This chapter examines the technology itself, its configuration, and in-depth troubleshooting. Chapter 6, "Troubleshooting Multiprotocol Label Switching Layer 3 VPNs" MPLS Layer 3 VPNs are proving to be a very popular technology for service providers and enterprises alike. The technology, its configuration, and in-depth troubleshooting are discussed in this chapter. Chapter 7, "Troubleshooting Any Transport over MPLS Based VPNs" AToM can be used to provide transport of Layer 2 protocols such as HDLC, PPP, Frame Relay, and Ethernet over an MPLS backbone. The technology, configuration, and in-depth troubleshooting are examined. Chapter 8, "Troubleshooting IPSec VPNs" IPSec VPNs are typically deployed to provide secure VPNs in a site-to-site or remote access configuration. The IPSec technology, configuration, and in- depth troubleshooting are discussed in this chapter. Troubleshooting Virtual Private Networks 15 / 665 19. Appendix A, "Answers to Review Questions" This appendix includes answers to the review questions provided at the end of each chapter. Appendix B, "Lab Instructions and Solutions" The L2F, L2TPv2, MPLS Layer 3 VPN, and IPSec chapters include troubleshooting labs to help readers understand and consolidate concepts and techniques discussed. This appendix explains how lab configuration can be loaded onto lab routers from the Cisco Press Web site (www.ciscopress.com/1587051044) and provides solutions to the labs themselves. Troubleshooting Virtual Private Networks 16 / 665 20. Chapter 1. Basic Troubleshooting Methodology There are two basic approaches to troubleshooting: the stab-in-the-dark approach and the systematic approach. The stab-in-the-dark approach usually involves little knowledge of the technology involved and is completely random in nature. Asystematic approach, on the other hand, involves a step-by-step approach and requires in-depth knowledge of the technology. Very occasionally, the stab-in-the-dark approach can work, but the more complex the technology (and virtual private networks [VPNs] are definitely complex), the less likely that the stab-in-the-dark approach is going to be effective. This chapter, therefore, introduces a step-by-step, systematic approach to troubleshooting that is detailed in the remainder of the book. If you are going to troubleshoot VPNs in a fast and efficient manner, this approach is definitely the one to adopt. Troubleshooting Virtual Private Networks 17 / 665 21. Preparatory Steps: Baselining Your Network Preparatory steps? How can you prepare to troubleshoot? Surely troubleshooting is purely activity, you might be thinking. It can be, but you can do a number of things so that, when problems do arise, you are prepared. Afirst step is to prepare a detailed network topology diagram or diagrams. This diagram should include information such as device types, names, addresses, routing protocols, routing protocol autonomous systems, and link types. You should also gather information including device configurations, software versions (IOS / CatOS), and performance statistics, such as utilization and error rates. Finally, make sure that you have a solid understanding of the technologies and protocols deployed in your network. Once you have all this information and have a good understanding of your network, you'll be able to spot and troubleshoot network problems much more easily. Troubleshooting Virtual Private Networks 18 / 665 22. What to Do When Problems Occur When problems do occur, all of the information mentioned in the previous section will stand you in good stead. But even if you are in possession of this information, you are going to need to work fast to gather facts relating to the issue. The first thing that you should do is ascertain exactly what has gone wrongestablish what the facts are. Find out whether any changes have been made to the network and, if so, what. If possible, try to talk to people directly involved with any changes; secondhand information might not always be as reliable as you would like. Also, if it becomes apparent during the troubleshooting process that there are multiple issues involved, be sure that you tackle one problem at a time. Any attempt to tackle multiple issues at one time usually just leads to confusion and may even make the situation worse. Troubleshooting Virtual Private Networks 19 / 665 23. Open Systems Interconnection Model Two reference models are often used to understand internetworking technologies: the Open Systems Interconnection (OSI) and Department of Defense (DoD) models. Both can be useful, but in this book, the model that is used is the OSI model. Figure 1-1 illustrates the OSI reference model. Figure 1-1. OSI Reference Model Only four of the seven layers are central to troubleshooting the technologies discussed in this book: Physical layer (Layer 1) Data link layer (Layer 2) Network layer (Layer 3) Transport layer (Layer 4) The physical layer is associated with the transmission of bits over the physical medium itself. Characteristics such as voltage levels, maximum transmission distances, and connector types are specified at this layer. The data link layer handles physical addressing, flow control, access to the physical medium, and error detection. Data link layer protocols include HDLC, PPP, Frame Relay, and Ethernet. The network layer facilitates the transmission of packets between end systems on different logical networks by providing path determination and selection. Network layer protocols include IP and IPX. Finally, the transport layer provides end-to-end communication and multiplexing of multiple applications over a transport connection. The transport layer can also provide a reliable channel of communication between end systems, with flow control and congestion avoidance. Transport layer protocols include TCP and UDP. One thing to remember, however, is that the OSI model is, after all, just a reference model. Not all protocols fit easily; a good example of this is Multiprotocol Label Switching (MPLS). It resides at neither the data link nor the network layer. It sits somewhat uncomfortably between the two. Troubleshooting Virtual Private Networks 20 / 665 24. End-to-End, Bottom-Up (or Top-Down) Troubleshooting Troubleshooting can take many forms, but VPN technologies are particularly suited to end-to-end, bottom- up (or top-down) troubleshooting. For example, if you are troubleshooting a compulsory mode Layer Two Tunneling Protocol (L2TP) version 2 VPN (with dial-in), the first thing to do is to confirm that remote clients' calls are being received on the L2TP Access Concentrator (LAC). Next you should confirm that Link Control Protocol (LCP) and partial authentication are being successfully completed on the LAC. Then you should confirm that L2TP tunnel and session setup is successful between the LAC and the L2TP Network Server (LNS). Finally, you can verify that PPP negotiation is successfully completed between the remote client and the LNS. Figure 1-2 illustrates L2TPv2 VPN setup. Figure 1-2. L2TPv2 VPN Setup [View full size image] In this example, setup is asymmetricthe calling party is the remote client, and the called party is (ultimately) the LNS. Some other VPN technologies require a symmetric approach to troubleshooting. Agood example of this is MPLS Layer 3 (RFC 2547bis) VPNs. In this case, you need to verify route exchange between customer edge (CE) routers bidirectionally over the MPLS VPN backbone. Additionally, you will need to verify the label switched path (LSP) in both directions between provider edge (PE) routers across the MPLS backbone. Figure 1-3 illustrates route exchange and LSPs across the MPLS VPN backbone. Figure 1-3. Bidirectional Route Exchange and LSPs Across the MPLS VPN Backbone [View full size image] Troubleshooting Virtual Private Networks 21 / 665 25. When you are troubleshooting a VPN, you should never lose sight of the underlying physical, data-link, and network layer protocols. It is always good practice to ask yourself what must happen first, then next, then after that for the VPN to function correctly. Also ask yourself what underlies each particular process or mechanism. Troubleshooting Virtual Private Networks 22 / 665 26. Troubleshooting Tools The primary tools for troubleshooting VPNs are the show, ping, traceroute, and debug commands. For these commands to be used correctly (and safely), a number of guidelines need to be followed. The show command can be used to view a wide variety of information and statistics related to VPNs. The ping and traceroute commands can be used to verify basic IP connectivity and route across the network. The traceroute command can also be used in an MPLS backbone to display the label stack. Maximum Transmission Unit (MTU) issues that may result in a VPN can also be identified using extended ping to sweep a range of packet sizes. If pings using smaller packet sizes succeed but larger packet sizes fail, this can indicate an issue with the MTU in the VPN. Finally, the debug command can be used to display a variety of status and error information associated with VPNs. Although debug is a useful and, at times, essential tool, there are some dangers with using it. If you use the wrong debug command, or do not filter its output, the output can tie up all the systems resources and potentially cause the system to hang. You can employ a number of ways to avoid loading the system too much. The first is not to debug via the console, but instead to debug via a Telnet session. Use the no logging console command to turn off logging to console. Use the terminal monitor command to view debugging output via a Telnet session. The terminal no monitor command disables viewing debug output via a Telnet session. It might even be a good idea to open a second Telnet session to the device in question so that debugging can still be turned off even if the first session is overwhelmed with output from a debug command. You can also redirect debug output to a syslog server using the logging syslog_server_ip_address command. Note that the quickest (most abbreviated) way to cancel all debug commands is by entering the un all command. This is an abbreviation of the undebug all command. One very useful command, particularly when debugging L2F, PPTP, L2TP, Any Transport over MPLS (AToM), and IPSec is debug condition or debug crypto condition (for IPSec). The debug condition command can be used to limit the output of a debug command so that only the output related to a particular called or calling number, interface, username, IP address, or AToM virtual circuit (VC) ID is displayed. The debug condition command can be used to limit the output of the following commands: debug aaa {accounting | authorization | authentication} debug dialer {events | packets} debug isdn {q921 | q931} debug modem {oob | trace} debug ppp {all | authentication | chap | error | negotiation | multilink events | packet} debug mpls l2transport vc {event | fsm} debug crypto {isakmp | ipsec | engine} In Example 1-1, debug condition is used to limit the output of the debug ppp negotiation command to that related to interface virtual-template 1. Note that only a portion of the output is shown. Example 1-1. debug ppp authentication with debug condition (interface virtual-template 1) Skydance_LNS#debug condition interface virtual-template 1 Condition 1 set Skydance_LNS# Skydance_LNS#debug ppp negotiation PPP protocol negotiation debugging is on Skydance_LNS# *Mar 1 00:27:33.478 UTC: Vi1 Debug: Condition 1, interface Vt1 triggered, count 1 *Mar 1 00:27:33.482 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up Troubleshooting Virtual Private Networks 23 / 665 27. *Mar 1 00:27:33.482 UTC: Vi1 PPP: Using vpn set call direction *Mar 1 00:27:33.482 UTC: Vi1 PPP: Treating connection as a callin *Mar 1 00:27:33.482 UTC: Vi1 PPP: Phase is ESTABLISHING, Passive Open [0 sess, 0 load] *Mar 1 00:27:33.486 UTC: Vi1 LCP: State is Listen *Mar 1 00:27:33.486 UTC: Vi1 LCP: I FORCED CONFREQ len 11 *Mar 1 00:27:33.486 UTC: Vi1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 00:27:33.486 UTC: Vi1 LCP: MagicNumber 0x066CA0F0 (0x0506066CA0F0) *Mar 1 00:27:33.486 UTC: Vi1 LCP: I FORCED CONFACK len 6 *Mar 1 00:27:33.490 UTC: Vi1 LCP: MagicNumber 0x508E6BD0 (0x0506508E6BD0) *Mar 1 00:27:33.490 UTC: Vi1 PPP: Phase is AUTHENTICATING, by this end [0 sess, 0 load] In the first highlighted line, debugging messages for interface virtual template 1 are enabled using the debug condition interface virtual-template 1 command. This also disables output for any other interfaces. In the second highlighted line, the debug ppp negotiation command is used to enable debugging of PPP negotiation events. Finally, in the third highlighted line, PPP debugging messages are triggered on interface virtual template 1 (from which interface virtual access 1 is cloned, in this example). PPP debugging messages are then displayed. More than one debug (crypto) condition command can be enabled at one time, but do not enable too many conditions as this can impact router performance. In this case, debug output must fulfill just one of the conditions to be displayed. Use the show debug condition or show crypto debug-condition commands as appropriate to verify current debugging conditions, as shown in Example 1-2. Example 1-2. Output of the show debug condition Command London_PE#show debug condition Condition 1: vcid 123 (2 flags triggered) Flags: 123 123 London_PE# As you can see, the condition AToM VC ID 123 has been configured. This condition has been met twice. To remove a condition, simply use the no debug (crypto) condition command. With IPSec, you can disable all conditional settings using the debug crypto condition reset command, but make sure you turn off all IPSec debug commands first. The output of a number of debug commands can also be filtered using an access list. Agood example of this is the debug ip bgp update [access-list] command. This can be used to limit the output of the command to updates containing prefixes specified by the access list. Troubleshooting Virtual Private Networks 24 / 665 28. Summary This chapter introduced a basic systematic troubleshooting methodology. VPNs are particularly suited to end-to-end, bottom-up, or top-down troubleshooting. For some VPN technologies, such as L2F, L2TP version 2, and PPTP, end-to-end troubleshooting is asymmetric, whereas for others, such as MPLS layer-3 VPNs and L2TP version 3, end-to-end troubleshooting is symmetric. Preparatory steps, such as drawing network diagrams, recording software versions, and backing up device configurations, are recommended. Finally, VPN troubleshooting tools, such as the show, ping, traceroute, and debug commands, were introduced. Usage guidelines for the debug command were also discussed. Troubleshooting Virtual Private Networks 25 / 665 29. Chapter 2. Troubleshooting Layer Two Forwarding Protocol VPNs The Layer Two Forwarding (L2F) Protocol is a Cisco proprietary protocol that facilitates the transparent forwarding of Point-to-Point Protocol (PPP) and Serial Line Internet Protocol (SLIP) across an IP backbone. L2F, which is defined in RFC 2341, allows the separation of the functionality of the traditional Network Access Server (NAS), with call reception on a NAS, but termination of the PPP or SLIP connection on a device called a Home Gateway. The Home Gateway is geographically separated from the NAS. This means that an enterprise can outsource call reception to an Internet service provider (ISP) but still terminate PPP/SLIP connections within the corporate network. This allows the enterprise to save or minimize on call charges because remote access clients are no longer required to dial directly to the enterprise. They are instead able to dial in to the ISP's nearest Point-of-Presence (POP). Figure 2-1 illustrates this concept. Figure 2-1. L2F Topology [View full size image] This logical separation of call reception and PPP connection termination presupposes a mechanism for tunneling the PPP frames across the backbone to the Home Gateway. This mechanism is provided by L2F. Only compulsory tunneling is supported with L2F. This means that tunneling directly from the remote access client to the Home Gateway is not supported. Note that L2F is also used to support the tunneling of multilink PPP (MP) links between NASs in a multichassis multilink PPP (MMP) environment. Troubleshooting Virtual Private Networks 26 / 665 30. Technical Overview of L2F This chapter focuses on in-depth troubleshooting of L2F. Fast and efficient troubleshooting requires a good knowledge of both L2F and its configuration, and to that end, a brief description of both follows. As previously described, L2F is a protocol that allows the tunneling of PPP and SLIP frames across a IP backbone between a NAS and a Home Gateway. This chapter focuses on the tunneling of PPP frames because, to a great extent, PPP has superceded SLIP as the remote access protocol of choice. The protocol itself uses the User Datagram Protocol (UDP), on top of which sits the L2F packet (header, payload, and optional CRC) itself. Figure 2-2 illustrates the relationship between IP, UDP, and L2F. Figure 2-2. Overall L2F Packet Format Note that L2F packets utilize UDP port 1701. This will be relevant when troubleshooting L2F. Now take a closer look at the L2F Protocol packet header itself in Figure 2-3. Figure 2-3. L2F Packet Header [View full size image] The following list provides an analysis of the L2F header, starting with the header flags: The F, K, S, and C bits, if set to 1, indicate that the optional fields (shown as opt in Figure 2-3) should be present: - F, if set, indicates that the Offset field should be present. - K, if set, indicates that the Key field should be present. Troubleshooting Virtual Private Networks 27 / 665 31. - S, if set, indicates that the Sequence number should be set. - Finally, C, if set, indicates that the Checksum should be present. The P bit, if set, indicates that this L2F packet is a priority packet. RFC 2341 does not specifically define what type of packet should constitute a priority packet but instead leaves this up to the implementer. The Version (Ver) field is a 3-bit field and should be set to 001 binary = 1 decimal. No other value is valid, at least as far as L2F is concerned. The 8-bit Protocol field has only three legal values, 0x01, 0x02, and 0x03. The value 0x1 indicates that this is an L2F management packet (type L2F_PROTO), the value 0x2 indicates that this packet contains PPP tunneled within L2F (type L2F_PPP), and the value 0x3 indicates that the packet contains SLIP tunneled within L2F (type L2F_SLIP). Table 2-1 summarizes Protocol field values. Table 2-1. L2F Protocol Field Values Value Type Description 0x00 L2F_ILLEGAL Illegal protocol type 0x01 L2F_PROTO Management packets 0x02 L2F_PPP Payload carries tunneled PPP 0x03 L2F_SLIP Payload carries tunneled SLIP If the value in the Protocol field specifies a management packet, then various options and suboptions are carried within the L2F payload. Options specify an overall message type, with suboptions carrying data associated with the message type. Options and suboptions are discussed in the section "L2F Management Messages." The 8-bit Sequence field is present only if the S-bit is set. The S-bit must be set, and therefore, sequence numbering must be used, for L2F management packets. RFC 2341 allows a degree of flexibility with regard to the Sequence number field. Packets other than management packets can use sequence numbers, but it is not mandatory. Some protocols might be sensitive to packets arriving out of sequence, and sequence numbering can be useful in this case. If sequence numbering is used, it must be present in every packet for a particular session (for every packet with the same multiplex ID [MID]). The MID is a 16-bit field, and it is used to distinguish between different sessions (connections) within the overall L2F tunnel from a NAS to a Home Gateway. Figure 2-4 illustrates an L2F tunnel between a NAS and Home Gateway with multiple sessions within it, each from a different remote access client. Figure 2-4. Multiple Sessions Within the L2F Tunnel [View full size image] Troubleshooting Virtual Private Networks 28 / 665 32. In Figure 2-4, two remote access users are connected to the NAS. Their PPP connections are tunneled via L2F from the NAS to the Home Gateway. The Home Gateway has to be able to distinguish between the two sessions, and this is done using unique MIDs. Remote access user A's PPP connection uses MID 17, and user B's PPP connection uses MID 18. Note that MID 17 and 18 have no special significance and are used purely for illustrative purposes. The MID 0 is reserved for L2F management (L2F_PROTO) packets, leaving a theoretical 2^16-1 (65535) MIDs for client sessions. The Client ID (CLID) is a 16-bit field, and it is used to uniquely identify a particular tunnel from a NAS to a Home Gateway and vice-versa. At any one time, a Home Gateway might be terminating L2F tunnels from a number of NASs. Similarly at any one time, a NAS might have tunnels to several Home Gateways. To allow the Home Gateway (or NAS) to distinguish between the packets coming through tunnels from different NASs (or Home Gateways), a CLID is used. The CLID assigned to a particular tunnel is communicated during the tunnel setup. It is communicated via the Assigned CLID field in a L2F_CONF packet (see the section "L2F Tunnel Establishment"). The receiving device then uses the CLID to distinguish inbound packets belonging to different tunnels. For example, a NAS with hostname LODI_NAS1 receives a call from an employee of the Perris Corporation. Having no existing L2F tunnel to the Home Gateway for the Perris Corporation (PERRIS_HGW1), LODI_NAS1 needs to set one up. Tunnel setup begins from LODI_NAS1 to PERRIS_HGW1. PERRIS_HGW1 is already terminating an L2F tunnel from LODI_NAS2, and this tunnel is identified by the CLID 1. PERRIS_HGW1 needs to distinguish inbound packets on the tunnel from LODI_NAS1 from those inbound from LODI_NAS2. During tunnel setup to LODI_NAS1, therefore, PERRIS_HGW1 assigns the unique CLID 2 and communicates this to LODI_NAS1 via the Assigned CLID field in a L2F_CONF message. Thereafter, whenever LODI_NAS1 needs to send L2F tunnel packets to PERRIS_HGW1, it puts the number 2 in the Client ID field. In simple terms, during tunnel setup, PERRIS_HGW1 says to LODI_NAS1, "Whenever you want to send tunnel packets to me, please uniquely identify them with the CLID 2 so that I will know that they are packets from you." Remember that this process is bidirectional, so LODI_NAS1 also communicates a locally unique CLID to PERRIS_HGW1. Figure 2-5 illustrates this concept. Figure 2-5. Identification of Tunnel Packets Using CLIDs In Figure 2-5, PERRIS_HGW1 is receiving L2F tunnel packets from both LODI_NAS1 and LODI_NAS2. It is able to distinguish these packets by examining the CLID field. The next field in the packet header is Length. The Length field is 16 bits long, and it reflects the length of the header and payload but does not include the checksum if one is present. The Offset field, if present, is used to specify how many bytes after the L2F header the payload starts. For some transport architectures, it might be more efficient if the payload is aligned with a 32-bit boundary, and the Offset field can be used to ensure this (with an offset of 0). The Offset is present only if the F bit is set. Troubleshooting Virtual Private Networks 29 / 665 33. The Key is a 32-bit field, is only present if the K bit is set, and is used to authenticate a tunnel peer. This prevents tunnel packets from being spoofed by another source. The Key is calculated as follows: 1. During tunnel establishment, each end of the tunnel sends a challenge to its peer in an L2F_CONF message. 2. This challenge contains a random number. The recipient of this challenge calculates a 128-bit hash value based on the random number and a shared password (tunnel secret). 3. The recipient then breaks the 128-bit hash into four parts, exclusive-ORs (XORs) them together, and sends the resultant hash value in the Key field back to its tunnel peer (NAS or Home Gateway). Note that the original 128-bit hash value is also sent to the tunnel peer during tunnel authentication. 4. The originator of the challenge calculates its own hash value based on the same random number and the shared password and compares it to the hash value received. If the two hash values match, authentication is successful. The 32-bit Key, once calculated, is carried in all tunnel packets for the duration of its lifetime. Next in the packet comes the L2F payload. This is used to carry either L2F management messages or PPP frames depending on the packet type. Finally, if the C bit is set, a 16-bit checksum is appended to the packet. The checksum is calculated over the entire L2F packet, starting with the header and including the payload. L2F Management Messages As previously mentioned, if the L2F header has a value of 0x01 (L2F_PROTO) in the Protocol field, the packet is a tunnel management packet. Within the payload of a tunnel management packet, various options and suboptions can be carried. The option specified dictates what kind of management message the packet is, whereas the suboptions carry any data associated with that particular message type. Table 2-2 summarizes the available options and their corresponding suboptions. Table 2-2. Tunnel Management Packet Payload Options Option Suboption Suboption Value Description L2F_CONF (0x01) L2F_CONF_NAME 0x02 Name of peer sending L2F_CONF L2F_CONF_CHAL 0x03 Random number challenge L2F_CONF_CLID 0x04 Assigned CLID for peer use L2F_OPEN (0x02) L2F_OPEN_NAME 0x01 Username received from remote access client L2F_OPEN_CHAL 0x02 Challenge Handshake Authentication Protocol (CHAP) challenge sent by NAS to remote access client L2F_OPEN_RESP 0x03 1. Tunnel authentication response 2. Response from remote access client to NAS challenge (hash value, if CHAP) L2F_ACK_LCP1 0x04 Last LCP CONFACK received from remote access client by NAS L2F_ACK_LCP2 0x05 Last LCP CONFACK sent Troubleshooting Virtual Private Networks 30 / 665 34. by NAS to remote access client L2F_OPEN_TYPE 0x06 Type of authentication used L2F_OPEN_ID 0x07 ID associated with CHAP challenge L2F_REQ_LCP0 0x08 First LCP CONFREQ received from remote access client L2F_CLOSE (0x03) L2F_CLOSE_WHY 0x01 Reason code for close L2F_CLOSE_STR 0x02 ASCII string description of close reason L2F_ECHO (0x04) (no suboptions) Keepalive L2F_ECHO_RESP (0x05) (no suboptions) Response to L2F_ECHO As you can see, if a L2F_CONF message is sent, three suboptions can be carried along with it: L2F_CONF_NAME, L2F_CONF_CHAL, and L2F_CLID. Similarly, if the message is an L2F_OPEN, the suboptions that can be carried range from L2F_OPEN_NAME to L2F_REQ_LCP0. When an L2F_CLOSE message is sent, the two suboptions can be carried are L2F_CLOSE_WHY and L2F_CLOSE_STR. Finally, if the message is either an L2F_ECHO or an L2F_ECHO_RESP, no suboptions can be carried. The sections that follow describe the function of the options and suboptions in greater detail. L2F Tunnel Establishment Tunnel establishment begins with the reception of a PPP connection by the NAS. At this stage, the NAS goes through the Link Control Protocol (LCP) negotiation phase with the remote client, with options such as compression, callback, and authentication protocol being negotiated. As soon as the LCP negotiation phase has been completed, the NAS and the remote client move onto authentication. AChallenge Handshake Authentication Protocol (CHAP) challenge is now sent by the NAS to the client. Note that although either CHAP or Password Authentication Protocol (PAP) could be used for authentication, this chapter assumes that CHAP is used. Upon receipt of the CHAP challenge, the remote client takes the random number in the challenge (call it Random3), the Challenge ID, and the CHAP password and calculates a Message Digest 5 (MD5) hash value (call it Hash3). This hash value is transmitted back to the NAS via a CHAP response message. At this point, the NAS performs a partial authentication on the CHAP response. The NAS does not examine the hash value contained within the CHAP response packet as it normally would but looks at the sender's name (which is also contained within the response). If this PPP connection is one that should be tunneled to a Home Gateway, the sender's name should be in the format username@domain_name. The domain name indicates to the NAS to which Home Gateway this PPP connection should be tunneled. It is worth noting that this delimiter character (@) can be modified on the NAS using the command vpdn domain- delimiter. This association of user to tunnel can also be based on the Dialed Number Information Service (DNIS) string. The DNIS is the dialed number, and it is present in ISDN Q.931 messages passed from the ISDN switch to the NAS during call setup. This means that, for example, if a remote access client dials the number 555-1234 to access the NAS, the NAS will use this number to associate the user to a L2F tunnel. The user-to-tunnel association can also be established on a per-username basis. In this case, the NAS sends the complete username to an authentication, authorization, and accounting (AAA) server, and the AAAserver responds with tunnel information based on this username. Configuration of per-user VPDN is beyond the scope of this chapter, but more details can be found at the following URL: http://www.cisco.com/en/US/tech/tk801/tk703/technologies_configuration_example09186a0080094860.shtml Troubleshooting Virtual Private Networks 31 / 665 35. Once the user-to-tunnel association has been made, the NAS either initiates tunnel setup to the appropriate Home Gateway, or if a tunnel already exists, initiates a new L2F session for the PPP connection within that tunnel. In this example, assume that the tunnel is not yet in existence. The NAS initiates tunnel setup by sending a L2F_CONF message. Figure 2-6 illustrates the L2F_CONF sent by the NAS to the Home Gateway. Figure 2-6. L2F_CONF Sent by the NAS Within the L2F packet header, the protocol type field is set to 0x01 (L2F_PROTO), which indicates that this is a management message. The Sequence Number, MID, CLID, and Key are all set to a value of 0. Contained within the payload is the L2F_CONF (option 0x01) itself. The L2F_CONF message contains within it the following suboptions: L2F_CONF_NAME (name of the tunnel initiating NAS) L2F_CONF_CHAL (random number challenge) L2F_CONF_CLID (assigned Client ID) In this example, assume that the NAS has chosen an assigned CLID of 34 (which is locally unique to the NAS). Figure 2-7 represents this packet. Figure 2-7. L2F_CONF Message Sent by the NAS Notice that a checksum is omitted in this example. The receiving Home Gateway first confirms that the incoming L2F_CONF message is from a recognized NAS. If it is, the Home Gateway takes the random number specified in L2F_CONF_CHAL (call it Random1) and the tunnel secret (password) corresponding to the NAS's name (specified in L2F_CONF_NAME suboption) and performs a hash. The password corresponding to the NAS's name is stored either locally on the Home Gateway (username nas_name password password) or on an authentication server (for example, a Remote Authentication Dial-In User Service Troubleshooting Virtual Private Networks 32 / 665 36. [RADIUS] server). If the L2F_CONF is not from a recognized NAS, the Home Gateway terminates tunnel setup. Once the L2F_CONF has been accepted, the Home Gateway is ready to reply to the NAS. At this point, the Home Gateway responds to the NAS with its own L2F_CONF message. This serves as recognition of the NAS's tunnel setup request. Figure 2-8 illustrates the L2F_CONF sent by the Home Gateway. Figure 2-8. L2F_CONF Sent by the Home Gateway [View full size image] Within the L2F header, the protocol field is set to 0x01 (L2F_CONF); the Sequence Number, MID, and Key are all set to a value of 0; and the Client ID is set to 34 (the Assigned CLID from the NAS). The L2F_CONF message itself is contained within the payload of the L2F packet. Again, a number of suboptions are included: The L2F_CONF_NAME is set to be the name of the Home Gateway. L2F_CONF_CHAL contains a random number (call it Random2). L2F_CONF_CLID contains a CLID assigned by and locally unique on the Home Gateway (in this example, the value 38). Figure 2-9 illustrates this packet. Figure 2-9. L2F_CONF Message Sent by the Home Gateway The Home Gateway has now received a L2F_CONF from the NAS, and the NAS has received a L2F_CONF from the Home Gateway. Troubleshooting Virtual Private Networks 33 / 665 37. The NAS now prepares to reply to, and to be authenticated by, the Home Gateway. To do this, the NAS calculates a hash (a CHAP-like hash) based on the random number, Random2, received from the Home Gateway in its L2F_CONF (see Figure 2-9), together with the tunnel secret (password). Call this hash Hash2, because it corresponds to Random2. The NAS uses an L2F_OPEN message to communicate the resultant hash value, Hash2, to the Home Gateway. Figure 2-10 shows the L2F_OPEN sent by the NAS. Figure 2-10. L2F_OPEN sent by the NAS [View full size image] The packet header for this message is constructed as follows: The Protocol field contains the value 0x01. The Sequence field (number) is set to 1 (the next exchange in the sequence, following the exchange of L2F_CONF messages). The MID field is set to 0. The CLID is set to 38 (the CLID assigned by the Home Gateway). The Key is set to the value "Hash2" (32-bit). The payload of the packet contains the L2F_OPEN message itself and suboption L2F_OPEN_RESP. The L2F_OPEN_RESP contains the entire 128-bit authentication hash value. Figure 2-11 shows the L2F_OPEN message sent by the NAS. Figure 2-11. The L2F_OPEN Message Sent by the NAS Troubleshooting Virtual Private Networks 34 / 665 38. Upon receipt of the L2F_OPEN message, the Home Gateway authenticates the NAS. This is done by comparing the received hash value (Hash2) to a hash value calculated locally based on the same input values (Random2 and the tunnel password). If the hash values match, the Home Gateway authenticates the NAS. If the values do not match, then tunnel setup is terminated. Once it has authenticated the NAS, the Home Gateway sends an L2F_OPEN message to the NAS with Hash1 (hash computed on Random1, plus the tunnel secret) being carried in the packet. Figure 2-12 illustrates the L2F_OPEN sent by the Home Gateway. Figure 2-12. L2F_OPEN Sent by the Home Gateway The packet format is shown in Figure 2-13, and is exactly the same as the L2F_OPEN sent by the NAS to the Home Gateway, with the protocol field set to 0x01 (L2F_PROTO), the Sequence Number set to 1, the MID is set to 0, and the CLID is set to 34 (the CLID assigned by the NAS). The Key is set to be hash1 (32-bit). Finally, the payload of the packet carries the message type itself (L2F_OPEN), with suboption L2F_OPEN_RESP. Figure 2-13. Packet Format of the L2F_OPEN Sent by the Home Gateway to the NAS The NAS compares the received hash value (hash1) to its own hash value calculated based on the same inputs (Random1 and the tunnel password). If the two hash values match, the NAS authenticates the Home Gateway. If not, the NAS terminates tunnel setup. Assuming that the NAS successfully authenticates the Home Gateway, both ends of the tunnel have now authenticated each other and are now ready to move on to the establishment of L2F sessions within the tunnel. Troubleshooting Virtual Private Networks 35 / 665 39. L2F Session Establishment Now that the L2F tunnel has been established between the NAS and the Home Gateway, the NAS can proceed to pass the LCP and authentication data negotiated with the remote access client to the Home Gateway. You'll remember that when the client first dialed into the NAS, the NAS issued a CHAP challenge to the client. Within the challenge was an ID value, together with a random number (Random3). The client responded to the challenge with a hash value (call it hash3) calculated from the random number (Random3), the ID, and the secret password. Although the NAS issued the CHAP challenge, it cannot fully authenticate the client because it does not have the password. In fact, the logical endpoint of the PPP connection is responsible for authenticating the client, and that is the Home Gateway. The NAS needs to pass the hash value, hash3, together with the client's user name and the CHAP challenge ID value on to the Home Gateway. To do this, it sends another L2F_OPEN message. Figure 2-14 shows the session setup L2F_OPEN sent by the NAS. Figure 2-14. Session Setup L2F_OPEN Sent by the NAS The L2F_OPEN message header takes the following form: The Protocol field contains the value 0x01 (because this is still a tunnel management message). The Sequence number field is set to the value 2 (this is the next in the sequence). The MID field is set to 1. The CLID is set to 38. The Key is set to the value Hash2. The payload contains the message type (option) L2F_OPEN. Anumber of suboptions are included: L2F_OPEN_TYPE (indicating authentication type) L2F_OPEN_NAME (the remote access client's username) L2F_OPEN_CHAL (the random number used to challenge the client [Random3]) L2F_OPEN_RESP (the hash value received in the response, Hash3) L2F_OPEN_ID (the ID used in the challenge from the NAS to the client). In addition to client authentication information, the NAS passes some client LCP negotiation messages to the Home Gateway: Troubleshooting Virtual Private Networks 36 / 665 40. The last LCP Configure-Ack (CONFACK) sent from the remote access client to the NAS (L2F_ACK_LCP1) The last CONFACK sent from the NAS to the client (L2F_ACK_LCP2) The first Configure-Request (CONFREQ) sent from the client to the NAS (L2F_REQ_LCP0). LCP negotiation messages passed by the NAS to the Home Gateway can allow the Home Gateway to much more rapidly configure LCP for communication with the client. If it accepts the options in the CONFACKs, there is no need to renegotiate with the client. However, the Home Gateway can renegotiate LCP with the client if it so wishes. LCP renegotiation can be based on the options specified in the first CONFREQ sent by the client but not agreed to by the NAS. It is worth noting that the MID value has now changed from 0 to a nonzero value. This is because this message corresponds to the L2F session, rather than being a purely tunnel management message (which would have a MID value of 0). Note that MID values are assigned based on being the next available. Figure 2-15 illustrates this L2F_OPEN message. Figure 2-15. Session L2F_OPEN Sent by the Home Gateway Upon receiving this L2F_OPEN message, the Home Gateway responds to the NAS with a L2F_OPEN. This L2F_OPEN serves to confirm acceptance of the client L2F session. Figure 2-16 shows the L2F_OPEN sent from the Home Gateway to the NAS. Figure 2-16. L2F_OPEN from the Home Gateway to the NAS Troubleshooting Virtual Private Networks 37 / 665 41. The L2F_OPEN message header takes the following format: The Protocol field is set to 0x01 (L2F_PROTO). The Sequence number field is set to 2. The MID is set to 1. The CLID is set to 34. The Key is set to Hash1. The payload of the packet contains the L2F_OPEN message itself. Figure 2-17 illustrates this packet. Figure 2-17. Session L2F_OPEN Message The NAS, having received this acceptance message from the Home Gateway, begins to transparently forward PPP frames between the client and the Home Gateway. Figure 2-18 shows the forwarding of PPP frames between the Home Gateway and the remote access client. Figure 2-18. NAS Forwards PPP Frames Troubleshooting Virtual Private Networks 38 / 665 42. It is worth qualifying the statement word transparently. PPP frames are unescaped, and any bit-stuffing is removed before forwarding. Additionally, PPP flags (excluding the address and control flags, unless negotiated away) and the CRC are omitted. PPP frames (from the remote access client) forwarded by the NAS to the Home Gateway are tunneled within L2F_PPP packets. This means that the packet headers now take the following form: The Protocol field is set to 0x02 (L2F_PPP, indicating PPP in payload). The sequence number is set to 0 (assuming that sequence numbering is not used). The MID is set to 1; the CLID is set to 38. The Key is set to Hash2. The payload contains the PPP frame. Similarly, PPP frames forwarded by the Home Gateway to the NAS are carried in L2F_PPP packets, with the packet header constructed as follows: The Protocol field is set to 0x02. The Sequence Number is set to 0; the MID is set to 1. The CLID is set to 34. The Key is set to Hash1. The payload again contains the PPP frame. Note how the Sequence number is now 0 for PPP frames sent between the NAS and the Home Gateway. This is because it is mandatory only for tunnel management packets to contain sequence numbering. Figure 2-19 illustrates the form of PPP frames tunneled within L2F packets sent from the NAS to the Home Gateway. Figure 2-19. L2F_PPP Packets Sent by the NAS Troubleshooting Virtual Private Networks 39 / 665 43. Figure 2-20 shows the form taken by PPP frames tunneled from the Home Gateway to the NAS. Figure 2-20. L2F_PPP Packets Sent by the Home Gateway L2F Tunnel Maintenance RFC 2341 specifies a keepalive mechanism for L2F tunnels. This consists of sending L2F_ECHO and L2F_ECHO_RESP messages. The L2F_ECHO is not a mandatory requirement for an implementation of L2F, but should an L2F peer receive an L2F_ECHO message, it is mandatory that the peer replies with a L2F_ECHO_RESP. Figure 2-21 illustrates the L2F keepalive mechanism. Figure 2-21. L2F Keepalive Mechanism Arecommended practice is that if a tunnel peer (NAS or Home Gateway) transmits at least five consecutive L2F_ECHOs without receiving a L2F_ECHO_RESP in reply, it (the NAS or Home Gateway) should assume that its peer has terminated the tunnel connection. Troubleshooting Virtual Private Networks 40 / 665 44. The L2F_ECHO is encoded as option 0x04, with the MID set to 0 (tunnel management packet). It is possible for L2F to include extra data in the payload, and if extra data is present, it must be preserved in the L2F_ECHO_RESP (option 0x05). Apossible usage of this extra data is to associate an L2F_ECHO_RESP with a particular L2F_ECHO. Figure 2-22 represents the L2F_ECHO. Figure 2-22. L2F_ECHO Message Figure 2-23 illustrates the L2F_ECHO_RESP. Figure 2-23. L2F_ECHO_RESP Message You will notice that the nonzero sequence numbering in the L2F_ECHO and L2F_ECHO_RESP. This is because, as L2F management messages, these two messages must carry sequence numbering. The Key values carried in the L2F_ECHO and L2F_ECHO_RESP messages are the same as those calculated in the tunnel establishment phase (Hash1 or Hash2). Similarly, the CLID corresponds to the CLIDs assigned during tunnel establishment. L2F Tunnel Teardown The final action in the life of tunnel is, of course, termination. Tunnel termination can be caused by several factors, for example reception of an invalid message type, reception of a PPP TERMREQ (Termination Request) on the last PPP connection in a tunnel, or simply execution of the command clear vpdn tunnel. It is worth pointing out that the reception of packets with an invalid key will not cause the tunnel to be terminated. The fact that L2F tunnels are not terminated when packets with an invalid key are received prevents denial-of-service attacks against L2F tunnels. Troubleshooting Virtual Private Networks 41 / 665 45. Once an event that mandates tunnel teardown has occurred, the endpoint wishing to tear down the tunnel (either the NAS or the Home Gateway) transmits an L2F_CLOSE message to its peer. Figure 2-24 illustrates the L2F_CLOSE message. Figure 2-24. NAS Sends an L2F_CLOSE Message Figure 2-25 illustrates the format of the L2F_CLOSE message. Figure 2-25. L2F_CLOSE Message Format The L2F_CLOSE_WHY suboption, which can optionally be included in the L2F_CLOSE message, is 4 octets long. It is used to inform the NAS of the reason for a tunnel setup failure or tunnel termination. An implementer might choose not to indicate

Troubleshooting vpn

Economy & Finance

Transcript of Troubleshooting vpn