Date post: | 14-Oct-2015 |
Category: |
Documents |
Upload: | nicolae-neceaev |
View: | 535 times |
Download: | 22 times |
7/13/2019 IPSEC VPN Fundamentals
1/480
From the Library of Ahmed
7/13/2019 IPSEC VPN Fundamentals
2/480
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
3/480
ii
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
4/480
iii
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
5/480
iv
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
6/480
v
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
7/480
vi
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
invaluable.
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
8/480
vii
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 http://www.ciscopress.com/safarienabled
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
http://www.ciscopress.com/safarienabledhttp://www.ciscopress.com/safarienabled7/13/2019 IPSEC VPN Fundamentals
9/480
viii
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
10/480
ix
Contents
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
11/480
x
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
12/480
xi
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
13/480
xii
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
14/480
xiii
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
15/480
xiv
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
16/480
xv
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
17/480
xvi
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
18/480
xvii
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
19/480
xviii
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
20/480
xix
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
21/480
xx
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
22/480
This page intentionally left blank
From the Library of Ah
7/13/2019 IPSEC VPN Fundamentals
23/480
From the Library of Ah
7/13/2019 IPSEC VPN Fundamentals
24/480
Part I: Introductory Concepts and
Configuration/Troubleshooting
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
25/480
From the Library of Ah
7/13/2019 IPSEC VPN Fundamentals
26/480
C H A P T E R 1
Introduction to VPN
Technologies
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
enterprise.
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
27/480
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
28/480
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?
4$h5*&FsW@4^%TY&^i*f
Plain Text
Cipher Text:
James
Charlies Encryption Key
Hey Charlie, what did youlearn at school today?
4$h5*&FsW@4^%TY&^i*f
Plain Text
Cipher Text:
Charlies Decryption KeyCipher:
RSA
Charlie
Cipher:
RSA
Charlie shares his encryptionkey only with James
From the Library of Ah
7/13/2019 IPSEC VPN Fundamentals
29/480
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
Fsd$#^@43#@Ad5J$
Hey Charlie, what did youlearn at school today?
Fsd$#^@43#@Ad5J$
Plain Text
Hash Value:
James
Hey Charlie, what did youlearn at school today?
Fsd$#^@43#@Ad5J$
Plain Text
Hash Value:
Fsd$#^@43#@Ad5J$
Hash Value:
Jamesappendsmessagedigest
tooriginalmessage
Charlie
Hash:MD5
Hash:MD5
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
Fsd$#^@43#@Ad5J$Digital
Signature
DigitalSignature
Hey Charlie, what did youlearn at school today?
James appends messagedigest to original message
DigitalSignature
Fsd$#^@43#@Ad5J$
Hash Value:
Fsd$#^@43#@Ad5J$
Hash:MD5
Cipher:RSA
Hash:MD5
Cipher:RSA
Hey Charlie, what did youlearn at school today?
From the Library of Ah
7/13/2019 IPSEC VPN Fundamentals
30/480
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
Secure HTTP (HTTPS)S/MIME, PGP
N/A
N/A
SSL and TLSSOCKS, SSH
IPSec Deployments,MPLS VPNs
VPDN-PPTP, L2TP, L2FATM Cell Encryptors
Frame-Relay Frame Encryptors
Optical Bulk EncryptorsRadio Frequency (RF)
Encryptors
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
31/480
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
headquarters.
PPP Encapsulation PPP PayloadL2F EncapsulationUDP
From the Library of Ah
7/13/2019 IPSEC VPN Fundamentals
32/480
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
TACACS+).
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).
PSTN/ISDNConnections
Cisco SecureACS, ISP
NAS
Step 4
Step 2
Step 3
Step 5
Step 6Step 1
HomeGateway
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
33/480
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 http://www.ietf.org/rfc/rfc2406.txt.
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
NAS
From the Library of Ah
http://www.ietf.org/rfc/rfc2406.txthttp://www.ietf.org/rfc/rfc2406.txt7/13/2019 IPSEC VPN Fundamentals
34/480
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
EnterpriseNetwork
Step 4
Step 3
Step 2
PSTN/ISDNConnections
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
35/480
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
1723.
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
36/480
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
supported.
NAS/PAC PIX/PNSGatewayRouter
PSTN/ISDNConnections
Service ProviderNetwork
EnterpriseNetwork
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
37/480
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
38/480
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
facility.
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
ServiceProviderNetwork
NAS/LAC
Step 4
Step 3
Step 5
Step 6
Step 1
LNS
Step 2
PSTN/ISDNConnections
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
39/480
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
client.
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:
http://www.ietf.org/rfc/rfc2547.txt
From the Library of Ah
http://www.ietf.org/rfc/rfc2547.txthttp://www.ietf.org/rfc/rfc2547.txt7/13/2019 IPSEC VPN Fundamentals
40/480
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.
CustomerNetwork
B
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.
CustomerNetwork
C
C
C
CE
CE
IPSwitched
CustomerNetwork
D
C
CE
IPSwitched
IP Switched IP Switched
C CE
CustomerNetwork
A
P
P
PE
PE
PE
PE
LabelSwitched
= VPN #1 = VPN #2
From the Library of Ah
7/13/2019 IPSEC VPN Fundamentals
41/480
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
42/480
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
43/480
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
SERVER-HELLO-DONE Message
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
1
2
3
4
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
44/480
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.
CLIENT-CERTIFICATE-REQUEST The SSL concentrator or
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
CLIENT-CERTIFICATE-REQUEST in Step 2 above.
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
45/480
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
CLIENT-CERTIFICATE-REQUEST in Step 2 above.
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
46/480
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
47/480
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