Top Banner
7/13/2019 IPSEC VPN Fundamentals 1/480 From the Library of Ahmed

IPSEC VPN Fundamentals

Oct 14, 2015



Nicolae Neceaev

IPsec Virtual Private Network Fundamentals
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
  • 7/13/2019 IPSEC VPN Fundamentals


    From the Library of Ahmed

  • 7/13/2019 IPSEC VPN Fundamentals


    800 East 96th Street

    Indianapolis, Indiana 46240 USA

    Cisco Press

    IPsec Virtual Private NetworkFundamentals

    James Henry Carmouche, CCIE No. 6085

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals



    IPsec Virtual Private Network FundamentalsJames Henry Carmouche, CCIE No. 6085

    Copyright 2007 Cisco Systems, Inc.

    Published by:Cisco Press800 East 96th StreetIndianapolis, 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 pub-lisher, 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 2006

    Library of Congress Cataloging-in-Publication Number: 2004107143

    ISBN: 1-58705-207-5

    Trademark AcknowledgmentsAll terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Cisco Pressor Cisco Systems, Inc. cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affectingthe validity of any trademark or service mark.

    Warning and DisclaimerThis book is designed to provide information about IPsec virtual private networks. Every effort has been made to make this book ascomplete 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 norresponsibility to any person or entity with respect to any loss or damages arising from the information contained in this book or fromthe 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.

    Corporate and Government SalesCisco 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 [email protected]

    For sales outside the U.S. please contact: International Sales [email protected]

    Feedback InformationAt Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each book is crafted with care and pre-cision, 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 qualityof this book, or otherwise alter it to better suit your needs, you can contact us through e-mail at [email protected]. Pleasemake sure to include the book title and ISBN in your message.

    We greatly appreciate your assistance.

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals



    Publisher Paul Boger

    Cisco Representative Anthony Wolfenden

    Cisco Press Program Manager Jeff Brady

    Executive Editor Brett Bartow

    Production Manager Patrick KanouseDevelopment Editor Andrew Cupp

    Project Editor Interactive Composition Corporation

    Copy Editor Interactive Composition Corporation

    Technical Editors Aamer Akhter, Jason Guy, Mark J. Newcomb

    Editorial Assistant Katherine Linder

    Book and Cover Designer Louisa Adair

    Composition Interactive Composition Corporation

    Indexer Tim Wright

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals



    About the AuthorJames Henry Carmouche, CCIE No. 6085,is a technical marketing engineer on the Cisco

    Enterprise Systems Engineering team, where he is currently responsible for architecting,

    constructing, and validating enterprise-class network systems solutions. As part of his solution

    development responsibilities, Henry researches and publishes solution reference designs for use

    by customers, technical sales staff members, and marketing staff members. Prior to joining ESE,

    Henry worked as a technical marketing engineer in the Cisco Government Systems Unit, where

    he was responsible for bringing advanced security products to market, building technical

    marketing collateral and presentations, and designing new product introduction training for the

    GSUs newly introduced security platforms. In addition to his product and solution development

    experience, Henry has more than six years of technical consulting experience, including three

    years as a network consulting engineer in the Cisco Advanced Services Group. Henry earned an

    M.B.A. degree from UNCs Kenan-Flagler Business School and a B.S. degree in mechanical

    engineering from Lehigh University. Henry currently lives in Chapel Hill, NC, with his wife and

    two sons.

    About the Technical ReviewersAamer Akhter, CCIE No. 4543,joined Cisco Systems in 1998 after graduating from Georgia

    Tech with a B.S. degree in electrical engineering to work in the Cisco Technical Assistance Center.

    He then supported the larger enterprise customers from Cisco in the NSA unit, where he helped

    design and deploy several large Layer 2 networks. Aamer later moved to Networked Solutions

    Integration Test Engineering (NSITE), where after a brief stint with IPsec VPNs, he moved into a

    new group for testing MPLS-VPNs. Five years later, MPLS-VPNS had matured much but testing

    of MPLS-related technologies still continues. Aamer is currently leading a team for testing Layer3 VPNs and related technologies in a cross-Cisco effort.

    Jason Guyis an engineer within the Cisco Systems NSITE Security team, an organization

    responsible for network-based security solution testing. Jason is a member of a team responsible

    for testing, validating, scaling, and assisting in deployment of the Cisco security solution. Jasons

    primary focus is on firewalls, IPsec Remote Access, and SSL VPN testing. Prior to his work on the

    security technologies, Jason worked on the AToM Layer 2 VPN and MPLS VPN teams. Jason

    received his Masters of Computer Engineering degree from North Carolina State University in

    Raleigh, NC.

    Mark J. Newcomb, CCNP, CCDP,is a retired network security engineer. Mark has more than

    20 years experience in the networking industry, focusing on the financial and medical industries.

    Mark is a frequent contributor and reviewer for Cisco Press books.

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals



    DedicationFor my loving wife, Kristen, and my two wonderful sons, James and Charlie. This would not have

    been possible without your unconditional love, support, and inspiration.

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals



    AcknowledgmentsDuring the development of this book, I had the privilege to work in three different groups at Cisco.

    Thank you to all of my teammates in Enterprise Systems Engineering, the Government Systems

    Unit, and Advanced Services who have lent me your professional acumen and loyal friendship

    over the years.

    Id like to thank Mike OShea for his support and friendship over the course of developing this

    book. Mikes sound professional and personal advice have helped me endure the ebbs and flows

    of sanity while balancing a challenging workload and added development responsibilities

    associated with writing this book.

    Thank you to Pavan Reddy, one of the sharpest technical minds in Advanced Services, who was

    instrumental in helping me outline and define this scope of work and whose technical advice and

    words of encouragement throughout the course of developing this book have proven to be


    And on that note, many thanks go out to Andrew Cupp and Brett Bartow for their patience,

    understanding, and support during this process. An author could not have asked for a more

    professional team to work with while developing and publishing his work.

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals



    This Book Is Safari EnabledThe SafariEnabled icon on the cover of your favorite technology book

    means the book is available through Safari Bookshelf. When you buy this

    book, you get free access to the online edition for 45 days.

    Safari Bookshelf is an electronic reference library that lets you easily search

    thousands of technical books, find code samples, download chapters, and

    access technical information whenever and wherever you need it.

    To gain 45-day Safari Enabled access to this book:

    Go to

    Complete the brief registration form

    Enter the coupon code 6LL4-NBLJ-5EK4-HDJP-PKVQIf you have difficulty registering on Safari Bookshelf or accessing the online

    edition, please e-mail [email protected].

    From the Library of Ah
  • 7/13/2019 IPSEC VPN Fundamentals



    Contents at a Glance

    Introduction xvii

    Part I Introductory Concepts and Configuration/Troubleshooting 3

    Chapter 1 Introduction to VPN Technologies 5

    Chapter 2 IPsec Fundamentals 35

    Chapter 3 Basic IPsec VPN Topologies and Configurations 105

    Chapter 4 Common IPsec VPN Issues 141

    Part II Designing VPN Architectures 205

    Chapter 5 Designing for High Availability 207

    Chapter 6 Solutions for Local Site-to-Site High Availability 235

    Chapter 7 Solutions for Geographic Site-to-Site High Availability 267

    Chapter 8 Handling Vendor Interoperability with High Availability 297

    Chapter 9 Solutions for Remote-Access VPN High Availability 313

    Chapter 10 Further Architectural Options for IPsec 359

    Part III Advanced Topics 389

    Chapter 11 Public Key Infrastructure and IPsec VPNs 391

    Chapter 12 Solutions for Handling Dynamically Addressed Peers 417

    Appendix A Resources 449

    Index 452

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals




    Introduction xvii

    Part I Introductory Concepts and Configuration/Troubleshooting 3

    Chapter 1 Introduction to VPN Technologies 5VPN Overview of Common Terms 5

    Characteristics of an Effective VPN 6

    VPN Technologies 9

    Virtual Private Dialup Networks 10

    Layer 2 Forwarding Protocol 10

    Point-to-Point Tunneling Protocol 12

    Layer 2 Tunneling Protocol 16

    Multiprotocol Label Switching VPNs 18

    IPsec VPNs 20

    Transport Layer VPNs 21Secure Socket Layer VPNs 21

    Transport Layer Security and SSL VPNs 25

    Common VPN Deployments 25

    Site-to-Site VPNs 25

    Remote Access VPNs 28

    SSL in RAVPN Architectures 28

    Business Drivers for VPNs 29

    Remote Access VPN Business DriversA Practical Example 30

    Site-to-Site VPN Business DriversA Practical Example 30

    IPsec VPNs and the Cisco Security Framework 31

    Summary 32

    Chapter 2 IPsec Fundamentals 35

    Overview of Cryptographic Components 35

    Asymmetric Encryption 36

    Symmetric Encryption 39

    Message Authentication, Message Integrity, and Sender Nonrepudiation Mechanisms 42

    Hashing and Message Digests 42

    Digital Signatures 44

    Public Key Encryption Methods 46

    RSA Public-Key Technologies 48

    RSA Encryption 48RSA Signatures 50

    Diffie-Hellman Key Exchange 51

    The IP Security Protocol (IPsec) 51

    IPsec Modes 52

    Transport Mode 52

    Tunnel Mode 54

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals



    IPsec Transforms 55

    ESP 55

    AH 57

    IP Payload Compression Protocol (IPPCP) and LZS 58

    IPsec SA 59

    IPsec Configuration Elements 63

    Creating an IPsec Transform 63

    Crypto Map Configuration 66

    Manual Keying 68

    The Need for Security Association and Key Management 77

    IKE and ISAKMP 78

    IKE and ISAKMP Terminology and Background 78

    IKE SA Negotiation and Maintenance 79

    IPsec Diffie-Hellman Shared Secret Key Generation Using IKE 79

    IKE Authentication Services 83

    Pre-Shared Keys 83RSA Encryption (Encrypted Nonces) 85

    RSA Signatures and X.509 Certificates 86

    IKE Phase I Negotiation 87

    Main Mode 88

    Aggressive Mode 89

    IKE Phase II Negotiation 90

    Quick Mode 90

    PFS 91

    Dead Peer Detection and IKE Keepalives 92

    Configuring ISAKMP 94

    IKE with RAVPN Extensions 96Mode Configuration 96

    X-Auth 98

    Summary 100

    Chapter 3 Basic IPsec VPN Topologies and Configurations 105

    Site-to-Site IPsec VPN Deployments 107

    Site-to-Site VPN Architectural Overview for a Dedicated Circuit 107

    Cisco IOS Site-to-Site IPsec VPN Configuration 108

    Verifying Cisco IOS Site-to-Site IPsec VPN Operation 111

    Site-to-Site Architectural Overview over a Routed Domain 117

    Site-to-Site IPsec VPN Deployments and GRE (IPsec+GRE) 121Site-to-Site IPsec+GRE Architectural Overview 121

    Increased Packet Size and Path MTU Considerations 122

    GRE and Weighted Fair Queuing 122

    QoS and the IPsec Anti-Replay Window 122

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals



    Site-to-Site IPsec+GRE Sample Configurations 123

    Cisco IOS Site-to-Site IPsec+GRE Configuration 123

    Verification of IPsec+GRE Tunnel Establishment 126

    Hub-and-Spoke IPsec VPN Deployments 128

    Hub-and-Spoke Architectural Overview 129Standard Hub-and-Spoke Design without High Availability 129

    Clustered Spoke Design to Redundant Hubs 130

    Redundant Clustered Spoke Design to Redundant Hubs 131

    Remote Access VPN Deployments 132

    RAVPN Architectural Overview 132

    RAVPN Clients 132

    Standalone VPN Concentrator Designs 133

    VPN Concentrator on Outside Network with Single DMZ 133

    VPN Concentrator and Firewall in Parallel 134

    VPN Concentrator with Dual DMZs to Firewall 135

    What to Avoid in DMZ/VPN Concentrator Topologies 136Clustered VPN Concentrator Designs 137

    Summary 138

    Chapter 4 Common IPsec VPN Issues 141

    IPsec Diagnostic Tools within Cisco IOS 141

    Common Configuration Issues with IPsec VPNs 142

    IKE SA Proposal Mismatches 142

    IKE Authentication Failures and Errors 146

    IKE Authentication Errors and PSKs 146

    IKE Authentication Errors with RSA Encryption 151

    IKE Authentication Errors with RSA Signatures 158IPsec SA Proposal Mismatches 165

    Crypto-Protected Address Space Issues (Crypto ACL Errors) 169

    Architectural and Design Issues with IPsec VPNs 171

    Troubleshooting IPsec VPNs in Firewalled Environments 171

    Allowing the Required IPsec Protocols to Pass 171

    Firewalls Handling of Fragmented IPsec Packets 173

    Filtering of ICMP Unreachables 174

    NAT Issues in IPsec VPN Designs 174

    Intrinsic IPsec/NAT Incompatibilities 175

    IPsec NAT Transparency (NAT-T) 178

    SPI-Based NAT 179The Influence of IPsec on Traffic Flows Requiring QoS 180

    IPsecs Influence on DiffServ and LLQ/CBWFQ 181

    IPsecs Effect on IntServ and RSVP 183

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals



    Solving Fragmentation Issues in IPsec VPNs 183

    Path MTU Discovery 184

    Fragmentation Behavior on Cisco IOS VPN Endpoints 189

    Solutions for Preventing Fragmentation 193

    The Effect of Recursive Routing on IPsec VPNs 197

    Summary 200

    Part II Designing VPN Architectures 205

    Chapter 5 Designing for High Availability 207

    Network and Path Redundancy 208

    IPSec Tunnel Termination Redundancy 210

    Multiple Physical Interface HA with Highly Available Tunnel Termination Interfaces 210

    Tunnel Termination HA Using HSRP/VRRP Virtual Interfaces 211

    HA with Multiple Peer Statements 212

    RP-based IPSec HA 214

    Managing Peer and Path Availability 215Peer Availability 216

    Path Availability 218

    Managing Path Symmetry 219

    Load Balancing, Load Sharing, and High Availability 222

    Load-Sharing with Peer Statements 222

    Routing 224

    Domain Name System (DNS) 225

    Cisco VPN3000 Concentrator Clustering 227

    IPSec Session Load-Balancing Using External Load Balancers 230

    Summary 232

    Chapter 6 Solutions for Local Site-to-Site High Availability 235

    Using Multiple Crypto Interfaces for High Availability 235

    Impact of Routing Protocol Reconvergence on IPsec Reconvergence 238

    Impact of Stale SAs on IPsec Reconvergence 240

    Impact of IPsec and ISAKMP SA Renegotiation on IPsec Reconvergence 241

    Stateless IPsec VPN High-Availability Alternatives 242

    Solution Overview for Stateless IPsec High Availability 242

    Hot Standby Routing Protocol 244

    RRI 245

    Stateless High Availability Failover Process 246

    Step 1: Initial IPsec VPN Tunnel Establishment 247

    Step 2: Pre-HSRP RRI Execution 251

    Step 3: Active Router Failure 254

    Step 4: HSRP Reconvergence 254

    Step 5: IPsec Reconvergence 255

    Step 6: Post-HSRP RRI Execution 257

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals



    Stateful IPsec VPN High-Availability Alternatives 257

    Solution Overview for Stateful IPsec High Availability 258

    HSRP and RRI 259

    Stateful Switchover (SSO) and IPsec High Availability 259

    Stateful High Availability Failover Process 261Step 1: Initial IPsec VPN Tunnel Establishment 261

    Step 2: SADB Synchronization with SSO 261

    Step 3: Pre-HSRP Failover RRI Execution 262

    Step 4: Active Router Failure 262

    Step 5: HSRP Reconvergence 262

    Step 6: IPsec Reconvergence 262

    Step 7: Post-HSRP RRI Execution 263

    Summary 263

    Stateless IPsec VPN High Availability Design Summary 263

    Stateful IPsec VPN High Availability Design Summary 265

    Chapter 7 Solutions for Geographic Site-to-Site High Availability 267

    Geographic IPsec VPN HA with Reverse Route Injection and Multiple IPsec Peers 267

    Solution Overview for RRI with Multiple IPsec Peers 267

    Geographic IPsec VPN High Availability with IPsec+GRE and Encrypted Routing

    Protocols 278

    Solution Overview for IPsec+GRE with Encrypted Routing Protocols 279

    Dynamic Multipoint Virtual Private Networks 287

    DMVPN Solution Design Drivers 288

    DMVPN Component-Level Overview and System Operation 289

    Summary 295

    Chapter 8 Handling Vendor Interoperability with High Availability 297Vendor Interoperability Impact on Peer Availability 297

    The Inability to Specify Multiple Peers 297

    Lack of Peer Availability Mechanisms 300

    Vendor Interoperability Impact on Path Availability 301

    IPSec HA Design Considerations for Platforms with Limited Routing

    Protocol Support 302

    IPSec HA Design Considerations for Lack of RRI Support 304

    IPSec HA Design Considerations for Lack of Generic Routing Encapsulation (GRE)

    Support 305

    Vendor Interoperability Design Considerations and Options 306Phase 1 and 2 SA Lifetime Expiry 307

    SADB Management with Quick Mode Delete Notify Messages 307

    Invalid Security Parameter Index Recovery 308

    Vendor Interoperability with Stateful IPSec HA 309

    Summary 311

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals



    Chapter 9 Solutions for Remote-Access VPN High Availability 313

    IPsec RAVPN Concentrator High Availability Using Virtual Interfaces for Tunnel

    Termination 314

    IPsec RAVPN Concentrator High Availability Using VRRP 315

    IPsec RAVPN Concentrator HA Using HSRP 327IPsec RAVPN Concentrator HA Using the VCA Protocol 333

    IPsec RAVPN Geographic HA Design Options 342

    VPN Concentrator Session Load Balancing Using DNS 343

    VPN Concentrator Redundancy Using Multiple Peers 345

    Summary 355

    Chapter 10 Further Architectural Options for IPsec 359

    IPsec VPN Termination On-a-Stick 359

    IPsec with Router-on-a-Stick Design Overview 359

    Single, Flatly Addressed L3 Domain 360

    Lack of In-Path Design Options 361Single Interface to the Bridged LAN 361

    Crypto-Enabled Loopback Interface 361

    Case Study: Small Branch IPsec VPN Tunnel Termination with NAT On-a-Stick 362

    In-Path Versus Out-of-Path Encryption with IPsec 368

    Out-of-Path Encryption Design Overview 370

    Case Study: Firewalled Site-to-Site IPsec VPN Tunnel Termination 370

    Separate Termination of IPsec and GRE (GRE-Offload) 379

    GRE-Offload Design Overview 379

    Lack of Support for GRE Processing 380

    Low GRE Performance 380

    Case Study: Large-Scale IPsec VPN Tunnel Termination with GRE Offload 382Dynamic Crypto Maps and GRE-Offload 383

    IKE Extended Authentication (X-Auth) 384

    Firewalled Cleartext Traffic 385

    High-Speed GRE Tunnel Termination for GRE-Offload 385

    Summary 386

    Part III Advanced Topics 389

    Chapter 11 Public Key Infrastructure and IPsec VPNs 391

    PKI Background 391

    PKI Components 394

    Public Key Certificates 394

    Registration Authorities 395

    Certificate Revocation Lists and CRL Issuers 396

    Certificate Authorities 397

    PKI Cryptographic Endpoints 397

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals



    Life of a Public Key Certificate 397

    RSA Signatures and X.509v3 Certificates 397

    Generating Asymmetric Keypairs on Cryptographic Endpoints 402

    Registration and Endpoint Authentication 402

    Receipt and Authentication of the CAs Certificate 403Forwarding and Signing of Public Keys 403

    Obtaining and Using Public Key Certificates 403

    PKI and the IPSec Protocol SuiteWhere PKI Fits into the IPSec model 404

    OCSP and CRL Scalability 404

    OCSP 405

    Case Studies and Sample Configurations 405

    Case Study 1: PKI Integration of Cryptographic Endpoints 407

    Case Study 2: PKI with CA and RA 410

    Case Study 3: PKI with Redundant CAs (CA Hierarchy) 412

    Summary 414

    Chapter 12 Solutions for Handling Dynamically Addressed Peers 417

    Dynamic Crypto Maps 417

    Dynamic Crypto Map Impact on VPN Behavior 418

    Dynamic Crypto Map Impact on ISAKMP/IKE 418

    Routing Considerations with Dynamic Crypto Maps 419

    Security Considerations for Dynamic Crypto Maps 421

    Dynamic Crypto Map Configuration and Verification 425

    Tunnel Endpoint Discovery 430

    TED Configuration and Verification 432

    Case StudyUsing Dynamic Addressing with Low-Maintenance Small Home Office

    Deployments 432Summary 446

    Appendix A Resources 449

    Books 449

    RFCs 449

    Web and Other Resources 450

    Index 452

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals



    Command Syntax ConventionsThe conventions used to present command syntax in this book are the same conventions used in

    the IOS Command Reference. The Command Reference describes these conventions as follows:

    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 showcommand).

    Italicsindicate 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.

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals



    IntroductionIn recent years, network security solutions have grown to include IPsec as a critical component

    of secure network architecture design. One primary objective of this publication is therefore

    to provide the reader with a basic working knowledge of IPsec on various Cisco routing and

    switching platforms and an understanding of the different components of the Cisco IPsec

    implementation. This book covers successful implementation of IPsec in a variety of network

    topologies. This book views IPsec as an emerging requirement in most major vertical markets

    (service provider, enterprise financial, government), explaining the need for increased information

    authentication, confidentiality, and non repudiation for secure transmission of confidential data

    (government records, financial data, billing information).

    The primary development objective of this book is to create a work that aids network architects,

    administrators, and managers in their efforts to integrate IPsec VPN technology into their existing

    IP infrastructures. The focus is on IPsec deployments in Cisco network environments, from simple

    site-to-site virtual private network (VPN) configurations to comprehensive VPN strategies,including architectural redundancy and interoperability.

    MethodologyThis book follows a tiered approach toward building a working knowledge of fundamental IPsec

    VPN design, starting with an overview of basic IPsec business drivers and functional components.

    These concepts and components are then used as a foundation upon which IPsec VPN High

    Availability (HA) design considerations are presented. Lastly, several advanced IPsec VPN

    technologies that are commonly available in todays enterprise networks are presented and

    discussed. Within each chapter, the design concepts are presented and then reinforced withconfigurations, illustrations, and practical case studies where appropriate.

    Who Should Read This Book?This book presents information for technically savvy individuals who want to further their

    understanding of the fundamentals of this specific technology. Those parties interested in this

    book most likely include network engineers, network design consultants, network administrators,

    systems administrators, information security specialists, and all other individuals who have an

    interest in securing their networks with Cisco routers and VPN products. Additionally, networking

    professionals who have an understanding of IPsec and also want to view typical Cisco specific

    IPsec configurations and practical IPsec deployment examples on Cisco products may also find

    the design guidance provided in this book valuable. Because it provides information at a

    fundamental level, this book may also serve as an effective design reference for decision makers

    looking to make strategic decisions impacting the security of their organizations network.

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals



    How This Book Is OrganizedThe organization of the book is formatted in a layered approach, starting with a basic explanation

    of the motivation behind IPsecs development and the types of organizations that rely on IPsec to

    secure data transmissions. The book then proceeds to outline the basic IPsec/Internet Security

    Association and Key Management Protocol (ISAKMP) fundamentals that were developed to meetdemand for secure data transmission. The book proceeds to cover the design and implementation

    of IPsec VPN architectures using an array of Cisco products, starting with basic concepts and

    proceeding to more advanced topics, including HA solutions and public key infrastructure (PKI).

    Sample topology diagrams and configuration examples are provided to help reinforce the

    fundamentals expressed in the text, and to assist the reader in translating explained IPsec concepts

    into practical working deployment scenarios. Case studies are incorporated throughout the text in

    order to map the topics and concepts discussed to real-world solutions.

    Chapters 1 through 4 compose Part I of this book, covering the most basic concepts required to

    develop an understanding of IPsec VPNs. The chapter content provided in Part I aims to help thereader achieve the following objectives:

    Understand the background of IPsec VPN development

    Differentiate IPSEC/SSL VPN from other VPN technologies

    Understand the underlying cryptographic technologies that compose an IPsec VPN

    Understand basic IPsec VPN configuration techniques

    Understand common issues that can affect all IPsec designs

    After you are familiar with the content of Part I, you should have the working knowledge of IPsec

    VPNs necessary to begin building a knowledge base surrounding the fundamentals of IPsec VPNHigh Availability using the design concepts provided in Part II. The chapters in Part I include:

    Chapter 1, Introduction to VPN TechnologiesThis chapter includes an introduction

    to various VPN technologies, discusses how VPNs are utilized in todays networks, and

    identifies the drivers for business migration to VPN technologies. The discussion in this

    chapter provides the reader with a high-level overview of VPN, particularly with a

    comparison between Multiprotocol Label Switching (MPLS), Virtual Private Dialup Network

    (VPDN), Secure Sockets Layer (SSL), and IPsec VPNs. After a brief comparison of the VPN

    technologies, the focus turns to the business drivers for VPN, which include both economics

    and security.

    Chapter 2, IPsec FundamentalsThis chapter focuses on the underlying components

    and mechanics of IPsec, including cryptographic components, Internet Key Exchange (IKE),

    and IPsec. This chapter includes basic configuration examples (not step-by-step) to

    demonstrate the concepts.

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals



    Chapter 3, Basic IPsec VPN Topologies and ConfigurationsThis chapter

    demonstrates building of basic VPN topologies using the knowledge gained in the previous

    chapters. Three basic topologies are discussed: hub-and-spoke without generic routing

    encapsulation (GRE), hub-and-spoke VPN with GRE, and remote-access VPN.

    Chapter 4, Common IPsec VPN IssuesIPsec deployments can involve a number ofpotential pitfalls if not properly addressed. Chapter 4 discusses the common IPsec VPN issues

    that a network engineer should take into consideration during the design and deployment

    process. It discusses common troubleshooting techniques to diagnose these problems should

    they occur in your network. Design solutions to the common VPN issues presented in this

    chapter are provided, along with the appropriate design verification techniques.

    Part II consists of Chapters 5 through 10. The topics discussed here build on the introductory

    concepts from Part I, extending them to encompass a common architectural goal: High

    Availability. Additional architectural variations are provided so as to present a comprehensive

    scope of design options available. The chapters in Part II include:

    Chapter 5, Designing for High AvailabilityThis chapter discusses the basic principles

    of an HA VPN design. Based on these principles, subsequent chapters develop solutions for

    local and geographical HA and discuss issues and options for achieving HA in multi-vendor

    VPN environments.

    Chapter 6, Solutions for Local Site-to-Site High AvailabilityThis chapter uses

    concepts previously described to develop solutions for local HA, including the use of highly

    available interface for IPsec tunnel termination, stateless tunnel termination HA, and stateful

    tunnel termination HA.

    Chapter 7, Solutions for Geographic Site-to-Site High AvailabilityThis chapter usesconcepts previously described to develop solutions for geographic HA. This chapter discusses

    RRI, IPsec with GRE tunnels, and Dynamic Multipoint VPN.

    Chapter 8, Handling Vendor Interoperability with High AvailabilityUnfortunately,

    current IPsec standards do not address HA. This leads to interoperability issues among

    vendors. This chapter discusses common issues and details the options that exist to handle

    these scenarios.

    Chapter 9, Solutions for Remote Access VPN High AvailabilityThis chapter discusses

    the HA concepts previously discussed in Chapters 6 and 7 in the context of RAVPN

    deployments. Additionally, it covers other HA tools commonly found in RAVPNs, including

    the use of VPN concentrator clustering with VCA and DNS-based load balancing.

    Chapter 10, Further Architectural Options for IPsecThis chapter discusses other

    architectural variations in designing VPN solutions. It describes each option with usage

    considerations and finishes with case studies of each.

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals



    IPsec VPN design concepts range from fundamental cryptographic operations to dynamic spoke-

    to-spoke peering and MPLS VPN routing and forwarding (VRF)-Aware IPsec VPNS. Although

    the scope of this book is firmly centered around the fundamental concepts of IPsec VPN design,

    the chapters included in Part III provide design guidance around two advanced topics of IPsec that

    are quite commonly deployed in todays enterprise-class IP networks:

    Chapter 11, Public Key Infrastructure and IPsec VPNsThis chapter discusses the

    usage of public key infrastructure (PKI) to authenticate IPsec peers via Rivest, Shamir, and

    Adelman (RSA) signatures. This method uses a certificate authority as a trusted third party to

    secure and scale IKE authentication. As organizations become more Public Key Infrastructure

    (PKI)-aware, this will become the de facto authentication mechanism.

    Chapter 12, Solutions for Handling Dynamically Addressed PeersDynamic peers

    allow network administrators to ensure network connectivity when remote network peers are

    either not known in advance or change to an unknown value over time. Dynamic peers also

    require less administrative effort than do static peers. This chapter addresses IPsec dynamicpeering options, some of which are less commonly used, and others that are more prolific in

    various architectures.

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    This page intentionally left blank

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    Part I: Introductory Concepts and


    Chapter 1 Introduction to VPN Technologies

    Chapter 2 IPsec Fundamentals

    Chapter 3 Basic IPsec VPN Topologies and Configurations

    Chapter 4 Common IPsec VPN Issues

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    C H A P T E R 1

    Introduction to VPN


    Modern business environments have been consistently changing since the advent of the Internet

    in the 1990s. Now more than ever, organizational leaders are asking themselves how efficiencies

    can be gained through making their workforce more mobile and thus increasing the scope of

    sales and distribution channels while continuing to maximize the economies of scope in their

    existing data infrastructure investments. Virtual private network (VPN) technologies provide

    a means by which to realize these business efficiencies in tandem with greatly reduced IT

    operational expenditures. In this chapter, we will discuss how todays VPN technologies enable

    enterprise workforces to share data seamlessly and securely over common yet separately

    maintained network infrastructures, such as through an Internet service provider (ISP) between

    enterprise networks or with corporate extranet partners. We will introduce several IPsec VPN

    topologies commonly found in todays enterprise networks, and we will conclude with the

    overview of two IPsec VPN business models, complete with cost savings realized by the


    VPN Overview of Common TermsA VPNis a means to securely and privately transmit data over an unsecured and shared network

    infrastructure. VPNs secure the data that is transmitted across this common infrastructure by

    encapsulating the data, encrypting the data, or both encapsulating the data and then encrypting

    the data. In the context of VPN deployments, encapsulation is often referred to as tunneling, as

    it is a method that effectively transmits data from one network to another transparently across a

    shared network infrastructure.

    A common encapsulationmethod found in VPNs today is Generic Routing Encapsulation

    (GRE). IP-based GRE is defined in IETF RFC 2784 as a means to enclose the IP header and

    payload with a GRE-encapsulation header. Network designers use this method of encapsulationto hide the IP header as part of the GRE-encapsulated payload. In doing so, they separate or

    tunnel data from one network to another without making changes to the underlying common

    network infrastructure. Although GRE tunnels have primitive forms of authentication, as well

    explore in later chapters when discussing dynamic multipoint VPN (DMVPN) deployments,

    they currently provide no means to provide confidentiality, integrity, and non-repudiation

    natively. Nevertheless, GRE tunneling is a fundamental component of many different IP

    Security Protocol (IPsec) designs, and will be discussed frequently in subsequent chapters.

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    6 Chapter 1: Introduction to VPN Technologies

    Encryptionrefers to the act of coding a given message into a different format, while decryptionrefers to decoding an encrypted message into its original unencrypted format. For encryption to

    be an effective mechanism for implementing a VPN, this encrypted, encoded format must only

    be decipherable by those whom the encrypting party trusts. In order to deliver upon these

    requirements, encryption technologies generally require the use of a mathematical operation,

    usually referred to as an algorithm, or cipher, and a key. Although generally complex in nature,

    mathematical functions are known. It is the symmetric key, or as youll see in the case of

    asymmetric cryptography, the private key, that is to be kept unknown to would-be attackers. The

    key is the primary way to keep the encrypted tunnel secure. This book discusses these two

    common types of cryptographic operations: symmetric key encryption and asymmetric key

    encryption. Other types of encryption discussed in the framework of this book include securehashes and digital signatures.

    Characteristics of an Effective VPN

    VPNs exist to effectively, securely, and privately protect data that is transmitted between two

    networks from the common, shared, and separately maintained infrastructure between the

    two networks. In order to effectively perform this task, there are four goals that a confidential VPN

    implementation must meet:

    Data confidentiality: Protects the message contents from being interpreted byunauthenticated or unauthorized sources.

    Data integrity: Guarantees that the message contents have not been tampered with or altered

    in transit from source to destination.

    Sender non-repudiation: A means to prevent a sender from falsely denying that they had

    sent a message to the receiver.

    Message authentication: Ensures that a message was sent from an authentic source and that

    messages are being sent to authentic destinations.

    Incorporating the appropriate data confidentialitycapabilities into a VPN ensures that only the

    intended sources and destinations are capable of interpreting the original message contents. IPsec

    is very effective at encrypting data using the encapsulating security protocol (ESP), described

    in RFC 1827. Utilizing ESP, IPsec transforms clear text in to encrypted data, or ciphertext.

    Because ESP-transformed messages are only sent across in their ciphered representations, the

    original contents of the message are kept confidential from would be interceptors of the

    NOTE Although IPSec-processed data is encrypted, it is also encapsulated with either

    Encapsulating Standard Protocol (ESP) or Authentication Headers (AH).

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    Characteristics of an Effective VPN 7

    message. Figure 1-1 illustrates a high-level exchange of encrypted message between to endpoints,

    James and Charlie.

    Figure 1-1 Confidentiality and Authenticity in Encrypted Communications

    Encrypting messages relies on the use of a key to encrypt clear text and to decrypt ciphered

    messages. In the exchange of messages in Figure 1-1, both James and Charlie require the

    appropriate keys to encrypt and decrypt communications from each other. Assuming that these

    keys were exchanged or derived securely (for example, via a Diffie-Hellman exchange, which is

    discussed in detail in Chapter 2, IPsec Fundamentals), when James receives a message from

    Charlie that he is able to decrypt, he can be assured that the message has been delivered with full

    confidentiality,and vice versa.

    Hashes and digital signatures protect the integrity of a specific communication of data. Hashes and

    digital signatures append unique messages to the original message before transmission that ensure

    that the message has not been tampered with in transit. Figure 1-2 illustrates the operation of a

    hash performed on a message to ensure data integrity.

    By providing a unique fingerprint specific only to the sender of the message, a digital signature

    also provides the receiver a method of message authentication and sender non-repudiation.

    Notice in Figure 1-3 that digital signatures require the use of a public decryption key unique to the

    sender's private encryption key. The use of this cryptographic keypair thus guarantees message

    authenticity, ensuring that the message was sent from the authentic origin, and safeguards against

    sender non-repudiation, preventing a situation in which the sender of a specific message

    intentionally and falsely denies their transmittal of the message. While a secure hash can

    provide data integrity, digital signatures provide added levels of security by offering message

    authentication and sender non-repudiation, the operation of which is illustrated in Figure 1-3.

    Hey Charlie, what did youlearn at school today?


    Plain Text

    Cipher Text:


    Charlies Encryption Key

    Hey Charlie, what did youlearn at school today?


    Plain Text

    Cipher Text:

    Charlies Decryption KeyCipher:





    Charlie shares his encryptionkey only with James

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    8 Chapter 1: Introduction to VPN Technologies

    Figure 1-2 Data Integrity, Secure Hashes

    Figure 1-3 Message Authenticity and Data Non-Repudiation with Digital Signatures

    Hey Charlie, what did youlearn at school today?

    Charlie separates James messagedigest from original message

    Charlie verifies the Jamesmessage digest with his own


    Hey Charlie, what did youlearn at school today?


    Plain Text

    Hash Value:


    Hey Charlie, what did youlearn at school today?


    Plain Text

    Hash Value:


    Hash Value:






    Hey Charlie, what did youlearn at school today?

    Charlie separates James messagedigest from original message

    Charlie verifies the Jamesmessage digest with his own

    Plain Text

    JamesEncryption Key

    JamesDecryption Key

    Hash Value:

    James Charlie

    Hash Value:James encrypts themessage digest

    Charliedecryptsthe digitalsignature




    Hey Charlie, what did youlearn at school today?

    James appends messagedigest to original message



    Hash Value:






    Hey Charlie, what did youlearn at school today?

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    VPN Technologies 9

    VPN Technologies

    Although IPsec-based VPNs represent one of the most secure and widely deployed types of VPNs,

    they are only one of many VPN technologies in existence today. As well discuss throughout the

    course of this book, VPNs have been designed to protect data at almost every layer of the OSI

    stack. For example, customers in different market verticals will deploy a range of encryption

    technologies, from Layer 1 bulk encryptors to encryption technologies embedded within the

    applications themselves (SSL-based VPNs).

    The OSI model consists of 7 layers, Physical, Data-Link, Network, Transport, Session,

    Presentation, and Application. Although our primary focus will be IPsec VPNs, which are a Layer 3

    VPN technology, it is important to understand IPsec VPNs within the context of other VPN

    technologies corresponding to different layers within the OSI stack. Figure 1-4 illustrates the OSI

    stack and provides some examples of VPN technologies that operate at each corresponding

    OSI layer

    Figure 1-4 VPN Technologies and the OSI Model





    IPSec Deployments,MPLS VPNs

    VPDN-PPTP, L2TP, L2FATM Cell Encryptors

    Frame-Relay Frame Encryptors

    Optical Bulk EncryptorsRadio Frequency (RF)


    Layer 7, Application

    Open-Standard Interconnect (OSI)Model Layer VPN Technology

    Layer 6, Presentation

    Layer 5, Session

    Layer 4, Transport

    Layer 3, Network

    Layer 2, Data Link

    Layer 1, Physical

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    10 Chapter 1: Introduction to VPN Technologies

    Virtual Private Dialup Networks

    Virtual private dialup networks (VPDN)are used to tunnel data across a shared media. Although

    the primary goal of a VPDN is to tunnel data across shared network infrastructures, some VPDNs

    may also incorporate data confidentiality. Most VPDNs rely on the use of PPP to encapsulate

    data in transit across a common network infrastructure. Typical VPDN deployments consist ofone or many PPP clients establishing a PPP session that terminates on a device at the opposite

    end of the tunnel, usually located at a central location within the enterprise or service provider

    edge. In doing so, a secure point-to-point tunnel is established from the clients network to

    the PPP concentrator. After the tunnel has been established, the client's network appears as

    if it were the same network as the enterprise side, while the underlying common network

    infrastructure across which data is tunneled remains unchanged. Common VPDN technologies

    deployed in todays networks include Layer 2 Forwarding Protocol, Point-to-Point Tunneling

    Protocol, and Layer 2 Tunneling Protocol.

    Layer 2 Forwarding Protocol

    TheLayer 2 Forwarding (L2F) Protocolwas originally developed by Cisco Systems as a way

    to tunnel privately addressed IP, AppleTalk, and Novell Internet Protocol Exchange (IPX) over

    PPP or Serial Line Internet Protocol (SLIP) dialup connections over shared networks. In

    order to do this, this VPDN technology concentrates tunnels at a home gateway, allowing all

    dial-up networks to appearas if their physical point of termination is the home gateway itself,

    regardless of the location of their actualdialup termination point. L2F uses control messages

    on UDP port 1701 to establish the session. Once a tunnel is established, L2F-encapsulated

    packets are forwarded in parallel with L2F control datagrams. Both L2F control and payload

    datagrams are forwarded on UDP 1701. The L2F encapsulated PPP packets have the formatdescribed in Figure 1-5.

    Figure 1-5 L2F Data Packet Format

    During the creation of an L2F tunnel, initially a user dials into the Network Access

    Server (NAS), negotiates PPP, and is authenticated with either Password Authentication

    Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP), as illustrated in

    Figure 1-6.

    NOTE In an L2F environment, a home gateway refers to a gateway located at the corporate


    PPP Encapsulation PPP PayloadL2F EncapsulationUDP

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    VPN Technologies 11

    Figure 1-6 L2F Topology and Tunnel Establishment

    The following steps describe the creation of an L2F tunnel, as illustrated in the steps in

    Figure 1-6:

    1. NAS and the PPP client negotiate a PPP session. NAS authenticates the PPP client with

    CHAP (or, optionally, PAP).

    Once the PPP session has been authenticated, a series of exchanges are performed to offload

    the termination of the dialup session to the home gateway. Figure 1-7 illustrates the CHAP

    handshake between the PPP client and the NAS shown in Figure 1-6.

    2. NAS initiates a tunnel connection to the home gateway.

    3. The home gateway authenticates NAS against the authentication database (RADIUS or


    4. The home gateway confirms acceptance of the tunnel negotiation initiation request from NAS.

    NOTE The NAS can optionally authenticate PPP connections against the AAA (or in this

    case, Cisco Secure Access Control Server) server in the service provider cloud. Managing userconnections centrally would ease the administrative burden and provide additional accounting

    and user database synchronization capabilities (that is, synchronization with NT databases and

    automated backup of AAA data on peer CSACS databases).


    Cisco SecureACS, ISP


    Step 4

    Step 2

    Step 3

    Step 5

    Step 6Step 1


    PPP Client,Mobile Worker

    PPP Client,Branch Office

    PPP Client,Telecommuter

    PPP Client, SmallHome Office PPP Client,Mobile Worker

    Cisco SecureACS, Corporate

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    12 Chapter 1: Introduction to VPN Technologies

    Figure 1-7 PPP Authentication with CHAP

    5. The home gateway and PPP client negotiate additional authentication, authorization,

    accounting, IP addressing, and tunneling parameters.

    6. An L2F tunnel is established and maintained between the PPP client and the home gateway.

    Point-to-Point Tunneling Protocol

    Point-to-point Tunneling Protocol (PPTP),a technology originally created by Microsoft, provides

    a seamless integration of remote PPP capable devices into an enterprise network. PPTP leverages

    authentication parameters inherent to native PPP and the tunneling capabilities of GRE to

    establish a VPDN. After a client has established a PPTP tunnel to a concentrator on a centralized

    enterprise network resource, that client appears as if it were part of the enterprise network

    itself, regardless of the underlying common infrastructure that the data is tunneled across.

    Consider the following exchange between a small remote office network (the PPP client) and

    a corporate VPDN (PPTP) concentrator. Figure 1-8 illustrates the order of operations executed

    when a client accesses the VPDN using PPTP.

    The PPP client in this scenario needs to connect to their enterprise network. The corporations

    security policy mandates that data be separated from the common service provider infrastructure

    and that central network connectivity provided by the service provider must remain transparent

    to the PPP clients, who are PSTN or ISDN attached. In order to accomplish this task, PPTP is

    used to provide an end-to-end tunnel for PPP connections inbound to the service provider.

    NOTE For more information on L2F, refer to RFC 2341 at

    Step 1: PPP CHAP Authentication Operation

    1) Establish link (LCP);

    initiate PPP negotiation

    2) Select CHAP as PPP authentication scheme

    3) Acknowledge PPP authentication scheme

    4) Challenge

    5) Create one-way hash and use as response

    6) Create one-way hash; verify clients response; accept or reject connection

    PPP Client, SmallHome Office


    From the Library of Ah
  • 7/13/2019 IPSEC VPN Fundamentals


    VPN Technologies 13

    Figure 1-8 PPTP Topology and Tunnel Negotiation

    Generally, there are two different types of PPTP VPDN tunnels: compulsory tunnels and voluntary

    tunnels. Compulsorytunnels are formed when a PPP client accesses the NAS or PPTP Access

    Concentrator (PAC). The NAS/PAC in turn establishes a tunnel with the PPTP Network Server

    (PNS). Voluntarytunnels are formed when a PPP client directly negotiates a PPTP tunnel with

    the PNS. The creation of a voluntary PPTP tunnel executes the following steps (illustrated in

    Figure 1-8):

    1. The first step in the negotiation occurs when the PPP client establishes a connection with the

    NAS and is authenticated through a chosen form of PPP authenticationPAP, CHAP, or

    Microsoft CHAP (MS-CHAP). PPTP tunnels can be encrypted through the use of MicrosoftPoint-to-Point Encryption (MPPE) to provide confidentiality in VPDNs. Cisco IOS supports

    both 40- and 128-bit MPPE encryption. In order to encrypt a PPTP tunnel using MPPE, the

    network administrator must use MS-CHAP to authenticate PPP connections to the NAS.

    2. Now that the PPP client has accessed the service provider network, the client has IP

    connectivity to the PNS at its corporate headquarters. The PPP client and the PNS must

    maintain two connections to one anothera control connection and a tunnel protocol

    connection. The PPTP control connection maintains the connection state and negotiates call

    setup and teardown. As such, it must be established before the tunnel protocol connection can

    be established. Once an NAS receives the call from the PPP client, the next step in creating

    the VPDN connection is to either establish a compulsory tunnel from the NAS/PAC to the

    TIP Authentication of PPP sessions can be passed to a centrally managed authentication

    database, such as CSACS via RADIUS or TACACS+. Authenticating PPP sessions against a

    CSACS database greatly eases administration of user authentication data for VPN access.

    NAS/PAC PIX/PNSGatewayRouter

    Step 1

    Service ProviderNetwork


    Step 4

    Step 3

    Step 2


    PPP Client,Mobile Worker

    PPP Client,Branch Office

    PPP Client,Telecommuter

    PPP Client,Small Home Office

    PPP Client,Mobile Worker

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    14 Chapter 1: Introduction to VPN Technologies

    PNS or to establish a voluntary tunnel from the PPP client itself to the PNS. In Figure 1-8, the

    PPP client elects to establish a voluntary tunnel directly to the PNS. In this scenario, the PIX

    is acting as the PNS for the PPTP exchange. The client initiates the tunnel by establishing a

    TCP connection to the PNS on port 1723.

    3. Once the PPP client and the PNS have TCP connectivity, they can start to exchange PPTP

    tunnel negotiation information between them. The tunnel negotiation process consists of

    exchanging connection request and reply messages as defined in RFC 2673 between the PNS

    and the PPP client.

    4. Once the PPTP control connection has negotiated call setup, call maintenance, and tunnel

    parameters accordingly, a second session is establishedthe PPTP tunnel connection itself.

    The PPTP tunnel connectionuses a modified version of GRE to tunnel PPP frames over the

    IP cloud, which, in Figure 1-8, is the service provider network. The GRE-encapsulated formatof the PPTP tunneled packet is illustrated in Figure 1-9.

    Figure 1-9 PPTP Tunnel Protocol Data Structure

    The preceding scenario describes a voluntary PPTP tunnel negotiation between the PPP client,

    which also acts as its own PAC, and the corporate PIX Firewall, acting as the PNS. In a compulsory

    PPTP tunnel negotiation, the NAS would act as the PAC and would multiplex multiple sessions

    CAUTION In many cases, including the example in Figure 1-8, TCP port 1723 must be

    allowed through any corporate firewalls or other filtering security devices for PPTP to operate

    correctly. In this scenario, the PIX would be configured with the appropriate static translation

    and access list entry on its outside interface to allow TCP sessions from remote clients on port


    TIP As with PPP authentication on the NAS/PAC, PPTP connections on PIX firewalls and

    Cisco routers can be authenticated against a Cisco Secure ACS database using RADIUS or

    TACACS+. Implementing user accounts on a central CSACS database greatly eases

    administrative overhead.

    NOTE The header used in the PPTP encapsulation process is similar to a GRE header, with

    some slight modifications to the specification outlined in RFC 1701. The PPTP version of the

    GRE header includes an acknowledgment field to determine the rate at which packets aretraversing the PPTP tunnel.

    Data Link Header Data Link TrailerIP Header PPTP Header PPP Header PPP Payload

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    VPN Technologies 15

    from the PPTP clients into a single tunnel to the PIX, or PNS. The exchanges in a compulsory

    tunnel would follow the same steps chronologically, but would appear as displayed in

    Figure 1-10.

    Figure 1-10 A PPTP Compulsory Tunnel Setup between PAC and PNS

    As depicted in Figure 1-10, only a single tunnel is negotiated between the PAC/PNS pair. In avoluntary exchange, it is possible that all 5 PPP clients dialing into the NAS terminate separate

    tunnels with the PIX/PNS. As such, compulsory tunnel architectures can be used to keep tunnel

    termination overhead low on the PNS. In the examples in this chapter, the voluntary tunnel negotiation

    option could yield up to five times the tunnel maintenance of a compulsory tunnel negotiation

    option (five PPP clients initiating tunnels to the PIX in a voluntary arrangement vs. one tunnel

    initiated from the NAS in a compulsory setting).

    Compulsory tunnels, however, do not offer end-to-end confidentiality with MPPE. In the

    preceding compulsory arrangement, the PPP connections to the NAS would remain

    unencryptedonly the connection from the PAC to the PNS would be encrypted with MPPE.As such, those network administrators requiring fully confidential exchange of data in their

    PPTP environments should choose to allow their clients to voluntarily negotiate an end-to-end PPTP

    tunnel with the PNS or, in this case, the corporate PIX Firewall. In doing so, the network

    administrator can ensure that all legs of the VPDN from their remote dialup hosts using PPP to

    their corporate PNS are encrypted for end-to-end data confidentiality.

    NOTE Although both L2TP and PPTP support both voluntary and compulsory tunnels,Cisco IOS only supports voluntary and compulsory tunnels for L2TP. While voluntary

    PPTP tunnels are supported in Cisco IOS, compulsory PPTP tunnels are currently not


    NAS/PAC PIX/PNSGatewayRouter


    Service ProviderNetwork


    PPP Client

    PPP Client

    PPP Client

    PPP Client

    PPP Client

    Step 2

    Step 3

    Step 1

    Step 4

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    16 Chapter 1: Introduction to VPN Technologies

    Layer 2 Tunneling Protocol

    Layer 2 Tunneling Protocol (L2TP)is a collaborative effort to develop a standards-based VPDN

    protocol within IETF. Vendors collaborating on this initiative include, among others, Cisco and

    Microsoft. As with PPTP, L2TP is a client-server operation consisting of two main components:

    L2TP Access Concentrator (LAC)The LAC represents the client side of this network and

    typically exists on the switch infrastructure between remote dialup nodes and the access

    server that terminates the inbound PPP sessions across the switched ISDN or PSTN

    infrastructure. As remote hosts initiate and terminate PPP connections on the NAS, the LAC

    serves as a proxy originator of L2TP control and tunnel data to the LNS at the corporate

    network. LACs are often collocated with the access server itself. A Cisco router or access

    server is capable of providing LAC functionality within a VPDN.

    L2TP Network Server (LNS)The LNS represents the server side of this VPDN

    architecture. It resides within the enterprise network and terminates tunneled data from the

    LAC. As users connect to the LAC, connections are multiplexed across the negotiated tunnel

    to the LNS, where they are eventually terminated.

    A typical L2TP session resembles a compulsory PPTP tunnel negotiation between a PAC and a

    PNS. As with PPTP, two types of data are forwarded into an L2TP tunnelcontrol data and tunnel

    data. Unlike PPTP, however, L2TP is not connection oriented. Instead, it is packet oriented. So,

    whereas PPTP relied on a TCP-based connection to establish a control channel between the

    PAC and PNS, L2TP uses UDP to maintain control data and tunnel data simultaneously. L2TP

    leverages the use of control messages and data packets as follows:

    L2TP control messages negotiate tunnel setup and maintenance. Control messages establishtunnel IDs for new connections within an existing tunnel. They also tear down and remove

    previously established tunnel IDs within an existing L2TP tunnel. L2TP control messages

    are originated on a given source port and forwarded to UDP destination port 1701.

    L2TP payload packets tunnel data within a given network. When data is tunneled from LAC

    to LNS across an IP cloud, it is encapsulated with an L2TP header. The format of the

    L2TP payload is illustrated in Figure 1-11. As with L2TP control messages, L2TP payload

    packets are forwarded to UDP 1701.

    Figure 1-11 L2TP Tunnel Protocol Data Structure

    NOTE L2F control and payload packets are also sent on UDP port 1701. Network devices

    inspect the version field to differentiate between L2F and L2TP packet formats.

    Data Link Header Data Link TrailerIP Header UDP Header PPP Header PPP PayloadL2TP Header

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    VPN Technologies 17

    Figure 1-12 depicts a sample L2TP tunnel setup in which a company uses L2TP to establish

    seamless, secure connectivity across an untrusted media. In this case, that shared network is the

    ISP cloud. The ISP owns the access server that terminates the customers dialup connection

    using PPP as the Layer 2 protocol. In this example, the access server also serves as the LAC.

    The LNS is located on the customer premises and terminates the L2TP tunnel originatedfrom the LAC.

    Figure 1-12 L2TP Tunnel Negotiation

    The following steps outline the creation of the L2TP VPDN from the remote host to the corporate

    network as described in Figure 1-12:

    1. The user dials in to the NAS/LAC over PSTN or ISDN. The user establishes a PPP connection

    with the NAS and is authenticated with CHAP.

    2. The user initiates an L2TP tunnel and is prompted for a username and password. The ISP

    inspects the remote users username and authenticates it against its central authentication

    database via TACACS+ or RADIUS.

    3. Once authenticated, the LAC initiates an L2TP tunnel to the LNS located at their corporate


    4. The LNS receives the request for tunnel negotiation and optionally authenticates the request

    against the corporate central authentication database via TACACS+ or RADIUS. The LNS

    responds with either an acceptance or a rejection of the tunnel initiation to the LAC.

    Cisco Secure ACS, ISP



    Step 4

    Step 3

    Step 5

    Step 6

    Step 1


    Step 2


    PPP Client,Mobile Worker

    PPP Client,Branch Office

    PPP Client,Telecommuter

    PPP Client, SmallHome Office PPP Client,

    Mobile Worker

    Cisco SecureACS, Corporate

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    18 Chapter 1: Introduction to VPN Technologies

    5. The LNS creates a virtual interface for the tunnel ID corresponding to the requesting remote

    PPP client. The remote PPP client and the LNS are now able to exchange authentication,

    authorization, accounting, and IP addressing data with one another over the tunneled PPP

    session. L2TP headers are stripped on ingress at the LNS for inbound connections from thePPP client. Likewise, L2TP headers are stripped at the LAC for outbound connections from

    the LNS to the PPP client.

    6. A PPP connection now exists between the PPP client and the LNS. Additionally, an

    L2TP tunnel has been negotiated between the LAC and the LNS. When a new PPP client

    attempts to access the corporate network and is authenticated at the ISP, the LAC does not

    create a new L2TP tunnel but instead adds a new tunnel ID to the existing tunnel for that


    Multiprotocol Label Switching VPNsMultiprotocol Label Switching (MPLS) VPNslogically separate VPN traffic over a shared

    media through the use of VPN Routing and Forwarding Instances (VRFs). In an MPLS network,

    different devices play different roles to achieve this logical separation:

    Provider (P) Router: P routers typically comprise the MPLS core and therefore provide

    transport between PE routers. Instead of using IP routing information base (RIB) or IP

    forwarding information base (FIB) lookups to make forwarding decisions, P routers use a

    label forwarding information base (LFIB) lookup to make their forwarding decisions.

    Convergence of the LFIB between P routers in the provider network is facilitated through the

    use of Label Distribution Protocol (LDP).

    Provider Edge (PE) Routers: PE routers typically provide the interface between the service

    provider and the customer, and it is most common for the provider to own the PE router.

    PE routers communicate information about VPNv4 addresses, including the IPv4 prefix and

    8-byte route descriptor, between one another using the Multiprotocol Border Gateway

    Protocol (MP-BGP), enabling convergence at the PE.

    Customer Edge (CE) Routers:CE routers provide the interface to the PE routers. CE routers

    typically perform forwarding decisions based on standard RIB or FIB lookups, and

    convergence between CE routers and the PE router can typically be achieved through the use

    a standard IGP.

    NOTE MP-BGP plays a critical role in the convergence of an MPLS VPN. For more

    information on MP-BGP and its role in MPLS VPNs, please refer to the following IETF RFC:

    From the Library of Ah
  • 7/13/2019 IPSEC VPN Fundamentals


    VPN Technologies 19

    A VRF describes a separate routing and forwarding table, enabled by the use of Route Descriptors,which are 8-byte unique identifiers derived from VPN-specific information at the provider edge

    (PE). MPLS VPNs enable customer edge (CE) routers to establish normal Layer 3 RP adjacencies

    with MPLS-aware PE routers. Each PE router is MPLS VPN aware and is able to forward traffic

    to its destination PE router on the opposite side of the provider core using VPNv4 addresses

    learned from MP-BGP advertisements from other PE routers. The provider core routers remain

    unaware of the customer networks routing table or IP addressing information. Instead, traffic is

    switched within the MPLS cloud using labels and an entry in the P routers label forwarding

    information base (LFIB). Figure 1-13 illustrates IP-routed and VRF-routed domains with MPLS.

    Figure 1-13 Traffic is IP-Routed to the Provider Edge (PE)

    When the traffic from the customer edge reaches the PE router, it is then label switched across the

    MPLS Service Provider core to its destination PE router. In this manner, customer routing and

    IP addressing information is kept virtual and private from the provider corethe P routers use

    CAUTION An MPLS VPN does not provide confidentiality unless it is deployed in

    conjunction with IPsec.



    PE Routers use MP-BGPto distribute VPNv4routes to one anotherover the network of Prouters.

    Customer Networks A, B, C,and D use the a single,shared, virtualized coreenabling all networks toparticipate in the VPN #1while only allowingCustomer Networks C and Dparticipate in the VPN #2.













    IP Switched IP Switched

    C CE










    = VPN #1 = VPN #2

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    20 Chapter 1: Introduction to VPN Technologies

    MPLS labels and an associated LFIB entry to forward the traffic across the MPLS core rather than

    IP addressing information.

    When MPLS-switched traffic arrives at the destination PE router, traffic can be forwarded to

    neighboring CE routers based on the previously installed VPNv4 address learned from MP-BGPadvertisements from neighboring MP-BGPenabled PE routers. The CE routers perform IP RIB

    lookups to determine the appropriate destination and forwarding decisions within the customer

    core IP network.

    The operation of MPLS offers separation of multiple virtual data networks across a shared

    network such as an ISP. The addition of MPLS labels at the service provider core allows customers

    to separate networks from other customers virtually over a shared core network such as a service

    provider network. The use of route descriptors on PE nodes provides separation at the control

    plane, allowing customers to use overlapping address space and overlapping services that would

    normally present conflict within a non-MPLS environment. As mentioned previously, data-planeseparation is achieved using VPN labels to make the forwarding decisions on PE routers.

    IPsec VPNs

    IPsec VPNsencrypt data at the Layer 3 IP packet layer, offering a comprehensively secure VPN

    solution through providing data authentication, anti-replay protection, data confidentiality, and

    data integrity protection. As such, IPsec is one of the most widespread VPN technologies in

    todays enterprise, service provider, and government networks. Using ESP in tunnel mode, IPsec

    supports the rewrite of Type of Service (ToS) bits into an outer IP header, thereby supporting

    encrypted data payloads while preserving quality of service (QoS) within a given network. IPsec

    is a standards-based protocol and therefore supports interoperability across products from

    multiple vendors.

    As we will discuss, IPsec is supported within Cisco IOS on a wide array of different routers,

    firewalls, VPN Service Modules, VPN concentrators, and VPN clients. Likewise, Cisco offers avariety of different hardware-based VPN acceleration options for enhanced VPN performance

    within a network. IPsec will serve as the primary VPN discussion point for the duration

    of this book.

    IPsec VPNs tunnel data across shared media using ESP, AH, or a combination of both. These two

    standards-based protocols both use symmetric encryption technology.

    NOTE Although IPsec is standards based, there are many optional components of IPsec (not

    required for RFC compliance) and proprietary innovations that present compatibility

    considerations in multi-vendor environments. We will discuss these design considerations in

    greater detail in Chapter 8, Handling Vendor Interoperability with High Availability.

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    VPN Technologies 21

    IPsec-supported symmetric encryption transforms include data encryption standard (DES,

    56-bit transform), triple data encryption standard (3DES, 168-bit transform), and most recently,advanced encryption standard (AES, 256-bit transform). Security parameters, including keys used

    for symmetric encryption, are communicated securely using the Internet Key Exchange (IKE)

    protocol, which is also considered part of the IPsec protocol suite. The operation of protocols

    incorporated within the IPsec protocol suite is discussed in greater detail in Chapter 2. Subsequent

    chapters will explore design considerations of IPsec-based VPNs.

    Transport Layer VPNs

    Transport layer VPNsprovide an additional layer of security at the transport of the OSI stack.

    Transport layer VPNs typically consist of a client application and a server. A transport layer VPN

    will undergo a handshake to agree on common parameters to use for the SSL or TLS session,

    including cryptographic keying material and transforms. The messages in this handshake are

    confidentially exchanged between client and server, typically with a form of public key encryption

    such as RSA encryption. During the handshake, the client and server also agree on a set of

    symmetric session keys and a symmetric key transform, such as DES or 3DES, for bulk data

    encryption over the SSL VPN.

    Secure Socket Layer VPNs

    In todays network architectures, Secure Socket Layer (SSL)VPNs represent one of the most

    popular choices for transport layer security. SSL was originally developed by Netscape in 1994to secure client/server applications across the Internet. SSL is effective at providing data

    authentication, data integrity, and data confidentiality between client and server applications,

    but it does not offer data non-repudiation services. As discussed before, SSL is performed over

    TCP in the transport layer of the OSI stack, as illustrated in Figure 1-14.

    Figure 1-14 SSL and the OSI Stack

    NOTE The precise operation of ESP and AH are outlined more comprehensively in Chapter 2.

    Secure Socket Layer (SSL)Services

    Layer 4, Transport, TCP

    Layer 3, Network, IP

    Layer 2, Data Link

    Layer 1, Physical

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    22 Chapter 1: Introduction to VPN Technologies

    SSL follows five broad steps when establishing a secure sessionclient exchange of cryptographic

    parameters, server exchange of cryptographic parameters, cryptographic key derivation, session

    authentication, and secure data exchange. Refer to the scenario illustrated in Figure 1-15 for the

    following description of SSL tunnel negotiation. In the SSL tunnel negotiation, public key

    encryption is typically used for initial client and server authentication. The client and server alsoexchange public keys to encrypt each message in the handshake. Once the handshake is

    completed, symmetric key transforms are used for bulk data encryption between client and server.

    Figure 1-15 SSL Tunnel Establishment

    The following order of operations describes the SSL handshake illustrated in Figure 1-15:

    Client Exchange of Cryptographic ParametersCLIENT-HELLO Message:

    Cipher suite (supported symmetric transforms) Version (SSL v2, v3, or v3.1) ClientRandom (for master secret calculation) Optional session ID

    Compression algorithmCLIENT-HELLO-DONE Message

    Server Exchange of Cryptographic ParametersSERVER-HELLO Message:

    Cipher suite (supported symmetric transforms) Version (SSL v2, v3, or v3.1) ServerRandom (for master secret calculation) Optional session ID Compression algorithm


    Cryptographic Key DerivationCLIENT-KEY-EXCHANGE Message:

    Client protocol version Pre-master secret: a 48-byte value

    FINISHED Message

    Hash of all exchanged messages executed in the handshake

    Session AuthenticationFINISHED Message

    Hash of all exchanged messages executed in the handshake including the Client FINISHED message

    Session Authentication

    FINISHED Message Hash of all exchanged messages executed in the

    handshake including the Client FINISHED message





    5 5

    SSL Concentrator

    SSL Concentrator

    SSL Concentrator

    SSL Concentrator

    SSL Concentrator

    SSL Client

    SSL Client

    SSL Client

    SSL Client

    SSL Client

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    VPN Technologies 23

    1. Client Exchange of Cryptographic ParametersThe client and server must agree on the

    parameters used for encryption, such as the encryption algorithm, key exchange method, and

    hash method to use for data integrity. If the client and server have not already agreed on these

    parameters, then the client will initiate the exchange of messages to negotiate mutually

    acceptable parameters to use for future operations using by sending a CLIENT-HELLO

    message to the concentrator.

    2. Server Exchange of Cryptographic ParametersThe server responds to the CLIENT-

    HELLO message with a SERVER-HELLO message and, optionally, several other messages:

    SERVER-CERTIFICATEContains the serverss public key for

    server authentication and pre-master secret encryption.

    SERVER-KEY-EXCHANGEOptionally used to encrypt the

    CLIENT-KEY-EXCHANGE message in Step 3 below.


    server can optionally request a client certificate for authentication. If this

    message is sent to the client, the clients server mustbe forwarded to the

    SSL concentrator and successfully validated.

    The SERVER-HELLO will specify the parameters to use for the SSL session, includingthe highest version ID and the strongest supported symmetric key cipher specified in the

    CLIENT-HELLO message from Step 1. At this point, the client and server should have

    the appropriate information necessary to agree on cryptographic parameters. A SERVER-

    HELLO-DONE message is then forwarded to the SSL client to indicate that the SSL server

    has received the required information for this sequence of the handshake and is awaiting

    information from the client (as described in the next step).

    3. Cryptographic Key DerivationThe client is now ready to generate and share its pre-master

    secret key with the SSL server. The pre-master secret is comprised of a 48-byte value (in the

    case where RSA is used). This value is then encrypted with the SSL servers public key and

    forwarded to the SSL server using a CLIENT-KEY-EXCHANGE message. Optionally, theclient will also forward two additional messages at this point in the SSL handshake:

    CLIENT-CERTIFICATEThe client must possess a certificate and

    forward it to the server using this message if the client receives a


    NOTE RSA signatures are commonly used to facilitate the authentication and confidential

    exchange of messages during the SSL handshake. RSA Signatures, including x.509-based

    certificates and certificate authorities, are discussed in full detail in Chapter 2 and Chapter 12,

    Public Key Infrastructures and IPsec.

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    24 Chapter 1: Introduction to VPN Technologies

    CERTIFICATE-VERIFYThis message is a hash of all previous

    handshake messages appended. It is sent to the SSL server to validate the

    authenticity and data integrity of the CLIENT-CERTIFICATE message

    (and all other previous handshake messages) if the client receives a


    The SSL Server decrypts the CLIENT-KEY-EXCHANGE message to obtain the pre-master

    secret sent by the client. The client and server then derive the master secret by hashing

    the pre-master secret with the ClientRandom and ServerRandom values shared in Step 1. The

    master key is then used to derive 4 session keys that SSL will use to encrypt data:

    Client Write MAC SecretClient uses this key to create a hash

    appended to the original message; server uses this key to verify the hash.

    Server Write MAC SecretServer uses this key to create a hash

    appended to the original message; client uses this key to verify the hash.

    Client Write KeyClient uses this key to encrypt messages; server

    uses it to decrypt messages.

    Server Write KeyServer uses this key to encrypt messages; client

    uses it to decrypt message.

    The client concludes this phase of the SSL handshake by sending a CLIENT-FINISHED

    message to the server. The FINISHED message contains a hashed value of all previous messages

    in the handshake to this point. The server verifies this message to determine that the previous

    exchanges have indeed been authentic with preserved data integrity.

    4. Session AuthenticationThe SSL concentrator or server must validate the hash (MAC)

    sent in the client FINISHED message received in Step 3 above. Upon successful validation of

    the MAC contained in the client FINISHED message, the server now safely assumes that the

    SSL handshake has proceeded with authenticity and preserved data integrity. The server

    subsequently forwards a server FINISHED message to the SSL client containing a MAC

    resulting from a hash of all previous messages in the handshake to this point. Upon receipt

    of this message, the SSL client performs a validation of the MAC received in the server

    FINISHED message so that it too can assume that the handshake has completed with

    authenticity and preserved data integrity.

    5. Confidential Exchange of Data with Preserved IntegrityThe client and server now use

    the session keys derived from the master secret in Step 1 to encrypt and decrypt data sent toand from one another. This is done through an agreed-upon cipher transform such as DES or,

    in this case, 3DES. However, to ensure data integrity, a hashed message authentication

    code (HMAC) is appended to the original message. The newly formed payload (original

    message + HMAC) is encrypted with the selected transform.

    NOTE The creation of hashed message authentication codes is covered in greater detail in

    Chapter 2.

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    Common VPN Deployments 25

    Transport Layer Security and SSL VPNs

    SSL was originally developed by Netscape and has proven to be effective for HTTPS

    communications. However, the IETF standards track protocol for security at the transport layer is

    actually transport layer security (TLS). The operation of TLS is similar to SSL 3.0 but has

    significant modifications, specifically with respect to support for different cryptographicalgorithms, that make the two incompatible with one another.

    TLS has big implications in 802.1x identity-based networking systems, because extensible

    authentication protocol with TLS (EAP-TLS) is part of the 802.1x standard. Additionally, TLS is

    a critical component in wireless network security. Although not formally a component of the

    newly ratified 802.11i IEEE standard for wireless network security, EAP-TLS is the de facto

    means of authentication in 802.11i-compliant networks.

    Common VPN Deployments

    Network infrastructures in which a VPN technology may be commonly deployed include, but

    are not limited to, trunks to Internet service provider networks, corporate extranet partner

    networks, or even private leased line connections in a corporate intranet. Next, we will briefly

    explore some of the common situations in which a VPN may be deployed.

    Site-to-Site VPNs

    As cryptographic technology becomes more embedded in various network elements, growth in

    site-to-site VPN deployments has risen. A site-to-site VPN could be as simple as encrypting the

    link between two different nodes on a point-to-point connection. Or it could be slightly more

    complex, offloading the initiation and termination of the VPN tunnel to a firewall or VPNconcentrator on each organizations DMZ. Figure 1-16 illustrates a simple site-to-site IPsec VPN

    deployment between two networks, A and B.

    Figure 1-16 Simple Site-to-Site Design Scenario

    Although the two IPsec tunnel implementations in Figure 1-16 use the same physical topology to

    accomplish a similar task, there is a significant difference between these two simple site-to-site

    VPN designs. For example, if a smaller router is used for the WAN connection, there could be a

    IPSec tunnel over point-to-point link

    IPSec tunnel over routed links

    Network A Network B

    From the Library of Ah

  • 7/13/2019 IPSEC VPN Fundamentals


    26 Chapter 1: Introduction to VPN Technologies

    substantial improvement in VPN performance by processing IPsec on the VPN concentrators. In

    such a case, the routed IPsec tunnel between the two VPN concentrators would be an optimal

    choice. However, if the PIX are performing network address translation (NAT), the VPN concentrators

    may need support for special features, such as IPsec NAT Transversal (IPsec NAT-T), for IPsec to

    work properly. If the concentrators do not have the appropriate features, the IPsec tunnel built overthe point-to-point line might be a better option.

    In the scenario in Figure 1-16, it is critically important to note that the flexibility to choose between

    the two tunnel deployments is enabled by the fact that IPsec VPNs operate at Layer 3, the

    network layer, of the OSI model. As such, VPNs are no longer limited to bulk data-link encrypt