CCSP™: Secure PIX and Secure VPN Study Guide

CCSP™: Secure PIX and Secure VPN Study Guide
CCSP™:
Secure PIX and Secure
VPN Study Guide
Wade Edwards, CCIE #7009
et al
SYBEX®
CCSP:
Secure PIX and Secure VPN
Study Guide
CCSP :
™
Secure PIX and Secure VPN
Study Guide
Wade Edwards, CCIE #7009
Tom Lancaster, CCIE #8829
Eric Quinn
Jason Rohm, CCIE #6861
Bryant Tow
San Francisco • London
Associate Publisher: Neil Edde
Acquisitions Editor: Maureen Adams
Developmental Editor: Jeff Kellum
Production Editor: Erica Yee
Technical Editor: Patrick Bass
Copyeditor: Laura Ryan
Compositor: Happenstance Type-O-Rama
Graphic Illustrator: Jeff Wilson, Happenstance Type-O-Rama
CD Coordinator: Dan Mummert
CD Technician: Kevin Ly
Proofreaders: Emily Hsuan, Laurie O'Connell, Nancy Riddiough
Indexer: Nancy Guenther
Book Designer: Bill Gibson
Cover Designer: Archer Design
Cover Illustrator/Photographer: Andrew Ward/Life File
Copyright © 2004 SYBEX Inc., 1151 Marina Village Parkway, Alameda, CA 94501. World rights reserved. The
author(s) created reusable code in this publication expressly for reuse by readers. Sybex grants readers limited permission to reuse the code found in this publication or its accompanying CD-ROM so long as the author(s) are
attributed in any application containing the reusable code and the code itself is never distributed, posted online
by electronic transmission, sold, or commercially exploited as a stand-alone product. Aside from this specific
exception concerning reusable code, no part of this publication may be stored in a retrieval system, transmitted,
or reproduced in any way, including but not limited to photocopy, photograph, magnetic, or other record, without the prior agreement and written permission of the publisher.
Library of Congress Card Number: 2003109126
ISBN: 0-7821-4287-7
SYBEX and the SYBEX logo are either registered trademarks or trademarks of SYBEX Inc. in the United States
and/or other countries.
The CD interface was created using Macromedia Director, COPYRIGHT 1994, 1997–1999 Macromedia Inc.
For more information on Macromedia and Macromedia Director, visit http://www.macromedia.com.
Internet screen shot(s) using Microsoft Internet Explorer 5.5 reprinted by permission from Microsoft Corporation.
This study guide and/or material is not sponsored by, endorsed by or affiliated with Cisco Systems, Inc. Cisco ®,
Cisco Systems ®, CCDA , CCNA , CCDP , CCSP, CCIP, BSCI, CCNP , CCIE , CCSI , the
Cisco Systems logo and the CCIE logo are trademarks or registered trademarks of Cisco Systems, Inc. in the
United States and certain other countries. All other trademarks are trademarks of their respective owners.
TRADEMARKS: SYBEX has attempted throughout this book to distinguish proprietary trademarks from
descriptive terms by following the capitalization style used by the manufacturer.
The author and publisher have made their best efforts to prepare this book, and the content is based upon final
release software whenever possible. Portions of the manuscript may be based upon pre-release versions supplied
by software manufacturer(s). The author and the publisher make no representation or warranties of any kind
with regard to the completeness or accuracy of the contents herein and accept no liability of any kind including
but not limited to performance, merchantability, fitness for any particular purpose, or any losses or damages of
any kind caused or alleged to be caused directly or indirectly from this book.
Manufactured in the United States of America
10 9 8 7 6 5 4 3 2 1
To Our Valued Readers:
Thank you for looking to Sybex for your Cisco Certified Security Professional exam prep
needs. Cisco developed the CCSP certification to validate expertise in designing and implementing secure Cisco internetworking solutions, and it promises to be one of the most highly
valued IT certifications available.
We at Sybex are proud of the reputation we’ve established for providing certification candidates with the practical knowledge and skills needed to succeed in the highly competitive IT
marketplace. It has always been Sybex’s mission to teach individuals how to utilize technologies in the real world, not to simply feed them answers to test questions. Just as Cisco is committed to establishing measurable standards for certifying those professionals who work in
the cutting-edge field of internetworking, Sybex is committed to providing those professionals
with the means of acquiring the skills and knowledge they need to meet those standards.
The authors, editors, and technical reviewers have worked hard to ensure that this Study
Guide is comprehensive, in-depth, and pedagogically sound. We’re confident that this book,
along with the collection of cutting-edge software study tools included on the CD, will meet
and exceed the demanding standards of the certification marketplace and help you, the CCSP
certification exam candidate, succeed in your endeavors.
Good luck in pursuit of your CCSP certification!
Neil Edde
Associate Publisher—Certification
Sybex, Inc.
Software License Agreement: Terms and Conditions
The media and/or any online materials accompanying
this book that are available now or in the future contain
programs and/or text files (the "Software") to be used in
connection with the book. SYBEX hereby grants to you
a license to use the Software, subject to the terms that
follow. Your purchase, acceptance, or use of the Software will constitute your acceptance of such terms.
The Software compilation is the property of SYBEX
unless otherwise indicated and is protected by copyright
to SYBEX or other copyright owner(s) as indicated in
the media files (the "Owner(s)"). You are hereby
granted a single-user license to use the Software for your
personal, noncommercial use only. You may not reproduce, sell, distribute, publish, circulate, or commercially
exploit the Software, or any portion thereof, without the
written consent of SYBEX and the specific copyright
owner(s) of any component software included on this
media.
In the event that the Software or components include
specific license requirements or end-user agreements,
statements of condition, disclaimers, limitations or warranties ("End-User License"), those End-User Licenses
supersede the terms and conditions herein as to that particular Software component. Your purchase, acceptance, or use of the Software will constitute your
acceptance of such End-User Licenses.
By purchase, use or acceptance of the Software you further agree to comply with all export laws and regulations of the United States as such laws and regulations
may exist from time to time.
Reusable Code in This Book
The author(s) created reusable code in this publication
expressly for reuse by readers. Sybex grants readers limited permission to reuse the code found in this publication, its accompanying CD-ROM or available for
download from our website so long as the author(s) are
attributed in any application containing the reusable
code and the code itself is never distributed, posted
online by electronic transmission, sold, or commercially
exploited as a stand-alone product.
Software Support
Components of the supplemental Software and any
offers associated with them may be supported by the
specific Owner(s) of that material, but they are not supported by SYBEX. Information regarding any available
support may be obtained from the Owner(s) using the
information provided in the appropriate read.me files or
listed elsewhere on the media.
Should the manufacturer(s) or other Owner(s) cease to
offer support or decline to honor any offer, SYBEX
bears no responsibility. This notice concerning support
for the Software is provided for your information only.
SYBEX is not the agent or principal of the Owner(s),
and SYBEX is in no way responsible for providing any
support for the Software, nor is it liable or responsible
for any support provided, or not provided, by the
Owner(s).
Warranty
SYBEX warrants the enclosed media to be free of physical defects for a period of ninety (90) days after purchase. The Software is not available from SYBEX in any
other form or media than that enclosed herein or posted
to www.sybex.com. If you discover a defect in the
media during this warranty period, you may obtain a
replacement of identical format at no charge by sending
the defective media, postage prepaid, with proof of purchase to:
SYBEX Inc.
Product Support Department
1151 Marina Village Parkway
Alameda, CA 94501
Web: http://www.sybex.com
After the 90-day period, you can obtain replacement
media of identical format by sending us the defective
disk, proof of purchase, and a check or money order for
$10, payable to SYBEX.
Disclaimer
SYBEX makes no warranty or representation, either
expressed or implied, with respect to the Software or its
contents, quality, performance, merchantability, or fitness for a particular purpose. In no event will SYBEX,
its distributors, or dealers be liable to you or any other
party for direct, indirect, special, incidental, consequential, or other damages arising out of the use of or inability to use the Software or its contents even if advised of
the possibility of such damage. In the event that the Software includes an online update feature, SYBEX further
disclaims any obligation to provide this feature for any
specific duration other than the initial posting.
The exclusion of implied warranties is not permitted by
some states. Therefore, the above exclusion may not
apply to you. This warranty provides you with specific
legal rights; there may be other rights that you may have
that vary from state to state. The pricing of the book
with the Software by SYBEX reflects the allocation of
risk and limitations on liability contained in this agreement of Terms and Conditions.
Shareware Distribution
This Software may contain various programs that are
distributed as shareware. Copyright laws apply to both
shareware and ordinary commercial software, and the
copyright Owner(s) retains all rights. If you try a shareware program and continue using it, you are expected to
register it. Individual programs differ on details of trial
periods, registration, and payment. Please observe the
requirements stated in appropriate files.
Copy Protection
The Software in whole or in part may or may not be
copy-protected or encrypted. However, in all cases,
reselling or redistributing these files without authorization is expressly forbidden except as specifically provided for by the Owner(s) therein.
Acknowledgments
We would like to thank Jeff Kellum and Maureen Adams for helping us launch this book
and not only making it a great Study Guide but a great tool—one we are very proud of and
excited about! In addition, we’d like to thank the editorial and production team, including
Production Editor Erica Yee, Copyeditor Laura Ryan, Technical Editor Patrick Bass, Compositors
Maureen Forys and Jeffrey Wilson, and CD Technicians Kevin Ly and Dan Mummert.
Contents at a Glance
Introduction
xvii
Assessment Test
xxxiv
Part I
Cisco Secure PIX Firewall Advanced
1
Chapter 1
PIX Firewall Basics
3
Chapter 2
PIX Firewall Configuration
Chapter 3
ACLs, Filtering, Object Grouping, and AAA
103
Chapter 4
Advanced Protocol Handling, Attack Guards,
and Intrusion Detection
147
Chapter 5
Firewall Failover and PDM
189
Chapter 6
VPNs and the PIX Firewall
227
Part II
Cisco Secure Virtual Private Networks
Chapter 7
Introduction to Virtual Private Networks
297
Chapter 8
Introduction to Cisco VPN Devices
329
Chapter 9
Configuring the VPN Concentrator
383
Chapter 10
Managing the VPN Concentrator
453
43
295
Glossary
487
Index
499
Contents
Introduction
xxi
Assessment Test
Part I
Chapter
1
xxxiv
Cisco Secure PIX Firewall Advanced
1
PIX Firewall Basics
3
Understanding a Firewall’s Role in Network Security
What Is a Firewall?
What Are the Potential Threats?
Reviewing Firewall Technologies
Dual-Homed Gateways
Packet-Filtering Firewalls
Stateful Firewalls
Firewall Technology Combinations
Hardware and Software Components of the Cisco Secure
PIX Firewall
PIX Firewall Features
PIX Firewall Components
PIX Firewall Operation
NAT Mechanisms
Packet Processing
The Adaptive Security Algorithm (ASA) and Security Levels
Working with the Firewall Services Module (FWSM)
Overview of Configuration
Configuring an IOS Switch
Configuring a CatOS switch
Connecting to the Module
Configuring the FWSM
Using the PIX Firewall CLI
CLI Access Methods
CLI Modes
Editing in the CLI
Basic Commands
Summary
Exam Essentials
Key Terms
Review Questions
Answers to Review Questions
4
4
6
6
6
7
8
9
12
12
13
18
19
20
21
22
23
24
25
26
27
28
28
28
30
30
37
37
38
39
41
xii
Contents
Chapter
2
PIX Firewall Configuration
43
Preparing for Firewall Configuration
44
Using Common Global Configuration Commands
45
The Remote Access Commands
45
47
The clock Command
48
The ntp Command
49
The domain-name and hostname Commands
50
The name/names Commands
50
The dhcpd Command
52
The logging Command
Configuring PIX Firewall Interfaces
53
Naming an Interface and Assigning a Security Level
53
Setting Interface Properties and Shutting Down the Interface 56
Assigning an IP Address
57
Setting the Maximum Transfer Unit
58
Configuring NAT and PAT
59
Understanding Address Translation
59
NAT, PAT, and Security
63
Configuring NAT
64
Configuring PAT
73
Configuring NAT on Multiple Interfaces
77
Configuring Routing
85
Configuring Dynamic Routing
86
Configuring Static Routing
87
Configuring Multicast Routing
90
Summary
92
Exam Essentials
92
Key Terms
93
Hands-On Lab
93
Answer to Lab 2.1
96
Answer to Lab 2.2
96
Answer to Lab 2.3
96
Answer to Lab 2.4
97
Answer to Lab 2.5
97
Answer to Lab 2.6
97
Review Questions
99
Answers to Review Questions
101
Chapter
3
ACLs, Filtering, Object Grouping, and AAA
Using PIX Firewall ACLs
Creating a PIX ACL
Applying a PIX ACL
Converting Conduits to ACLs
103
104
105
106
106
Contents
URL Filtering
How Does URL Filtering Work?
Configuring the PIX Firewall for URL Filtering
PPPoE and the PIX Firewall
Configuring the PPPoE Client Username and Password
Enabling PPPoE on the PIX Firewall
Verifying PPPoE Operation
Object Groups
Configuring Object Groups
Using Object Groups
Authentication, Authorization, and Accounting (AAA) Services
Installing CiscoSecure ACS for Windows 2000/NT
Implementing AAA on the PIX Firewall
Downloadable PIX ACLs
Summary
Exam Essentials
Key Terms
Written Lab
Hands-On Lab
Answer to Lab 3.1
Answer to Lab 3.2
Answer to Lab 3.3
Answer to Lab 3.4
Answer to Lab 3.5
Answer to Lab 3.6
Review Questions
Answers to Written Lab
Answers to Review Questions
Chapter
4
Advanced Protocol Handling, Attack Guards, and
Intrusion Detection
Advanced Protocol Handling
Special Protocol Support Basics
File Transfer Protocol
Remote Shell
SQL*Net
Multimedia Support
Alternative Solutions to Problem Protocols
Attack Guards
AAA Flood Guard
SYN Flood Guard
Mail Guard
IP Fragmentation Guard
DNS Guard
xiii
108
108
108
111
111
112
113
115
115
119
119
120
125
132
134
134
135
135
136
138
139
139
140
140
140
142
144
145
147
148
149
151
154
154
156
158
159
159
160
161
165
168
xiv
Contents
Intrusion Detection
IP Audit
Shunning
Summary
Exam Essentials
Key Terms
Written Lab
Hands-On Lab
Answer to Lab 4.1
Answer to Lab 4.2
Answer to Lab 4.3
Answer to Lab 4.4
Answer to Lab 4.5
Review Questions
Answers to the Written Lab
Answers to Review Questions
Chapter
5
Firewall Failover and PDM
Fault-Tolerance Concepts
Points of Failure
Fault-Tolerant Strategies
PIX Firewall Failover
PIX Firewall Failover Features
PIX Firewall Failover Requirements
How PIX Firewall Failover Works
Stateful Failover
Basic Failover Configuration
Cisco PIX Device Manager (PDM)
PDM Overview
Operating Requirements
Preparing for PDM
Using PDM to Configure the PIX Firewall
Summary
Exam Essentials
Key Terms
Written Lab
Review Questions
Answers to Written Lab
Answers to Review Questions
Chapter
6
VPNs and the PIX Firewall
Preparing to Configure VPN support
Configuring IKE on a Firewall
Enabling IKE
169
169
175
176
176
177
177
178
180
180
181
181
181
184
186
187
189
190
190
194
195
195
195
196
203
204
208
208
209
210
212
220
221
221
222
223
225
226
227
228
229
229
Contents
Configuring the IKE Policy
Configuring Preshared Keys
Configuring the Use of Certificate Authorities (CAs)
on a Firewall
Configuring IPSec on a Firewall
Creating Crypto ACLs
Creating and Configuring Transform Sets
Setting the Tunnel Lifetime
Creating Crypto Maps
Verifying and Troubleshooting IPSec Configuration on a Firewall
Viewing Configuration Information
Understanding Error Messages
Debugging
Understanding Remote Access VPN
Extended Authentication (Xauth)
IKE Mode Config for Dynamic Addressing
Pushing Additional Attributes to the VPN Client
Common Commands
Installing and Configuring the Cisco VPN Client
Deploying the VPN Client
Using PDM to Create VPNs
Setting Up a Site-to-Site VPN
Setting Up a Remote Access VPN
Enterprise PIX Firewall Management and Maintenance
Cisco Secure Policy Manager (CSPM)
PIX Management Center (MC)
Auto Update Server (AUS)
Summary
Exam Essentials
Key Terms
Written Lab
Hands-On Lab
Answer to Lab 6.1
Answer to Lab 6.2
Answer to Lab 6.3
Answer to Lab 6.4
Answer to Lab 6.5
Answer to Lab 6.6
Review Questions
Answers to the Written Lab
Answers to Review Questions
xv
230
231
232
237
237
238
240
241
244
244
247
248
248
248
249
250
251
253
255
261
263
268
273
273
275
277
281
281
282
282
283
286
286
286
287
287
288
291
293
294
xvi
Contents
Part II
Chapter
Cisco Secure Virtual Private Networks
7
Introduction to Virtual Private Networks
VPN Basics
Major Types of VPNs
VPN Devices
Introducing IPSec
IPSec Services
IPSec Building Blocks: AH and ESP
Hashing
Encryption
Diffie-Hellman Key Exchange
Internet Key Exchange
Transform Sets
IPSec Security Associations
How IPSec Works
Defining Interesting Traffic
IKE Phase 1
IKE Phase 2
IPSec Task Flow
IPSec Troubleshooting
Traffic Delay Problems
Filtering Problems
NAT Problems
ACL Problems
Summary
Exam Essentials
Key Terms
Review Questions
Answers to Review Questions
Chapter
8
Introduction to Cisco VPN Devices
Introducing the VPN 3000 Concentrators
Overview of the VPN 3005 Concentrator
Overview of VPN 3015 through 3080 Concentrators
VPN Concentrator Client Support
Introducing the 3002 VPN Hardware Client
Configuring the 3002 CLI Quick Configuration Utility
Configuring the Hardware Client with the Quick
Configuration Utility
Managing the Hardware Client
Additional VPN 3002 Client Features
295
297
298
298
299
302
303
303
307
309
309
311
313
315
317
317
318
320
320
322
322
322
323
323
323
323
324
325
328
329
330
331
333
335
336
337
341
349
349
Contents
Introducing the VPN Software Clients
Configuring the Connection
Setting Authentication Properties
Setting Connection Properties
Installing a Certificate
Preconfiguring the VPN Client
Overview of the Cisco VPN Software Client Auto-Initiation
Summary
Exam Essentials
Key Terms
Written Lab
Answers to the Written Lab
Hands-On Lab
Answer to Lab 8.1
Answer for Lab 8.2
Answer for Lab 8.3
Answer for Lab 8.4
Answer for Lab 8.5
Answer for Lab 8.6
Answer for Lab 8.7
Answer for Lab 8.8
Review Questions
Answers to Review Questions
Chapter
9
Configuring the VPN Concentrator
Using the CLI for Initial Configuration
Starting the CLI
Using Web Quick Configuration Mode
Configuring Physical Interfaces
Setting System Information
Setting the Tunnel-Creation Method
Setting Address Assignment
Configuring Authentication
Setting a Group Name
Changing the Admin Password
Configuring User and Policy Management
Navigating the GUI
Setting Up Groups
Setting Up Users
Configuring an Authentication Server
Configuring Access Hours and Filters
Configuring Backup on the Hardware Client
xvii
356
357
357
358
359
362
365
367
367
368
368
370
371
373
374
375
376
377
378
378
378
380
382
383
386
386
393
395
395
396
396
397
399
399
399
400
401
409
409
410
413
xviii
Contents
Configuring Load Balancing
Configuring LAN-to-LAN IPSec
Updating Clients Automatically
Setting Up the Stateful Firewall
Configuring the Use of IPSec Digital Certificates
Introducing the Public Key Infrastructure
Requesting and Installing Concentrator Certificates
Requesting and Installing Client Certificates
Firewall Feature Set for the IPSec Software Client
Software Client’s “Are You There” Feature
Software Client’s Stateful Firewall Feature
Software Client’s Central Policy Protection Feature
Client Firewall Statistics
Customizing Firewall Policy
Configure the VPN 3000 Concentrator for IPSec over UDP
and IPSec over TCP
Overview of Port Address Translation
Configuring IPSec over UDP
Configuring NAT-Transversal
Configuring IPSec over TCP
Summary
Exam Essentials
Key Terms
Written Lab
Hands-On Lab
Answer to Lab 9.1
Answer to Lab 9.2
Review Questions
Answers to Review Questions
Answers to the Written Lab
Chapter
10
Managing the VPN Concentrator
Monitoring the VPN Concentrator
Viewing Concentrator Monitoring Information
Configuring Logging and SNMP Traps
Administering the VPN Concentrator
Configuring Access Rights
Administering Sessions
Administering File Management
Updating Software
Pinging Devices
Summary
414
416
418
421
424
424
425
433
436
436
436
437
437
439
439
440
441
442
443
443
444
445
445
446
447
448
449
451
452
453
454
455
465
471
471
475
476
478
479
480
Contents
Exam Essentials
Key Terms
Written Lab
Review Questions
Answers to the Written Lab
Answers to Review Questions
Glossary
Index
xix
480
481
481
482
484
485
487
499
Introduction
This Study Guide is an introduction to the Cisco security certification. It will help improve
your Cisco security skills so you can have more opportunities for a better job or job security.
Security experience has been a hot job skill and it will continue to be because networks need
security. Cisco has been pushing further into the security market, and having a Cisco security
certification will further expand your opportunities. Let this Study Guide not only be your
resource for the Advanced PIX and VPN tests but an aid when you are gaining hands-on
experience in the field.
Not only will this Study Guide help with your pursuit of Cisco security certifications, but
it will improve your understanding of everything related to security internetworking, which
is relevant to much more than Cisco products. You’ll have a solid knowledge of network
security and how different technologies work together to form a secure network. Even if
you don’t plan on becoming a security professional, the concepts covered in this Study
Guide are beneficial to every networking professional. Having a Cisco security certification
is in such high demand, even at companies with only a few Cisco devices. Since you have
decided to become Cisco security–certified, this Study Guide will put you way ahead on the
path to that goal.
The new Cisco security certifications reach beyond the popular certifications such as the
CCNA/CCDA and CCNP/CCDP to provide you with a greater understanding of today’s secure
network with insight into the Cisco secure world of internetworking.
Some people don’t understand why networks are always vulnerable to security breaches and
why the operating systems just can’t provide protection for these systems without relying on the
network to provide security. The answer is because users demand features in their software to
share files and printers, not only at the office but also from their Internet connection at home.
These features are placed in the software with little thought for security concerns.
You might be thinking, “Why is it that networks are so vulnerable to security breaches anyway? Why can’t the operating systems provide protection?” The answer is pretty straightforward: Users want lots of features, and software vendors give the users what they want because
features sell. Capabilities such as sharing files and printers and logging in to the corporate infrastructure from the Internet are not just desired, they’re expected. The new corporate battle cry
is, “Hey, give us complete corporate access from the Internet and make it super fast and easy—
but make sure it’s really secure!”
So, are software developers to blame? There are just too many security issues for any one
company to be at fault. But it is true that providing all the features that any user could possibly
want on a network at the click of a mouse certainly creates some major security issues. It’s also
true that we certainly didn’t have the types of hackers we have today until we accidentally
opened the door for them. To become truly capable of defending yourself, you must understand
the vulnerabilities of a plethora of technologies and networking equipment.
So, our goal is twofold: First, we’re going to give you the information you need to understand all those vulnerabilities, and second, we’re going to show you how to create a single,
xxii
Introduction
network-wide security policy. Before we do so, there are two key questions behind most
security issues on the Internet:
How do you protect confidential information but still allow access by the corporate users
that need to get to that information?
How do you protect your network and its resources from unknown or unwanted users outside your network?
If you’re going to protect something, you have to know where it is, right? Where important/
confidential information is stored is key for any network administrator concerned with security.
You’ll find the goods in two places: physical storage media (such as hard drives and RAM) and
in transit across a network in the form of packets. This book’s focus is mainly on the network
security issues relative to the transit of confidential information across a network. But it’s important to remember that both physical media and packets need to be protected from intruders within
your network and outside it. TCP/IP is used in all the examples in this book because it’s the most
popular protocol suite these days and also because it has some inherent security weaknesses.
From there, you’ll look beyond TCP/IP and understand how both operating systems and network
equipment come with their own vulnerabilities to address as well. If you don’t have passwords and
authentication properly set on your network equipment, you’re in obvious trouble. If you don’t
understand your routing protocols and especially how they advertise throughout your network, you
might as well leave the building unlocked at night. Furthermore, how much do you know about your
firewall? Do you have one? If so, where are its weak spots? If you don’t cover all these bases, your
equipment will be your network’s Achilles heel.
What Is Good Security?
So now you have a good idea of what you’re up against to provide security for your network.
To stay competitive in this game, you need to have a sound security policy that is both monitored and used regularly. Good intentions won’t stop the bad guys from getting you. Planning
and foresight will save your neck. All possible problems need to be considered, written down,
discussed, and addressed with a solid action plan.
You also need to communicate your plan clearly and concisely to management, providing
solid policy so that they can make informed decisions. With knowledge and careful planning,
you can balance security requirements with user-friendly access and approach. And you can
accomplish all of it at an acceptable level of operational cost. As with many truly valuable
things, however, this is not going to be easy to attain.
First-class security solutions should allow network managers to offer improved services to
their corporate clients, both internally and externally, and save the company a nice chunk of
change at the same time. If you can do this, odds are good that you’ll end up with a nice chunk
of change too. Everybody but the bad guys gets to win!
Cisco Security Certifications
xxiii
If you can understand security well, and if you figure out how to effectively provide network
services without spending the entire IT budget, you’ll enjoy a long, lustrous, and lucrative career
in the IT world. You must be able to
Enable new networked applications and services.
Reduce the costs of implementation and operations of the network.
Make the Internet a global, low-cost access medium.
It’s also good to remember that people who make really difficult, complicated things simpler
and more manageable tend to be honored, respected, and generally very popular—in other words,
in demand and employed. One way to simplify the complex is to break a large, multifaceted thing
down into nice, manageable chunks. To do this, you need to classify each network into one of the
three types of network security classifications: trusted networks, untrusted networks, and
unknown networks. You should know a little bit about these before you begin this book.
Trusted networks Trusted networks are the networks you want to protect, and they populate
the zone known as the security perimeter. The security perimeter is connected to a firewall
server through network adapter cards. Virtual private networks (VPNs) are also considered
trusted networks, only they send data across untrusted networks. So they’re special: They create
special circumstances and require special considerations in establishing a security policy for
them. The packets transmitted on a VPN are established on a trusted network, so the firewall
server needs to authenticate the origin of those packets, check for data integrity, and provide for
any other security needs of the corporation.
Untrusted networks Untrusted networks are those found outside the security perimeters and
not controlled by you or your administrators, such as the Internet and the corporate ISP. These are
the networks you are trying to protect yourself from while still allowing access to and from them.
Unknown networks Because you can’t categorize something you don’t know, unknown networks are described as neither trusted or untrusted. This type of mystery network doesn’t tell
the firewall if it’s an inside (trusted) network or outside (untrusted) network.
Cisco Security Certifications
There are quite a few new Cisco security certifications to be had, but the good news is that this
book, which covers the CSPFA and CSVPN exams, is the prerequisite for all Cisco security certifications. All these new Cisco security certifications also require a valid CCNA.
xxiv
Introduction
Cisco Certified Security Professional (CCSP)
You have to pass five exams to get your CCSP. The pivotal one is the SECUR exam. Here they
are, the exams you must pass to call that CCSP yours:
Securing Cisco IOS Networks (642-501 SECUR). The CCSP: Securing Cisco IOS Networks Study Guide (Sybex, 2003) will help you pass this exam.
Cisco Secure PIX Firewall Advanced (642-521 CSPFA). The book you have in your hands
will help you pass this exam.
Cisco Secure Virtual Networks (642-511 CSVPN). The book you have in your hands will
help you pass this exam.
Cisco Secure Intrusion Detection System (643-521 CSIDS) (at the time this was written, this
exam was still in beta). The CCSP: Secure Intrusion Detection and SAFE Implementation
Study Guide (Sybex, 2004) will help you pass this exam.
Cisco SAFE Implementation (642-541 CSI). The CCSP: Secure Intrusion Detection and
SAFE Implementation Study Guide (Sybex, 2004) will help you pass this exam.
In addition, Cisco offers a number of Security specialization tracks, including
Cisco Firewall Specialist Cisco security certifications focus on the growing need for knowledgeable network professionals who can implement complete security solutions. Cisco Firewall Specialists focus on securing network access using Cisco IOS Software and Cisco PIX Firewall technologies.
The two exams you must pass to achieve the Cisco Firewall Specialist certification are Securing Cisco
IOS Networks (642-501 SECUR) and Cisco Secure PIX Firewall Advanced (642-521 CSPFA).
Cisco VPN Specialist Cisco VPN Specialists can configure VPNs across shared public networks using Cisco IOS Software and Cisco VPN 3000 Series Concentrator technologies.
The two exams you must pass to achieve the Cisco VPN Specialist certification are Securing
Cisco IOS Networks (642-501 SECUR) and Cisco Secure Virtual Networks (642-511 CSVPN).
Cisco IDS Specialist Cisco IDS Specialists can both operate and monitor Cisco IOS software
and IDS technologies to detect and respond to intrusion activities.
The two exams you must pass to achieve the Cisco IDS Specialist certification are Securing
Cisco IOS Networks (642-501 SECUR) and either Cisco Secure Intrusion Detection System
(9E0-100 CSIDS), which was scheduled to retire November 1, 2003, or CSIDS (643-531),
which was in beta when this was written.
For more information about the Cisco Certified Security Professional exams
and Sybex’s Study Guides on these exams, go to www.sybex.com.
Cisco Network Support Certifications
xxv
Cisco Network Support Certifications
Initially, to secure the coveted Cisco Certified Internetwork Expert (CCIE), you took only one
test, and then you were faced with a nearly impossible lab—an all-or-nothing approach that
made it really tough to succeed. In response, Cisco created a series of new certifications to help
you acquire the coveted CCIE and aid prospective employers in measuring skill levels. With
these new certifications, which definitely improved the ability of mere mortals to prepare for
that almighty lab, Cisco opened doors that few were allowed through before. So, what are these
stepping-stone certifications, and how do they help you get your CCIE?
Cisco Certified Network Associate (CCNA)
The CCNA certification was the first in the new line of Cisco certifications and was the precursor to all current Cisco certifications. With the new certification programs, Cisco has created a
stepping-stone approach to CCIE certification.
And you don’t have to stop there. You can choose to continue your studies and achieve a
higher certification called the Cisco Certified Network Professional (CCNP). Someone with a
CCNP has all the skills and knowledge they need to attempt the CCIE lab. However, because
no textbook can take the place of practical experience, we’ll discuss what else you need to be
ready for the CCIE lab shortly.
How Do You Become a CCNA?
The first step to becoming a CCNA is, depending on what path you take, to pass one or two
exams: either Interconnecting Networking Devices (640-811 ICND) and the INTRO (641-821
INTRO), which is currently in beta, or the CCNA (640-801).
Both paths test on the same topics. The only difference is that the CCNA exam is
one 90-minute exam, while ICND and INTRO are 60 and 90 minutes, respectively.
We can’t stress this enough: It’s critical that you have some hands-on experience with Cisco
routers to prepare for you CCNA certification (as well as your other Cisco certifications). If you
can get a hold of some Cisco 2500 or 2600 series routers, you’re set. Also, you should pick up
the best-selling CCNA: Cisco Certified Network Associate Study Guide, 4th ed. (Sybex, 2003),
which covers all the exam objectives. In addition, the CCNA: Cisco Certified Network Associate Study Guide, Deluxe Edition (Sybex 2003) also contains the CCNA: Virtual Lab Gold Edition, a comprehensive router simulator.
Information about Sybex’s CCNA: Cisco Certified Network Associate Study
Guide can be found at www.sybex.com.
xxvi
Introduction
Cisco Certified Network Professional (CCNP)
So you’re thinking, “Great, what do I do after passing the CCNA exam?” Well, if you want to
become a CCIE in Routing and Switching (the most popular certification), understand that there’s
more than one path to that much-coveted CCIE certification. One way is to continue studying and
become a CCNP, which means four more tests, in addition to the CCNA certification.
The CCNP program will prepare you to understand and comprehensively tackle the internetworking issues of today and beyond—and it is not limited to the Cisco world. You will
undergo an immense metamorphosis, vastly increasing your knowledge and skills through the
process of obtaining these certifications.
While you don’t need to be a CCNP or even a CCNA to take the CCIE lab, it’s extremely
helpful if you already have these certifications.
How Do You Become a CCNP?
After becoming a CCNA, the four exams you must take to get your CCNP are as follows:
Exam 642-801: Building Scalable Cisco Internetworks (BSCI) This exam continues to build
on the fundamentals learned in the CCNA course. It focuses on large multiprotocol internetworks and how to manage them with access lists, queuing, tunneling, route distribution, route
maps, BGP, EIGRP, OSPF, and route summarization. The CCNP: Building Scalable Cisco
Internetworks Study Guide (Sybex, 2003) covers all the objectives you need to understand to
pass the BSCI exam.
Exam 642-811: Building Cisco Multilayer Switched Networks (BCMSN) This exam tests
your knowledge of creating and deploying a global intranet and implementing basic troubleshooting techniques in environments that use Cisco multilayer switches for client hosts and services. The CCNP: Building Cisco Multilayer Switched Networks Study Guide (Sybex, 2003)
covers all the objectives you need to understand to pass the current BCMSN exam.
Exam 642-621: Building Cisco Remote Access Networks (BCRAN) This exam determines if
you can describe, configure, operate, and troubleshoot WAN and remote access solutions. The
CCNP: Building Cisco Remote Access Networks Study Guide (Sybex, 2003) covers all the
exam objectives.
Exam 642-831: Cisco Internetwork Troubleshooting (CIT) This exam tests you extensively
on troubleshooting suboptimal performance in a converged network environment. The CCNP:
Cisco Internetwork Troubleshooting Study Guide (Sybex, 2003) covers all the objectives you
need to understand to pass the CIT exam.
www.routersim.com has a complete Cisco router simulator for all CCNP exams.
Cisco Network Support Certifications
xxvii
And if you hate tests, you can take fewer of them by taking the BCRAN and CIT exams, and
then taking just one more long exam called the Composite exam (642-891). Doing this also
gives you your CCNP, but beware: It’s a really long test that fuses all the material from the BSCI
and BCMSN exams into one exam.
Remember that test objectives and tests can change anytime without notice.
Always check the Cisco Web site for the most up-to-date information
(www.cisco.com).
Cisco Certified Internetwork Expert (CCIE)
Cool! You’ve become a CCNP, and now your sights are fixed on getting your CCIE. What do
you do next? Cisco recommends a minimum of two years of on-the-job experience before taking
the CCIE lab. After jumping those hurdles, you then have to pass the written CCIE Exam Qualification before taking the actual lab.
There are actually four CCIE certifications, and you must pass a written exam for each one
of them before attempting the hands-on lab:
CCIE Routing and Switching The CCIE Routing and Switching exam covers IP and IP routing, non-IP desktop protocols such as IPX, and bridge- and switch-related technologies. The
CCIE: Cisco Certified Internetwork Expert Study Guide, 2nd ed. (Sybex, 2003) is a superb
Study Guide that covers both the qualification and lab portions of this track.
CCIE Security
components.
The CCIE Security exam covers IP and IP routing as well as specific security
CCIE Service Provider The CCIE Service Provider (formerly called Communications and Services) exam covers topics related to networking in service provider environments.
CCIE Voice The CCIE Voice exam covers those technologies and applications that make up
a Cisco Enterprise VoIP solution.
How Do You Become a CCIE?
To become a CCIE, Cisco recommends you do the following:
1.
Attend a CCIE hands-on training lab program from a Cisco training partner.
2.
Pass the VUE/Prometric exam. This costs $300 per exam. See the upcoming “Where Do
You Take the Exams?” section for more information.
3.
Pass the one-day, hands-on lab at Cisco. This costs $1,250 per lab, and many people fail
it two or more times. Some people never make it through—it’s very difficult. Cisco has both
added and deleted sites lately for the CCIE lab, so it’s best to check the Cisco Web site for
the most current information. Take into consideration that you might also need to add
travel costs to that $1,250.
xxviii
Introduction
Cisco Network Design Certifications
In addition to the network support certifications, Cisco has created another certification track
for network designers. The two certifications within this track are the Cisco Certified Design
Associate and Cisco Certified Design Professional. If you’re reaching for the CCIE stars, we
highly recommend the CCNP and CCDP certifications before attempting the lab (or attempting
to advance your career).
This certification will give you the knowledge you need to design routed LAN, routed WAN,
and switched LAN and ATM LANE networks.
Cisco Certified Design Associate (CCDA)
To become a CCDA, you must pass the Designing for Cisco Internetwork Solutions exam (640861 DESGN). To pass this test, you must understand how to do the following:
Identify the customer’s business needs and their internetworking requirements.
Assess the customer’s existing network and identify the potential issues.
Design the network solution that suits the customer’s needs.
Explain the network design to the customer and network engineers.
Plan the implementation of the network design.
Verify the implementation of the network design.
The CCDA: Cisco Certified Design Associate Study Guide, 2nd ed. (Sybex, 2003)
is the most cost-effective way to study for and pass your CCDA exam.
Cisco Certified Design Professional (CCDP)
If you’re already a CCNP and want to get your CCDP, you can simply take the Designing Cisco
Network Service Architectures exam (642-871 ARCH). If you’re not yet a CCNP, you must
take the CCDA, CCNA, BSCI, BCMSN, and ARCH exams.
CCDP certification skills include the following:
Designing complex routed LAN, routed WAN, and switched LAN and ATM LANE networks
Building on the base level of the CCDA technical knowledge
CCDPs must also demonstrate proficiency in the following:
Network-layer addressing in a hierarchical environment
Traffic management with access lists
How to Use This Book
xxix
Hierarchical network design
VLAN use and propagation
Performance considerations: required hardware and software; switching engines; memory,
cost, and minimization
How to Use This Book
If you want a solid foundation for the serious effort of preparing for the Cisco Secure PIX Firewall Advanced (CSPFA) and Cisco Secure VPN (CSVPN) exams, then look no further. We’ve
put this book together in a way that will thoroughly equip you with everything you need to pass
the CSPFA and CSVPN exams as well as teach you how to completely configure security on
many Cisco platforms.
This book is loaded with lots of valuable information. You’ll really maximize your studying
time if you tackle it like this:
1.
Take the assessment test immediately following this introduction. (The answers are at the
end of the test, so no cheating.) It’s okay if you don’t know any of the answers—that’s why
you bought this book! But you do need to carefully read over the explanations for any question you get wrong and make note of which chapters the material is covered in. This will
help you plan your study strategy. Again, don’t be disheartened if you don’t know any
answers—just think instead of how much you’re about to learn!
2.
Study each chapter carefully, making sure that you fully understand the information and
the test objectives listed at the beginning of each chapter. And really zero in on any chapter
or part of a chapter that deals with areas where you missed questions in the assessment test.
3.
Take the time to complete the written lab at the end of the chapter. Do not skip this! It
directly relates to the CSPFA and CSVPN exams and the relevant stuff you’ve got to glean
from the chapter you just read. So no skimming! Make sure you really, really understand
the reason for each answer.
4.
Answer all the review questions related to that chapter. (The answers appear at the end of
the chapter.) While you’re going through the questions, jot down any questions that trouble
you and study those sections of the book again. Don’t throw away your notes; go over the
questions that were difficult for you again before you take the exam. Seriously: Do not just
skim these questions! Make sure you completely understand the reason for each answer
because the questions were written strategically to help you master the material that you
must know before taking the CSPFA and CSVPN exams.
5.
Complete all the hands-on labs, referring to the relevant chapter material so that you understand the reason for each step you take. If you don’t happen to have a bunch of Cisco equipment lying around to practice on, be sure to study the examples extra carefully.
xxx
Introduction
6.
Try your hand at the bonus exams that are included on the CD provided with this book.
These questions appear only on the CD, and testing yourself will give you a clear overview
of what you can expect to see on the real thing.
7.
Answer all the flashcard questions on the CD. The flashcard program will help you prepare
completely for the CSPFA and CSVPN exams.
The electronic flashcards can be used on your Windows computer, Pocket PC,
or Palm device.
8.
Make sure you read the Exam Essentials, Key Terms, and Labs at the end of the chapters
and are intimately familiar with the information in those three sections.
Try to set aside the same time everyday to study, and select a comfortable, quiet place to do
so. Pick a distraction-free time and place where you can be sharp and focused. If you work hard,
you’ll get it all down, probably faster than you think.
This book covers everything you need to know to pass the CSPFA and CSVPN exams. Even
so, taking the time to study and practice with routers, a PIX Firewall, VPN concentrators, or a
router simulator is your real key to success.
If you follow the preceding eight steps; really study and practice the review questions, bonus
exams, electronic flashcards, and written and hands-on labs; and practice with routers, a PIX
Firewall, VPN Concentrators, or a router simulator, it will be diamond-hard to fail the CSPFA
and CSVPN exams!
What Does This Book Cover?
Here’s the information you need to know for the CSPFA and CSVPN exams—the goods that
you’ll learn in this book. This book is broken into two Parts. Part 1—Chapters 1 through 6—
focuses on the CSPFA exam. Part 2—Chapters 7 through 10—focuses on the CSVPN exam.
Chapter 1, “PIX Firewall Basics,” introduces you to the basics of Firewall technology and
how they mitigate security threats. Chapter 1 also describes the types of PIX Firewalls and
licensing options available. We also discuss the Firewall Service Module (FWSM) and some
basic commands on the command-line interface (CLI).
Chapter 2, “PIX Firewall Configuration,” is an introduction on how to configure the Cisco
PIX Firewall. Chapter 2 explains how to configure DHCP server and client services; NAT
and PAT concepts and configurations; and static, dynamic, and multicast routing on the
PIX Firewall.
What Does This Book Cover?
xxxi
Chapter 3, “ACLs, Filtering, Object Grouping, and AAA,” explains how to configure
access control lists (ACLs) on the PIX Firewall and how object grouping can make ACLs
easier to configure and modify. We also cover how to configure URL filtering using Websense and N2H2 servers. Finally we cover how to install, configure, and administer the
CiscoSecure ACS on Windows 2000 and Windows NT servers plus how to implement AAA
services on a PIX Firewall.
Chapter 4, “Advanced Protocol Handling, Attack Guards, and Intrusion Detection,”
introduces you to the advanced protocol handling features of the Cisco PIX Firewall
and how it can be configured to guard against various denial of service (DoS) attacks.
This chapter also describes how you can implement the intrusion detections feature and
how to stop attacks.
Chapter 5, “Firewall Failover and PDM,” introduces you to the failover features of the PIX
Firewall and how to configure it for stateful failover operation. Chapter 5 explains how to
use the Java-based PIX Device Manager to configure the PIX Firewall using a generally
available Web browser.
Chapter 6, “VPNs and the PIX Firewall,” discusses how to implement site-to-site and
remote access VPNs on the PIX Firewall using the CLI and PDM and how to scale the VPN
support using digital certificates. This chapter also addresses how to configure and maintain multiple PIX Firewalls in an enterprise using CiscoWorks2000 components and the
PIX Cisco Secure Policy Manager.
Chapter 7, “Introduction to Virtual Private Networks,” provides a high-level overview of
VPN technologies and the complex group of protocols that are collectively known as IPSec.
Chapter 7 also identifies the key Cisco product offerings for the VPN market.
Chapter 8, “Introduction to Cisco VPN Devices,” briefly describes the VPN 3000 Concentrator products. Chapter 8 also explains how to set up the Cisco VPN 3000 series hardware
and software clients for a number of common VPN configurations. Information on preparing the client for mass rollout is also included.
Chapter 9, “Configuring the VPN Concentrator,” explains how to prepare the VPN Concentrator for use. This chapter includes basic setup as well as more complex features such
as load balancing and automatic software updates. Security features such as client firewalls
and protocol filters are also covered.
Chapter 10, “Managing the VPN Concentrator,” covers the many tools for monitoring
concentrator usage and troubleshooting problems. The chapter discusses a number of protocols that can be used to remotely monitor, configure, and troubleshoot the system. Chapter 10 also explains the tools available to control access to the administrative interfaces.
The Glossary is a handy resource for Cisco terms. It’s a great reference tool for understanding some of the more obscure terms used in this book.
Most chapters include written labs, hands-on labs, and plenty of review questions to make
sure you’ve mastered the material. Again, do not skip these tools. They’re invaluable to your
success.
xxxii
Introduction
What’s on the CD?
We’ve provided some very cool tools to help you with your certification process. All the following gear should be loaded on your workstation when studying for the test:
The All-New Sybex Test Engine
The test preparation software, developed by the experts at Sybex, prepares you to pass the
CSPFA and CSVPN exams. In this test engine, you will find all the review and assessment questions from the book, plus two bonus exams that appear exclusively on the CD. You can take the
assessment test, test yourself by chapter, or take the bonus exams. Your scores will show how
well you did on each CSPFA and CSVPN exam objective.
Electronic Flashcards for PC and Palm Devices
We’ve included about 150 flashcard questions that can be read on your PC, Palm, or Pocket PC
device. These are short questions and answers designed to test you on the most important topics
needed to pass the exams.
CCSP: Secure PIX and Secure VPN Study Guide in PDF
Sybex offers the CCSP: Secure PIX and Secure VPN Study Guide in PDF format on the CD so you
can read the book on your PC or laptop if you travel and don’t want to carry a book, or if you just
like to read from the computer screen. Acrobat Reader 5.1 with Search is also included on the CD.
Where Do You Take the Exams?
You may take the exams at any of the more than 800 Thomson Prometric Authorized Testing Centers around the world, www.2test.com, (800) 204-EXAM (3926). You can also register and take
the exams at a VUE authorized center as well, www.vue.com, (877) 404-EXAM (3926).
To register for a Cisco certification exam:
1.
Determine the number of the exam you want to take. (The CSPFA and CSVPN exams are
numbered 642-521 and 642-511, respectively.)
2.
Register with the nearest Thomson Prometric Registration Center or VUE testing center.
You’ll be asked to pay in advance for the exam. At the time of this writing, the exams are
$125 each and must be taken within one year of payment. You may schedule exams up to
Tips for Taking Your CSPFA and CSVPN Exams
xxxii
six weeks in advance or as late as the same day you want to take it. If you fail a Cisco exam,
you must wait 72 hours before you get another shot at retaking the exam. If something
comes up and you need to cancel or reschedule your exam appointment, contact Thomson
Prometric or VUE at least 24 hours in advance.
3.
When you schedule the exam, you’ll get instructions regarding all appointment and cancellation procedures, the ID requirements, and information about the testing-center location.
Tips for Taking Your CSPFA
and CSVPN Exams
The CSPFA and CSVPN exams contain between 55 and 65 questions each to be completed in
75 minutes. This can change per exam. You must score 82 percent to pass, but again, each exam
can be a tad different, so aim higher.
Many questions on the exam have answer choices that at first glance look a lot alike, especially the syntax questions (see the sidebar). Remember to read through the choices carefully
because close doesn’t cut it. If you get commands in the wrong order or forget one measly character, you’ll get the question wrong. So, to practice, do the hands-on exercises in this book over
and over again until they feel natural to you.
Watch That Syntax!
Unlike Microsoft or Novell tests, the CSPFA and CSVPN exams have answer choices that are
syntactically similar. Although some syntax is dead wrong, it is usually just subtly wrong.
Some other choices might be syntactically correct, but they’re shown in the wrong order. Cisco
does split hairs, and they’re not at all averse to giving you classic trick questions. Here’s an
example:
True or False: access-list 101 deny ip any any eq 23 denies Telnet access to all systems.
This statement looks correct because most people refer to the port number (23) and think, “Yes,
that’s the port used for Telnet.” The catch is that you can’t filter IP on port numbers (only TCP
and UDP).
xxxiv
Introduction
Also, never forget that the right answer is the Cisco answer. In many cases, more than one
appropriate answer is presented, but the correct answer is the one that Cisco recommends.
Here are some general tips for exam success:
Arrive early at the exam center so you can relax and review your study materials.
Read the questions carefully. Don’t jump to conclusions. Make sure you’re clear about
exactly what each question asks.
When answering multiple-choice questions that you’re not sure about, use the process of
elimination to discard the obviously incorrect answers first. Doing this greatly improves
your odds if you need to make an educated guess.
You can no longer move forward and backward through the Cisco exams, so double-check
your answer before pressing Next because you can’t change your mind.
After you complete an exam, you’ll get immediate, online notification—a printed Examination Score Report that indicates your pass or fail status and your exam results by section. The
test administrator will give you that report. Test scores are automatically forwarded to Cisco
within five working days after you take the test, so you don’t need to send in your score. If you
pass the exam, you’ll usually receive confirmation from Cisco within four weeks.
How to Contact the Authors
You can reach Wade Edwards at [email protected], where you can ask questions relating
to his books. You can reach Jason Rohm at [email protected]
Assessment Test
xxxv
Assessment Test
1.
What is the name of the VPN software client’s global configuration file?
A. vpnclient.ini
B. oemsetup.inf
C. ipsecdlr.ini
D. vpnclient.pcf
2.
How many groups are configured on a VPN 3000 Concentrator by default?
A. Zero
B. One
C. C.Two
D. D.15
3.
Which type of VPN is typically used by a mobile sales force?
A. Intranet VPN
B. Extranet VPN
C. Access VPN
D. Transit VPN
4.
Which RFC defines the Encapsulating Security Payload (ESP) Header?
A. 1918
B. 1826
C. 2402
D. 2406
5.
You enter enable password abcdefg encrypted from the Privileged mode prompt. Is this a
valid command? (Choose all that apply.)
A. Yes, it is a valid command.
B. No, you must enter that command from the Configuration mode prompt.
C. No, encrypted passwords must be exactly 16 characters.
D. No, the password must be enclosed in quotation marks.
xxxvi
6.
Introduction
How many VLAN interfaces can be defined on the Firewall Services Module?
A. 10
B. 50
C. 100
D. There is no limit to the number of VLAN interfaces.
7.
Which keyword is used to identify DNS traffic (TCP port 53) through the PIX Firewall?
A. dns
B. dnsix
C. domain
D. names
8.
Which of the following protocols allows for the generation of a shared secret over an insecure
connection?
A. Message-Digest 5 (MD5)
B. Diffie-Hellman (DH)
C. Internet Key Exchange (IKE)
D. Security Parameter Index (SPI)
9.
When the PIX Firewall redirects you to another server for authentication, how do you get back
to the original URL?
A. You are automatically redirected back to your original URL after authentication.
B. You have to reenter the URL after authentication.
C. There is a link to get back to the original URL on the redirect page.
D. There is no redirection; you are sent to the entered URL.
10. Which protocol can be used for command authorization?
A. RADIUS
B. TACACS+
C. RADIUS
D. None of the above
Assessment Test
xxxvii
11. What feature is especially challenging about the RTSP protocol?
A. It is connectionless.
B. It uses all multicast addresses.
C. It can use almost any TCP or UDP port, RTP, HTTP, or the control session for
transport.
D. It does not have a control session for the PIX Firewall to monitor.
12. Which feature is used to provide for multiple VPN clients when the tunnels pass through a firewall or router using port address translation (PAT)?
A. NAT-Transversal
B. IPSec over UDP
C. IPSec over TCP
D. LAN-to-LAN NAT
13. Which of the following actions can be tied to an attack signature class?
A. Alarm
B. Drop
C. Reset
D. All the above
14. How many poll intervals must pass without receiving a hello packet for a PIX Firewall to begin
the failover sequence?
A. One
B. Two
C. Three
D. Four
15. What does it mean if the secondary PIX Firewall is also the active PIX?
A. A failover has occurred.
B. This cannot happen.
C. This is the normal status.
D. You have misconfigured the secondary PIX Firewall.
xxxviii
Introduction
16. Which of the following commands contains the appropriate syntax for configuring the inside
interface with IP address 10.1.1.1?
A. interface ip (inside) 10.1.1.1 255.255.255.0
B. ip address (inside) 10.1.1.1 255.255.255.0
C. ip address 10.1.1.1 255.255.255.0
D. ip address inside 10.1.1.1 255.255.255.0
17. When the VPN 3000 configuration is saved, what is the previous configuration file renamed?
A. VPN3000.RST
B. CONFIG.BAK
C. SHADOW
D. FILE000.CHK
18. What command is used to see the public key of the local device?
A. show crypto ca mypubkey rsa
B. show ca mypubkey rsa
C. show crypto pubkey-chain rsa
D. show ca pubkey-chain rsa
19. Which attack guard feature is not enabled by default?
A. Fragmentation guard
B. Flood guard
C. DNS guard
D. Mail guard
20. The PIX Management Center uses which port to communicate to the PIX Firewall?
A. UDP/1024 or above
B. UDP/23
C. TCP/80
D. TCP/443
E. TCP/21
21. When using certificates, NTP should be used. What is NTP?
A. Network Test Packet
B. Network Time Packet
C. Novell Test Packet
D. Network Time Protocol
Assessment Test
xxxix
22. How many users can be supported by a VPN 3002 Hardware Client?
A. 10
B. 50
C. 100
D. 253
23. When a VPN concentrator or hardware client is initially set up, it prompts the administrator for
basic information. What is this feature called?
A. Initial Setup Wizard
B. Quick Configuration mode
C. Bootstrap script
D. Initialization dialog
24. The interfaces dmz and isp1 have both been set with a security level of 20. What traffic will the
PIX Firewall allow between these interfaces?
A. Hosts on the isp1 network can create a translation slot to the dmz network, but hosts
on the dmz network cannot create a translation slot to hosts on the isp1 network.
B. Hosts on the dmz network can create a translation slot to the isp1 network, but hosts
on the isp1 network cannot create a translation slot to the hosts on the dmz network.
C. Hosts on either network can create a translation slot to the other network.
D. No direct connectivity is allowed between hosts on the dmz and isp1 networks.
25. Which Cisco VPN 3000 series model includes two Scalable Encryption Processing (SEP) modules?
A. 3015
B. 3030
C. 3060
D. 3080
26. Which command sets the password for telnet access to the PIX Firewall?
A. enable telnet
B. telnet password
C. passwd
D. login password
27. Which type of object group can be nested within a network object group? (Choose all that apply.)
A. Network
B. Service
C. ICMP
D. Protocol
xl
Introduction
28. What feature/service must be used when you need to collect more than 256 log entries on a
VPN 3005 Concentrator?
A. Automatic log filtering
B. Flash compression
C. SNMP traps
D. syslog server
29. Which of the following is a valid authentication protocol when using encryption with PPTP?
A. Password Authentication Protocol (PAP)
B. Challenge-Handshake Authentication Protocol (CHAP)
C. Microsoft CHAP (MS-CHAP)
D. Shiva Password Authentication Protocol (SPAP)
30. What username do you use to log in to the PDM when you are not using AAA?
A. pix
B. enable
C. A blank username
D. Any of the above will work with the proper enable password.
Answers to Assessment Test
xli
Answers to Assessment Test
1.
A. The Cisco Unified Client saves its global configuration settings in a standard Windows .ini
file called vpnclient.ini. For more information, see Chapter 8.
2.
B. The VPN 3000 series has one built-in group called the base_group. The base group cannot
be disabled or deleted. For more information, see Chapter 10.
3.
C. Cisco distinguishes between access, intranet, and extranet VPNs. The access VPN type is the
most common VPN type and applies to any part-time single-user connection. For more information, see Chapter 7.
4.
D. The IPSec standards are defined in a number of request for comments (RFC) documents.
The Authentication Header (AH) is primarily defined in 1826 and 2402. ESP is defined as
RFC 2406. For more information, see Chapter 7.
5.
B, C. Passwords are configured from the Configuration mode, and an encrypted string must be
exactly 16 characters long. It would be okay to enter abcdefg as an unencrypted password, but
once the PIX Firewall encrypts it, the encrypted string will always be exactly 16 characters long.
See Chapter 1 for more information.
6.
C. Every PIX Firewall is shipped with a 56-bit DES license, but you can upgrade to the 168-bit
3DES license. See Chapter 1 for more information.
7.
C. The dns keyword describes the dnsix port, and names and dnsix are not valid keywords.
See Chapter 2 for more information.
8.
B. Diffie-Hellman key exchange uses mathematical associations to generate an encryption key
known as a shared secret. Since the key is generated on each end, it is known only to the
exchange partners and is never sent over the network. For more information, see Chapter 7.
9.
A. You will be automatically redirected back to the original URL after authentication. See
Chapter 3.
10. B. TACACS+ is the only protocol that can be used to authorize commands using AAA. See
Chapter 3.
11. C. RTSP can use other protocols such as RTP or HTTP or even its own control session for
transport, and it can use a wide range of TCP and UDP ports. See Chapter 4.
12. C. Only IPSec over TCP supports multiple clients through a firewall or router using PAT. For
more information, see Chapter 9.
xlii
Introduction
13. D. You can tie all the above actions to either an attack or informational signature class. See
Chapter 4.
14. C. The PIX Firewall will wait for three failover intervals. See Chapter 5 for more
information.
15. A. The secondary PIX Firewall will become the active PIX Firewall after a failover.
See Chapter 5 for more information.
16. D. The command does not use parentheses, but it does require the interface name.
See Chapter 2 for more information.
17. B. The primary configuration file is called CONFIG; when the configuration is saved, a backup
copy named CONFIG.BAK is saved to flash. For more information, see Chapter 10.
18. B. The command show ca mypubkey rsa is used to view the firewall’s public key.
19. A. The Fragmentation Guard must be enabled manually. The others are on by default.
See Chapter 4.
20. D. The PIX MC uses the Secure Sockets Layer protocol on TCP port 443 for secure communications with the PIX Firewall.
21. D. Network Time Protocol allows for accurate time to be kept by configuring the firewall to
communicate with a timeserver.
22. D. The hardware client supports up to 253 users, but is recommended only for 50 or less. For
more information, see Chapter 8.
23. B. The initial configuration is done using Quick Configuration mode. For more information,
see Chapter 9.
24. D. No connectivity is allowed between equal interfaces. See Chapter 2 for more information.
25. C. Models 3015 through 3080 are upgradeable to four SEP modules. Only model 3060
includes two of these as part of the standard bundle. For more information, see Chapter 8.
26. C. The passwd command is the only valid command listed here. See Chapter 1 for more
information.
27. A. Only like object types can be nested within each other. See Chapter 3.
28. D. The VPN 3000 series has a limited amount of space for log storage. If you need more storage
or a historical database, you need to send those logs to a syslog server. For more information,
see Chapter 10.
Answers to Assessment Test
xliii
29. C. Encryption is supported with Point to Point Tunneling Protocol only when MS-CHAP is
used as the password protocol. For more information, see Chapter 9.
30. C. When not using AAA, the username must be left blank and the enable password used at the
login prompt. See Chapter 5 for more information.
Cisco Secure PIX
Firewall
Advanced
PART
I
Chapter
1
PIX Firewall Basics
THE FOLLOWING TOPICS ARE COVERED IN
THIS CHAPTER:
Firewall technology overview
Overview of the PIX Firewall models
Understanding PIX Firewall licensing
Using the PIX Firewall user interface
Defining the ASA security levels
Overview of basic PIX Firewall configuration
Using the Firewall Services Module (FWSM)
This chapter begins our detailed look at Cisco’s firewall solutions,
laying the groundwork for all the information you need to know
for the Cisco Secure PIX Firewall Advanced (CSPFA) exam. We
will go into comprehensive coverage of installation and configuration in later chapters, but first,
we will take a broader view of firewalls in general.
We will begin by discussing the role of firewalls in network security—what they can do and
what they cannot do. We’ll cover the hardware and software components of the Cisco Secure
PIX Firewall including the different models and licensing available, and explain how they all fit
together to help protect networks. Next, there will be an overview of the Catalyst 6500 series
and Cisco 7600 series Firewall Services Module (FWSM) and how to do basic configuration.
Finally, we will cover the PIX Firewall command-line interface (CLI) and some of the basic commands used to manage the PIX Firewall.
Understanding a Firewall’s Role
in Network Security
Like many network devices, firewalls have evolved considerably since their inception, as networks themselves have evolved considerably. In this section, we will discuss what threats firewalls are designed to counter and some types of threats that firewalls are powerless against. We
will also look at the firewall in relation to the rest of the network and what the firewall actually
is. We begin with a common definition.
What Is a Firewall?
A firewall is a system or group of systems that enforces an access-control policy between two
or more networks, usually between the Internet and the internal networks of a company, but
sometimes between internal networks. Although new classes of products, such as “personal firewalls” that reside on PCs, have now muddied that definition somewhat, it remains fundamentally accurate.
There are several important points regarding the effectiveness of a firewall, each of which is
discussed in the following sections.
Understanding a Firewall’s Role in Network Security
5
Policy Enforcement
A firewall is the mechanism that enforces a policy. It does not design or define the policy, nor is
it the policy itself; it simply carries out the policy. In the discipline of policy management, which
is rapidly becoming integrated with Cisco’s security tools, a firewall is an example of a policy
enforcement point (PEP). The decisions about the policy are made in a policy decision point
(PDP), and the policy itself resides in a repository. In some implementations, one physical device
might perform all three of these functions, but these distinctions are important nevertheless.
Firewall Location
To enforce a policy between two networks, the firewall must reside between the two networks.
Just like the firewalls in cars and buildings (typically made of large sheets of steel or fireretardant material) that exist to slow the spread of real fires, network firewalls act as a border
between the two systems to prevent something bad in one system from finding its way into the
other system.
In a data network, the firewall must exist at the point through which the data passes on its
route from one network to the other. If there are multiple paths, as there often are, there must
be multiple firewalls to be effective. This is why a firewall can also be a group of systems.
Understanding the location of firewalls is crucial because firewalls can help to secure only the
perimeter of the network. They cannot protect internal systems from internal users, nor can they
prevent users from connecting modems to their desktops and accessing the internal network via
dial-up analog lines. Again, if the physical path of the data as it travels through the network
does not pass through the firewall, the firewall offers no protection.
Trusted Networks
A third, more subtle point is that the presence of an access-control policy implies that one network is more trusted than another. In fact, this statement must be made from the perspective
of a device on each network. You might consider your local network to be more secure than the
network on the other side of the firewall. If not, why have a firewall at all? However, a device
on the other side of the firewall might consider its local network more secure than your side of
the firewall.
As you will see later in the “The Adaptive Security Algorithm (ASA) and Security Levels” section of this chapter, this relative level of trust is a key to the operation of the PIX Firewall.
Firewall Systems
As our definition points out, the firewall is a system. The firewall system itself can be implemented in many ways. In other words, it’s not necessarily a black box with two Ethernet ports.
It can be one physical box, several boxes, or none at all.
The most common firewall system is a software application that runs on top of a generalpurpose operating system, such as Windows 2000 Server or Unix, with general-purpose hardware,
such as the Intel-based PC or Sun Microsystems’ Sparc Station. Another method of implementing
firewall features is using custom hardware and software, designed with a single purpose in mind.
6
Chapter 1
PIX Firewall Basics
What Are the Potential Threats?
As described in the previous sections, the firewall is a point in the perimeter of the network that
enforces an access-control policy between two networks that trust each other to varying degrees.
To better understand the role of a firewall, we will next look at the potential threats to network
security. Three primary types of threats are addressed by network security:
Privacy violations Privacy violations occur when confidential data is exposed. This can occur
on a host, such as the highly publicized Web server break-ins that allowed hundreds of thousands of credit card numbers to be stolen. Privacy violations can also occur on the network
itself. For example, an intruder with a packet sniffer might view confidential information, such
as your password, as it is transmitted across the network.
Breach of integrity A breach of integrity occurs when data in a system is altered. Again, this
can occur on a host or on the network itself. An example of a breach of integrity on a host is
the defacement of a website. An example on the network could be a “man-in-the-middle”
attack, where the data inside a packet is intercepted and modified as it traverses the network.
Denial of service (DoS) The two most common ways of denying service are on a host and in
the network. Commonly, a flaw in the host is exploited to cause it to crash or waste CPU cycles
or memory, starving the legitimate applications. In the network, an attack might try to use all
available bandwidth or send invalid information to a routing protocol to cause it to redirect
your traffic to the wrong location. A particularly nasty type of DoS attack is called the distributed denial-of-service (DDoS) attack. This term describes an attack where several (often thousands of) unsuspecting hosts are compromised and then used to attack a single target in unison.
The overall goal is to keep these threats from becoming a reality. The objective of network
security is to create a policy that makes these attacks prohibitively difficult or expensive. The
role of the firewall is to enforce this policy at the network perimeter.
Reviewing Firewall Technologies
Because there are many types of threats, there are many types of policies to deal with these
threats. Because these policies operate at many different levels, there are several different types
of firewalls. Here, we will concentrate on three common types:
Application proxy (a type of dual-homed gateway)
Packet-filtering firewall
Stateful firewall
Of course, any given firewall product may implement one or more of these techniques.
Dual-Homed Gateways
There are several types of dual-homed gateways. Application proxies (often called proxy servers) and bastion hosts are common examples. All of the dual-homed gateways have one thing
Reviewing Firewall Technologies
7
in common: Physically and as far as the operating system is concerned, the dual-homed gateway
is actually a host on two different networks at the same time. This device is not a router or a
switch; routers and switches forward packets at layer 2 or 3 (the Data-Link or Network layer
of the OSI model). Rather, the dual-homed gateway acts as a host. Packets are sent to it, and it
processes them in the same way as any other host, passing them all the way up to layer 7 (the
Application layer), where they are inspected by a proxy application.
The proxy is “application-aware.” For example, a Web proxy understands the HTTP protocol. It knows what the commands mean and can decide whether the users are allowed to access
a certain URL or whether specific content returned to the client is allowed inside the network.
Generally speaking, dual-homed gateways are very useful for Application-layer filtering, and
they excel at auditing. For instance, if you’ve used a Web proxy server, you might have noticed
that the log files are quite detailed and can grow very large.
Unfortunately, dual-homed gateways have several drawbacks:
They are inherently slow. Their high latency often creates problems with real-time traffic,
such as streaming media.
Because they are application-aware, they must be programmed to understand the application. If the manufacturer does not support the particular service or protocol you need, you
will need to find another solution.
Once they are compromised, the gateway can be used as a launch pad for attacks into the
formerly protected network. This is typically possible on dual-homed gateways because
they often run general-purpose operating systems, which makes it easy to develop attack
software.
Special-purpose operating systems and hardware rarely publish their application programming interfaces (APIs) and other specifications, so developing
rogue programs to run on these systems would be an extremely difficult task.
Application gateways are very good at preventing unauthorized access to services or data, both
inbound and outbound. They provide some protection against privacy violations on the hosts, but
not for data in transit, and they actually become an additional point of failure for DoS attacks.
Packet-Filtering Firewalls
Packet-filtering firewalls operate at a much lower level of the OSI model than dual-homed gateways in the network. In fact, this functionality is often implemented on routers and switches,
which process packets only at layers 2 through 4 (Data-Link, Network, and Transport).
Packet-filtering firewalls simply match values in the headers of frames and packets and permit or deny packets based on a set of rules. The most commonly used fields are as follows:
The layer 2 source address and destination address, most often the MAC addresses
The layer 3 source address and destination address, most often the IP or Internetwork
Packet Exchange (IPX) addresses
8
Chapter 1
PIX Firewall Basics
The options in the layer 3 header, such as the fragmentation bits
The layer 4 source address and destination address, most often the TCP or UDP ports
The options in the layer 4 header, such as the SYN bit
Packet-filtering technology has been around for some time and is often considered an old
technology that is no longer useful, but it does have a few advantages:
It is very cheap and widely available.
The lower a function is on the OSI model, the faster it is, so packet-filtering firewalls generally have a tremendous speed advantage compared with application gateways.
It is simple, fairly reliable, and easy to maintain. Its simplicity also makes it easy to implement in hardware.
It is particularly useful in combination with other technologies. In modern security architecture, packet filtering is often used on screening routers.
On the other hand, packet filtering has its share of problems:
The rules are commonly static in nature, so services such as FTP, which use random ports,
are often blocked accidentally.
Undesired packets can be fabricated to match the “permit” rules. For instance, a packet
could be fabricated to appear as if it were already part of an established TCP connection,
and it would be permitted to pass through the firewall.
The order in which the rules are placed is critically important. If there are a large number
of rules, it is easy to make mistakes when manually maintaining these rules.
Older packet-filtering platforms had difficulty with fragmented packets because only the
first packet contains the header information. Sending specially formed, fragmented packets, or not sending the final fragment, would often crash older host systems.
Despite these shortcomings, packet-filtering technology is still useful because it provides a
moderate amount of protection against all three of the primary threats described in the “What
Are the Potential Threats?” section earlier in this chapter. Cisco has implemented this technology in the form of access control lists (ACLs) in all versions of their Cisco IOS software. Combining these ACLs with other firewalls, such as the PIX Firewall, can create a much more robust
security system than either tool by itself.
Stateful Firewalls
Stateful firewalls operate in the same manner as packet-filtering firewalls, except they work on
connections instead of packets. Put another way, a stateful firewall has the ability to permit or
deny a packet based on other packets. For example, if a TCP packet arrives claiming to be from
an established connection (that is, it doesn’t have the SYN bit set), the packet-filtering firewall
would let it pass, but the stateful firewall would still deny this packet if any of the following conditions are met:
It has not seen the three-way handshake of SYN, SYN-ACK, and ACK for that connection.
Reviewing Firewall Technologies
9
The TCP sequence and acknowledgment numbers are not correct (these would be based on
the previous packet).
The packet contains a response when there wasn’t previously a command.
As you can see, when properly implemented, stateful filtering can make forging packets practically impossible.
Stateful firewalls also excel in preventing DoS attacks. For instance, conceivably, you could
allow Ping traffic into your network. If someone attempted to send you 100,000 Internet Control
Message Protocol (ICMP) requests at once, the packet-filtering firewall would let all of them
through. However, the stateful firewall could be configured with a reasonable threshold, and then
after this threshold was crossed, automatically deny all future requests until the flood subsided.
Generally, stateful firewalls provide the following benefits:
Much higher performance than application gateways
Stronger security than packet filtering
Easy administration
However, because they do not necessarily operate at the Application layer, stateful firewalls
do not offer as strong control over applications as do dual-homed gateways. This also means
that their auditing will not be as detailed.
Firewall Technology Combinations
Each of the three firewall types mentioned in the previous sections has different strengths and
weaknesses. While we compare them here academically, in the real world, they are often all used
together.
For instance, the application gateway and proxy servers provide some protection for the
application, but they themselves are vulnerable to other attacks, such as DoS attacks. To protect
the proxy servers, we typically put them in what is called a screened subnet or a DMZ (for
demilitarized zone). This is a protected network that sits between a trusted internal network and
a totally untrusted external network. From the perspective of a typical company’s internal network, the DMZ is trusted less than the internal network, but more than the external network.
There are two common screened-subnet designs used today, which are described in the following sections.
Packet-Filtering Router, Stateful Firewall, and Application
Proxy Combination
One type of screened subnet employs a packet-filtering router to separate the outside network
from the DMZ. Then a stateful firewall connects the DMZ to the inside network. An application
proxy typically resides inside the DMZ, so traffic does not flow directly from the inside network
to the outside network or from the outside network directly to the inside network. Instead, all traffic from the inside network to the outside network flows to and from the proxy server. However,
traffic from the outside network to the other servers, such as the Web and FTP servers, does not
pass through the proxy server, but goes directly to the appropriate server. The data flow of this
design is shown in Figure 1.1.
10
Chapter 1
FIGURE 1.1
PIX Firewall Basics
Traffic flow in a modern screened subnet
External
network
Packetfiltering
firewall
DMZ
Proxy server
WWW server
FTP server
Stateful
firewall
Internal
network
Users
Throughout this book, we use the terms DMZ and screened subnet interchangeably.
The combination of these three firewall technologies provides much more security than any
one technology alone. The routers in this network provide high-performance packet filtering,
and the application-aware proxy servers make attacks as difficult as possible. The stateful firewall protects the resources on the internal network, without affecting the performance of Web
servers and other devices in the DMZ.
Another advantage of this design is that the access to the proxy server often requires authentication, based on the user’s ID on the internal network (such as an account on a Windows
domain). This makes access into the internal network more secure, without requiring the management of an infinite number of accounts on the outside network, which are accessing your
Web and FTP services.
The combination of low-level support by the packet-filtering firewall, application-level support from the dual-homed gateway, and protection from DoS attacks is a classic case of synergy,
Reviewing Firewall Technologies
11
where the whole is greater than the sum of the parts. This technique is sometimes called defense
in depth.
A Stateful Firewall with Multiple Interfaces
The second type of screened-subnet design is similar to the one just described, but it’s a little more
efficient and cost-effective. It takes advantage of multiple interfaces on the newer, faster firewalls.
However, the traffic flow is fundamentally unchanged. This design is shown in Figure 1.2.
FIGURE 1.2
A cost-effective alternative DMZ design
External
network
Stateful
firewall
with 3
faces
inter
DMZ
Proxy ser
ver
WWW ser
ver
FTP ser
ver
Internal
network
Users
This design has two inherent characteristics, which are both a result of all the data passing
through a single firewall. The negative characteristic is that the additional traffic might affect
performance. The positive characteristic is that seeing all the traffic might allow the firewall to
make more intelligent filtering decisions than a firewall that sees only part of the traffic.
12
Chapter 1
PIX Firewall Basics
Hardware and Software Components of
the Cisco Secure PIX Firewall
Now that you understand the basic firewall technologies and their usefulness, we can describe
the basic characteristics of the PIX Firewall. The PIX Firewall, where PIX is an acronym for private Internet eXchange, is one of the world’s premier firewalls because its unique operation provides strong security and very high performance. It is not based upon a mainstream operating
system, such as Windows or UNIX, but on a hardened, secure, embedded operating system
know as Finesse. In this section, we will begin to discuss its operation and various features that
contribute to its speed and protection.
Admittedly, the information in this section is more marketing-related than technical, and as such, isn’t likely to be on the exam. However, it is important to
understand the background and context in which Cisco places the PIX Firewall.
This understanding will also benefit you immensely after the exam, when it
comes time to select and install a firewall in your network.
The PIX Firewall has its roots in Network Address Translation (NAT), with the ability to
maintain information about the state of each connection that passes through it, and then filter
(permit or deny) traffic based on that state. For this reason, it is classified as a stateful firewall.
PIX Firewall Features
The PIX Firewall series uses specially designed hardware and a very small, proprietary, multithreaded kernel. On the lower-end models, the hardware is fixed-configuration, but the higherend models support modular interface cards for many different types of media, up to gigabit
speeds. The advantage here is that the extraneous equipment and issues associated with hard
drives, CD-ROMs, GUIs, monitors, keyboards, mice, and so on are eliminated, without losing
the core functionality of the firewall.
The PIX Firewall features support for Internet Protocol Security (IPSec), virtual private networks (VPNs), cut-through proxy switching, inbound and outbound authentication, failover,
and more. These features are covered in this section and in later chapters.
Another feature, which administrators will appreciate, is that compared with some firewalls,
particularly the ones running on general-purpose operating systems, the PIX Firewall is easy to
configure and hard to misconfigure. Unlike many firewalls, the PIX Firewall hardware and software are based on a pessimistic, or restrictive, security model. In other words, by default, everything is denied. To allow network traffic to pass through the PIX Firewall it must be explicitly
configured to accept that traffic.
The latest versions of the PIX Firewall operating system have even more new features. One of
the most eagerly anticipated features is multicast support. The PIX Firewall now supports multicast routing (with the mroute command) and Internet Group Management Protocol (IGMP).
Hardware and Software Components of the Cisco Secure PIX Firewall
13
PIX Firewall Components
In this section, we will explore the parts that make up the PIX Firewall. Before we get into the
nuts and bolts, you should understand that simplicity is an important competitive advantage in
the realm of security, because as components in a system become more complex, there are more
opportunities to take advantage of the system. The PIX Firewall has succeeded in maintaining
a very simple, almost minimalist, list of components.
On the PIX Firewall, some of these components can be seen by typing the show version
command at the privileged exec prompt, as seen in Listing 1.1 (we’ve boldfaced the sections of
interest here for clarity).
Using the show version command
PIX# show version
Cisco Secure PIX Firewall Version 6.0(1)
Compiled on Thu 17-May-01 20:05 by morlee
PIX up 58 secs
Hardware: PIX-515, 64 MB RAM, CPU Pentium 200 MHz
Flash i28F640J5 @ 0x300, 16MB
BIOS Flash AT29C257 @ 0xfffd8000, 32KB
0: ethernet0: address is 0050.54ff.076d, irq 10
1: ethernet1: address is 0050.54ff.076e, irq 7
2: ethernet2: address is 00d0.b79d.8856, irq 9
Licensed Features:
Failover:
Enabled
VPN-DES:
Enabled
VPN-3DES:
Disabled
Maximum Interfaces:
6
Cut-through Proxy:
Enabled
Guards:
Enabled
Websense:
Enabled
Throughput:
Unlimited
ISAKMP peers:
Unlimited
Serial Number: 403420127 (0x180bb3df)
Activation Key: 0x9aa99a8d 0xc56166de 0x4ecd338a
0x5b6d06eb
PIX#
14
Chapter 1
PIX Firewall Basics
As you can see, the components shown by the show version command are the central processing unit (CPU), random access memory (RAM), flash file system, system image, BIOS, interfaces, and licensed features. Let’s take a closer look at each of these components.
CPU
The PIX Firewall uses the Intel Pentium line of processors as the CPU. This is where the software
image is executed and most of the rules are processed. Also, tasks such as encryption using IPSec
are performed here (unless an optional VPN accelerator card is installed, which offloads this
processing to a dedicated processor).
The show version command shows the type and speed of the processor. The show cpu
usage command gives the average processor utilization for the past five seconds, one minute,
and five minutes, as in this example:
PIX# show cpu usage
CPU utilization for 5 seconds = 0%; 1 minute: 0%;5 minutes: 0%
PIX#
RAM
RAM is the primary memory used by the PIX Firewall. Instructions being executed by the CPU
exist here. Also, RAM is used for packet buffers and the various tables, such as state information, dynamic NAT entries, the translation (xlate) tables (described in the “NAT Mechanisms”
section later in this chapter), and more.
The sample show version output in Listing 1.1 shows that this PIX Firewall has 64MB of
RAM. You can also use the show memory command to see the available or unused memory:
PIX# show memory
67108864 bytes total, 51089408 bytes free
PIX#
Flash File System
The physical flash memory used in PIX Firewalls is similar to that used in Cisco’s router and
switch platforms. However, the file system used by the PIX Firewall is considerably different.
The file system used in Cisco’s IOS allows any number of files to be stored, including multiple
images, copies of the configuration file, and so on. Each of these can be manipulated by a filename. However, the PIX Firewall flash file system version 1 divides the flash into four sectors.
Each of these sectors contains one file. Version 2 of the flash file system adds one more sector,
for a total of five, to support the GUI configuration software, PIX Device Manager (PDM).
The show flashfs command shows the length of each file, but not their filenames:
PIX# show flashfs
flash file system:
file 0: origin:
version:2 magic:0x12345679
0 length:2449464
Hardware and Software Components of the Cisco Secure PIX Firewall
file
file
file
file
PIX#
1:
2:
3:
4:
15
origin: 2490368 length:1463
origin:
0 length:0
origin:
0 length:0
origin: 8257536 length:280
The files are used as follows:
File 0 is the PIX Firewall binary image. This is the BIN file. (See the next section for details
on the PIX Firewall system image.)
File 1 is the PIX Firewall configuration data, viewed with the show config command.
File 2 contains the firewall’s IPSec key and certificates.
File 3 contains the PDM software.
File 4 contains downgrade information for previous versions.
Access to these files is much more restricted than access to the Cisco IOS flash file system. To
enhance security, the ability to copy files from flash to FTP, TFTP, another file on the flash, or other
locations is no longer available. Also gone are flash partitions and the detailed information, such
as checksums. Although the lack of these features might not seem like an enhancement, their exclusion helps prevent your private keys from being stolen. The maintenance of the flash system—such
as compacting, formatting, and squeezing—is handled automatically on the PIX Firewall.
System Image
The system image is a binary executable file that resides in file 0 in the flash. Older models store
the image on 3.5-inch floppy disks. The image contains all the code for the PIX Firewall operating system and all the features—NAT, IPSec, filtering, and so on.
Unlike Cisco IOS images, where there are many images for each platform and each image
contains only a certain set of features, there is only one image per software version for the PIX
Firewall. This image contains all the features Cisco has developed for PIX Firewall, but certain
features may be enabled and disabled by the licensing keys (see the “Licensed Features” section
later in this chapter).
To install or upgrade an image, you must copy it across the network, typically with TFTP,
or replace the flash memory with flash containing the new image. For PIX Firewall models that
use floppy disks, simply swap the floppy with the one containing the new image and reboot.
The PIX Firewall operating system itself is non-Unix, real-time, and embedded.
BIOS
The BIOS of the PIX Firewall operates in the same way as the BIOS of other Intel processor–
based computers. It is responsible for the initial boot sequence and loading the PIX Firewall
software image located in file 0.
The BIOS is stored in a special chip, separate from flash. Although upgrades to the BIOS are
seldom necessary (an example would be date fixes for the Y2K bug), upgrading it is possible.
16
Chapter 1
PIX Firewall Basics
Flash Exploits
Years ago, it was a trivial (pun intended) exercise to gain unauthorized access to most Cisco
routers. The primary reason for this was that most router administrators would configure TFTP
so that they could copy system images to and from the routers and make backup copies of their
configuration files. Because TFTP has no authentication, and does not even require a password, all intruders needed to know was the name of the configuration file, and they could send
a TFTP Get request to the router. The router would promptly return the configuration file, which
of course, contained the login and enable passwords. Although the password was encrypted
in the configuration file, it was just a matter of time before it was cracked. If the password could
be found in a dictionary, this “matter of time” was probably a few seconds.
While it’s still possible to configure routers like this, it is unusual. This is because newer versions of Cisco IOS have more secure default settings and support more secure protocols, such
as FTP, which at least requires a username and password.
With the PIX Firewall, the security is much tighter. In fact, configuration file theft is exactly the
type of attack the PIX Firewall’s flash system is designed to thwart. It is immune to this type of
attack because you can only send files to the PIX Firewall; you cannot download from it.
Interfaces
Most PIX Firewalls have at least three fixed ports: RJ-45 (console connector), DB15 (failover
connector), and USB (not currently used).
Depending on the model, PIX Firewalls also have one or two fixed Fast Ethernet interfaces
for data traffic and a number of slots for optional interfaces. These interfaces are labeled much
like router interfaces: 10/100 Ethernet 0, 10/100 Ethernet 1, and so on.
Internally, the interfaces are numbered and named. For instance, using the command show
interface ethernet1, we see that the interface numbered ethernet1 is named inside:
PIX# show interface ethernet1
interface ethernet1 "inside" is up, line protocol is up
Hardware is i82559 ethernet, address is 0050.54ff.076e
IP address 10.1.1.20, subnet mask 255.255.255.0
MTU 1500 bytes, BW 100000 Kbit full duplex
395 packets input, 43128 bytes, 0 no buffer
Received 395 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun,
0 ignored, 0 abort
1 packets output, 64 bytes, 0 underruns
Hardware and Software Components of the Cisco Secure PIX Firewall
17
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collisions, 0 deferred
1 lost carrier, 0 no carrier
input queue (curr/max blocks): hardware (128/128)
software (0/2)
output queue (curr/max blocks): hardware (0/2)
software (0/1)
PIX#
All PIX Firewalls have at least two interfaces, but several models support six or more interfaces. By default, these two interfaces are named inside and outside. The name inside
is reserved for a network that has a security level of 100 (the maximum). The name outside is
reserved for a network that has a security level of 0 (the minimum). We will discuss the security levels in more depth in the “The Adaptive Security Algorithm (ASA) and Security Levels”
section later in this chapter.
Some models of the PIX Firewall have more than one internal bus, which shuttles data from the interfaces to the CPU and RAM. For instance, the PIX 535 has
three separate buses: two run at 66MHz or 33MHz, and the third runs at only
33MHz. Some interface cards, such as the Gigabit Ethernet interface card, come
in 33MHz and 66MHz flavors, so the interface you use and the slot you choose
can greatly affect your system’s performance. Other interface cards, such as
the VPN accelerator and four-port FastEthernet cards, can be placed only in
33Mhz slots, or the system will hang at boot time.
Secure PIX Firewall Product Line
The following is a brief description of the PIX Firewall product line, the chassis type, and the
maximum number of interfaces supported. A more detailed description can be found at
www.cisco.com/warp/public/cc/pd/fw/sqfw500/.
Model
Interfaces
Chassis
501
1 10BaseT and four-port 10/100 switch
desktop
506E
2 10BaseT
desktop
515E
6 FastE
modular
525
8 FastE or 3 GigE
modular
535
10 FastE or 9 GigE
modular
18
Chapter 1
PIX Firewall Basics
Licensed Features
Cisco has three basic licenses for the PIX Firewall:
The Restricted license sets a limit on the number of connections and interfaces and disables
failover.
The Unrestricted license has no limit on connections, enables failover, and allows as many
interfaces as the hardware supports.
The Failover license, the least expensive license, is intended for a backup firewall (when
using the failover feature) and assumes the license characteristics of the primary firewall.
In addition to these licenses, each PIX Firewall comes with a license for IPSec encryption
using 56-bit Data Encryption Standard (DES) or Triple Data Encryption Standard (3DES) using
168 bits.
The encryption and firewall licenses are independent from the version of operating system. The version of the operating system can be updated without
affecting the licenses and the licenses can be updated without affecting the
operating system version.
All features, including cut-through proxy, attack guards, N2H2, and Websense support are
included in the Unrestricted license. Older models of the PIX Firewall had multiple Restricted
versions that were limited to 128 connections or 1,024 concurrent connections.
Each PIX Firewall has a unique serial number. This serial number and the licenses purchased
are used as the inputs to a mathematical formula that generates an activation key. This key is
entered as the system image is being installed and determines which features are available on the
firewall. When you do a flash upgrade, you need the serial number of the flash card, too.
As of version 6.2, the activation-key command was added so that code and boot-time
upgrades are not needed to upgrade the activation key. For prior versions, to change your license,
you must reload the system image. For instance, if you purchase a license-activation key for 3DES
encryption and wish to install it on your PIX Firewall, you must copy the system image to the flash
(again). During this process, you will be prompted for the activation code. The DES activation key
provides 56-bit DES, and the 3DES activation key provides 168-bit 3DES.
PIX Firewall Operation
Now that you understand the components of the PIX Firewall, let’s look at how they work
together. As we mentioned earlier, the PIX Firewall has its roots in NAT. In fact, when the PIX
Firewall was introduced in 1994, it was the first box capable of doing true RFC 1631 NAT.
Although it is possible to configure a PIX Firewall to not translate IP addresses, its switching
process is based on NAT, and every packet must use this NAT mechanism. So, to understand how
a PIX Firewall forwards packets, we must first define some NAT vocabulary. Then we will discuss
the sequence in which packets are processed, and finally, the Adaptive Security Algorithm.
PIX Firewall Operation
19
Even if the PIX Firewall filtering is configured so that its ACLs will not deny any
packets, packets that are not translated will not be forwarded. The PIX Firewall
must have a translation slot to switch packets from one interface to another.
NAT Mechanisms
With NAT, a translation is a pair of IP addresses: local and global. The local address is on the
network connected to the inside, or trusted, interface of the PIX Firewall. The global address is
part of a network somewhere beyond the outside interface that is trusted less than the inside
interface. The PIX Firewall translates the local address to the global address as the packet passes
outbound through the firewall. It translates the global address to the local address as a packet
passes inbound through the firewall.
Translations can be either static or dynamic. Static translations must be manually configured. Dynamic translations are created as packets that meet certain criteria arrive.
When the first packet in a series of packets arrives at the PIX Firewall from the inside interface, the PIX Firewall creates a translation slot. This “slot” is a software construct that keeps
track of translations. Each translation uses one translation slot.
Connection slots are another software construct that the PIX Firewall uses to keep track of
stateful information. A given pair of devices, such as a client and server, can multiplex several
conversations between their two IP addresses. This is often accomplished via TCP and UDP
ports. For instance, a client could connect to a server via telnet, FTP, and HTTP simultaneously,
creating three separate TCP connections between the two devices. If this happened across a PIX
Firewall, it would create a single translation slot and three connection slots. Each connection
slot is bound to a translation slot.
The Restricted licenses used in older PIX Firewall models limit the number of
connection slots to either 128 or 1,024. As of the time of this writing, “older”
means the PIX Classic and those whose model numbers end in zero, such as
PIX 520. The current models end in five, such as PIX 515, PIX 525, and PIX 535.
The translation table, which is usually abbreviated as xlate table, is the actual table in memory that holds all the translation slots and connection slots. It is important to distinguish this
table from the configuration file of the PIX Firewall. Just because you have configured a static
entry does not mean it will appear in the output of the show xlate command. The PIX Firewall
places an entry in this table only when a packet arrives. After a certain amount of inactivity (that
is, after the PIX Firewall does not see any more packets that are part of this conversation), the
PIX Firewall will remove the entry from the xlate table. Remember that the xlate table shows
the current translations and connections.
20
Chapter 1
PIX Firewall Basics
Packet Processing
Now that you know how NAT works, let’s look at how the PIX Firewall processes packets.
We’ll see how it handles outbound packets, inbound packets, and routing.
Outbound Packets
When a packet arrives on the inside interface, the PIX Firewall first checks the xlate table for a
translation slot. Specifically, this means the PIX Firewall is checking the source address of the
IP header and searching the xlate table for a match. Its next actions depend on whether or not
it finds a match.
Packets with Existing Translation Slots
If the PIX Firewall finds a match for the outbound packet’s source address, it knows it has seen
packets from this address before and already created a dynamic translation slot, or it has a manually configured static translation slot. The PIX Firewall then processes the outbound packet as
follows:
It takes the global address from the translation slot that corresponds to the local address it
just looked up in the xlate table and overwrites the source address in the IP header of the
packet with the value of the global address.
The other attributes, such as the checksums, are recalculated. (Otherwise, the packet would
be discarded upon arrival, since the change in the IP header would change the value of the
checksum.)
The packet is then forwarded out the outside interface.
Packets without Existing Translation Slots
If the PIX Firewall receives a packet on the inside interface that does not have a current translation slot in the xlate table, it can dynamically create an entry if configured to do so. In this
case, when the packet arrives, the PIX Firewall checks the source address and finds no match
in the xlate table. It then follows these steps to process the outbound packet:
The PIX Firewall makes sure it has sufficient connections, which are determined by the
license.
It creates the translation slot by reserving an unused IP address from the global NAT pool
and entering this global address along with the source address from the IP header into the
translation slot.
With the translation slot created, the source address is overwritten with the global address.
The checksum and other values are recalculated.
The packet is transmitted on the outside interface.
Inbound Packets
For packets that arrive on the outside interface, destined for the inside network, the PIX Firewall behaves quite differently than it does for packets that arrive on the inside interface. This
PIX Firewall Operation
21
is because the outside network is, by definition, less trusted. By default, packets from the outside
do not create translation slots, so they cannot be switched to the inside interface without a static
NAT mapping. This makes the PIX Firewall very secure, from an architectural standpoint.
But even before the PIX Firewall checks for an existing entry in the xlate table, packets from
an outside interface must match criteria specified in an ACL. Only after an incoming packet
matches the ACL will it be processed further. The combination of the ACL and translation slot
is the primary source of the PIX Firewall’s security.
Do not confuse the definition of stateful firewalls with this section’s description
of the operation of the PIX Firewall. There are many brands of stateful firewalls,
but the PIX Firewall’s operation is unique.
Routing
As you can see from the description of packet processing in the previous sections, the PIX Firewall is not a router. This is an important distinction, because many other brands of firewalls are,
in fact, routers, with packet-filtering or even stateful capabilities added on. For instance, the
Cisco IOS Firewall is a full-featured, stateful firewall that runs on a Cisco router, but it processes packets just as it would if it were running a basic Cisco IOS image, except that it adds the
stateful filtering feature. Although the mode of operation detailed in the previous sections
makes the PIX Firewall much more secure, it also has some limitations related to its routing protocol support. The configuring of routing will be discussed in the next chapter.
The Adaptive Security Algorithm (ASA) and
Security Levels
Cisco’s ASA is the basis for the PIX Firewall’s security, and it includes much of the information
discussed in the previous sections. However, it can be summarized into a few rules that govern
how packets are inspected and permitted or denied:
All packets must have a connection slot to be transmitted.
All packets are allowed to travel from a more secure interface to a less secure interface
unless specifically denied (for example, by an ACL).
All packets from a less secure interface to a more secure interface are denied, unless specifically allowed.
All ICMP packets are denied unless you specifically configure the PIX Firewall to accept them.
When the PIX Firewall denies a packet, it is “dropped” (received but not transmitted), and
the action is noted in the logs.
Monitor return packets to ensure they are valid.
Security on the PIX Firewall is relative, and it’s critical that you understand this. Specifically,
what is allowed and disallowed by default depends on which interfaces a packet enters and leaves.
22
Chapter 1
PIX Firewall Basics
Each interface is assigned a value, called the security level, from 0 to 100, where 100 is completely trusted and 0 is completely untrusted. This allows a PIX Firewall with several interfaces
to be configured securely.
For instance, you might have five interfaces on your PIX Firewall and assign them security
levels as follows:
Connection
Security Level
Default Access
Internal network
100
All
Remote-access network
75
Business partner, DMZ, and Internet
Business partner
50
DMZ and Internet
DMZ
25
Internet
Internet
0
None
In this scenario, traffic from your internal network would, by default, be able to access any
of the other four networks. Your remote users would be able to get to your business partner, the
DMZ, and the Internet; however, you must explicitly configure the PIX Firewall to let them
inside your internal network because it has a higher security level. Your business partners would
be able to access your shared systems on the DMZ and the Internet by default, although you
could restrict this with an ACL. Your partners would not be able to get to your internal network
or the modems on your remote-access network, unless you explicitly grant them permission in
the configuration. The systems on the DMZ would be able to access only the Internet. Finally, the
Internet would not be able to access any of the other four networks, again, without explicit configuration.
In summary, the PIX Firewall controls access via the translation and connection slots we
mentioned earlier. The PIX Firewall simply does not allow a packet from a less-trusted interface, destined for a more-trusted interface, to create a translation or connection slot, without
explicitly configuring the NAT translation and an ACL.
Working with the Firewall Services
Module (FWSM)
If you want more firewall horsepower you should consider using the Firewall Services Module
for the Catalyst 6500 Series switch and the 7600 Series Internet router with either a Supervisor
1A with MSFC2 (Catalyst operating system only) or Supervisor 2 with MSFC2. The FWSM is
based on Cisco PIX Firewall technology and uses the same time-tested Cisco PIX Firewall Operating System, a secure, real-time operating system.
This is a multigigabit firewall module with 1GB RAM and 128MB flash memory that provides up to 5Gbps of throughput. This module is switch fabric–aware and runs the entire
Working with the Firewall Services Module (FWSM)
23
PIX 6.0 software feature set and some PIX 6.2 features including command authorization,
object grouping, and URL-filtering enhancements. This module supports up to 100 virtual
LANs (VLANs) with no physical interfaces.
There are some caveats to using the FWSM over a stand-alone PIX Firewall. There is no support for IDS signatures, the PIX Firewall Manager, the Cisco Secure Policy Manager, conduit
commands, the Dynamic Host Configuration Protocol (DHCP) client, and VPN except for
IPSec for management purposes. If you need more than 5Gbps of throughput, then you can
install up to four modules per chassis for a total of 20Gbps. There is, however, support for the
Open Shortest Path First (OSPF) routing protocol, something that will not be available until version 6.3 of the PIX Firewall operating system. We will not discuss the OSPF support in this book
because it is beyond the scope of the current test.
In this section, we will have a configuration overview followed by how to configure the
switch for the FWSM using both IOS and CatOS-based switches. Next we will show you how
to connect to the module and what tasks need to be completed for the FWSM to start protecting
the secured VLANs.
Overview of Configuration
The FWSM can provide access control to the whole inside network, or it can segregate multiple
security zones through VLAN interfaces of different security levels. These VLAN interfaces are
known as secure VLANs because they are handled by the FWSM and not by the supervisor
engine. There is one secure VLAN known as the secure VLAN interface (SVI), and it provides
a layer 3 secure VLAN interface between the module and the router on the supervisor engine so
they can communicate with each other.
One SVI must be configured between each FWSM in the chassis and the supervisor engine
module router. Only one SVI can exist between a given FWSM and the router on the supervisor
engine. There can be multiple SVIs in a device but only one can exist between each FWSM and
the supervisor engine.
You can configure secure VLANs using both the Cisco IOS and CatOS operating systems.
The secure VLAN information is passed from the switch operating system software to the firewall module when it comes on line. The module accepts traffic on the secure VLANs only after
the firewall interfaces are configured on the module corresponding to the secure VLANs defined
on the switch. The firewall software will not see traffic on VLANs that are unknown to the firewall module or on the secure VLANs without having corresponding firewall interfaces defined.
When the firewall module comes on line, the Network Management Processor (NMP) sends
a message that specifies the secure VLANs that are defined for that particular firewall module.
If a VLAN is active and is configured as a secure VLAN, the information about the new active
VLAN is sent to the corresponding FWSM.
The FWSM configuration has the following characteristics:
Each firewall interface is a layer 3 interface and has an IP address.
Each firewall interface has a fixed VLAN, which is defined on the switch.
The switch MSFC is used as a router for only the SVI so the devices can communicate.
24
Chapter 1
PIX Firewall Basics
The module views all networks attached to an interface as having the same security level.
Traffic from non-firewall VLANs is routed through the MSFC without being processed by
the FWSM.
Configuring an IOS Switch
To set up the configuration for the FWSM on the switch using the Cisco IOS CLI, follow these steps:
1.
Create the VLANs to be used by the module using the vlan number command.
2.
Define an SVI on the MSFC using the interface vlan number command or you will be
unable to configure VLANs on the module.
3.
Create a firewall group of secure VLANs using the firewall vlan-group firewallgroup vlan-range command.
4.
Attach the VLAN and firewall group to the slot where the FWSM is located using the
firewall module module number vlan-group firewall-group command.
You can also view the defined VLAN groups and the module(s) using the show firewall
vlan-group and show firewall module commands. The following in an example of using the
above commands to create secure VLANs and the SVI, and tying the VLANs to the slot for
the FWSM:
MSFC# conf t
Enter configuration commands, one per line. End with CNTL/Z.
MSFC(config)# vlan 15
MSFC(config-vlan)# vlan 16
MSFC(config-vlan)# vlan 17
MSFC(config-vlan)# exit
MSFC(config)# firewall vlan-group 10 15-17
MSFC(config)# firewall vlan-group 21 30-45
MSFC(config)# firewall module 8 vlan-group 10,21
MSFC(config)# int vlan 55
MSFC(config-if)# ip address 192.168.1.1 255.255.255.0
MSFC(config-if)# no shut
MSFC(config-if)# end
MSFC# show firewall vlan-group
Group vlans
----- -----10
15-17
21
30-45
MSFC# show firewall module
Module Vlan-groups
8
10,21,
MSFC#
Working with the Firewall Services Module (FWSM)
25
You can also see the SVI interface using the show interface vlan number command, as
you can see from the output below:
MSFC# show int vlan 15
Vlan15 is up, line protocol is up
Hardware is EtherSVI, address is 000A.2ed0.8c54 (bia 000A.2ed0.8c54)
Internet address is 192.168.1.1/24
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
ARP type:ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:08, output hang never
Last clearing of "show interface" counters never
Input queue:0/75/0/0 (size/max/drops/flushes); Total output drops:0
Queueing strategy:fifo
Output queue :0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
L2 Switched:ucast:196 pkt, 13328 bytes - mcast:4 pkt, 256 bytes
L3 in Switched:ucast:0 pkt, 0 bytes - mcast:0 pkt, 0 bytes mcast
L3 out Switched:ucast:0 pkt, 0 bytes
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
4 packets output, 256 bytes, 0 underruns
0 output errors, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
Router#
To prevent trunks from carrying secure VLANs, you should remove those
VLANs from any trunk connection using the switchport trunk allowed vlan
remov vlan-list command.
Configuring a CatOS switch
To set up the configuration on the switch for the FWSM using the Catalyst operating system
CLI, you must be in the proper Virtual Terminal Protocol (VTP) mode to create VLANs (Server,
Transparent, or Off modes all work), and then follow these steps:
1.
Specify firewall VLANs and maps them to the module using the set vlan vlan-list
firewall-vlan module command.
2.
Set the VLAN SVI using the set vlan vlan-number command.
26
Chapter 1
PIX Firewall Basics
To display the range of VLANs specified for the FWSM, use the show vlan firewall-vlan
module-number command. The following in an example of using the above commands to create secure VLANs while tying those to the slot for the FWSM and setting the SVI:
Console>(enable)
Console>(enable)
Console>(enable)
Secured vlans by
17, 21-25, 29-30
Console>(enable)
set vlan 17, 21-25, 29-30 firewall-vlan 8
set vlan 19
show vlan firewall-vlan 8
firewall module 8:
Connecting to the Module
You might be asking yourself how do I get to the module to configure it after I have set up the
secure VLANs on the switch? For an IOS-based switch, the command is session slot number
processor 1. The following is an example of connecting to the FWSM in slot 8:
MSFC# session slot 8 processor 1
The default escape character is Ctrl-^, then x. You can also type ‘exit’ at the
remote prompt to end the session
Trying 127.0.0.81 … Open
FWSM passwd:
Welcome to the FWSM firewall
Type help or '?' for a list of available commands.
FWSM>
If you are using the CatOS, you need to use the session module command to connect to
the FWSM in the specified module. The following is an example of connecting to the FWSM
in slot 8:
Console> session 8
The default escape character is Ctrl-^, then x. you can also type ‘exit’ at the
remote prompt to end the session
Trying 127.0.0.81 … Open
FWSM passwd:
Welcome to the FWSM firewall
Working with the Firewall Services Module (FWSM)
27
Type help or '?' for a list of available commands.
FWSM>
If the module does not boot into the application partition, you might need to reset the module with the hw-module module slot-number reset cf:4 command for Cisco IOS and
reset module-number for the CatOS-based switch.
Configuring the FWSM
The configuration of the module is the same if you are using the Cisco IOS or the CatOS-based
switch. Plus, with a few exceptions, the configuration of the FWSM is basically the same as the
stand-alone PIX Firewall. Each interface needs to be defined before it can be used for traffic
using a command slightly modified for the FWSM. That command is nameif vlan-number
if-name security-level, where the vlan-number is in place of the physical-interface
parameter.
To allow traffic to flow from one interface to another, you must explicitly define
an access list and map that access list to the appropriate interface. Unlike the
PIX firewall, traffic from high-security-level interfaces is not allowed to flow
freely to an interface with a lower security level. By default, access lists are
defined as deny any.
The following is an example that shows how to configure the module:
FWSM(config)# nameif 15 inside 100
FWSM(config)# nameif 16 outside 0
FWSM(config)# ip address inside 10.1.1.1 255.255.255.0
FWSM(config)# ip address outside 192.168.1.2 255.255.255.0
FWSM(config)# access-list 1 permit ip any any
FWSM(config)# access-group 1 in interface inside
FWSM(config)# show nameif
nameif vlan15 inside security100
nameif vlan16 outside security0
FWSM(config)# show ip
System IP Addresses:
ip address inside 10.1.1.1 255.255.255.0
ip address outside 192.168.1.2 255.255.255.0
ip address eobc 127.0.0.61 255.255.255.0
Current IP Addresses:
ip address inside 10.1.1.1 255.255.255.0
ip address outside 192.168.1.2 255.255.255.0
28
Chapter 1
PIX Firewall Basics
ip address eobc 127.0.0.61 255.255.255.0
FWSM(config)# show access-list
access-list 1; 1 elements
access-list 1 permit ip any any (hitcnt=0)
FWSM(config)# show access-group
access-group 1 in interface inside
FWSM(config)#
Using the PIX Firewall CLI
Now that you know what the PIX Firewall is and how it works, it’s time to get some hands-on
experience with it. In this section, we will discuss the various modes of the CLI, as well as several
basic commands. This chapter concentrates on the system and management commands and
general navigation between the CLI modes. The bulk of the network and security configuration
commands will be discussed in detail in later chapters.
CLI Access Methods
There are a number of ways to access the PIX Firewall’s CLI. The most common method is via
the console. This is a standard EIA/TIA-232 serial interface that uses a RJ-45 connector and a
rolled cable. Typically, the console is connected to the COM port on a PC and accessed via a
terminal emulator, such as HyperTerminal or TeraTerm.
Another way to access the CLI is via a telnet session. However, this option comes with some
major caveats. The telnet protocol itself is almost totally insecure. Although a password is
required, it is transmitted in plain text across the network. For this and other reasons, it is possible to telnet to a PIX Firewall from any interface, but sessions connecting to the PIX Firewall
from the outside network must be inside an IPSec tunnel (Part II, “Cisco Secure Virtual Private
Networks,” covers IPSec tunnels).
The preferred method of remotely accessing a PIX Firewall is using the Secure Shell Protocol, often abbreviated SSH. This method is similar to telnet, but it provides data privacy via
encryption.
The actual configuration of these access methods will be discussed in the next chapter. Here,
we will continue by explaining what happens once you access and log on to the PIX Firewall.
CLI Modes
The PIX Firewall uses basic modes similar to the Cisco IOS–based routers: Monitor mode, User
mode (called Unprivileged mode), Privileged mode, and Configuration mode.
Using the PIX Firewall CLI
29
Monitor Mode
Monitor mode is used when you need to upgrade the software on a PIX Firewall that does not
have an internal floppy drive. All of the new PIX Firewalls do not have internal floppy drives.
You get into Monitor mode during the bootup sequence, when you’re prompted to use either
BREAK or Esc to interrupt the Flash boot. You have 10 seconds to interrupt the normal boot
process. You then press the Esc key or send a BREAK character, which will put you in Monitor
mode. The monitor> prompt is then displayed. This mode is sometimes overlooked in the Cisco
documentation.
Unprivileged Mode
After the initial logon, you’re in Unprivileged mode. This is a highly restricted mode that, by
default, has only a few commands including enable, pager, and quit. The prompt in Unprivileged mode is marked by the greater-than symbol (>) after the system name.
Privileged Mode
To gain access to view and configure the PIX Firewall, you must type the command enable
from the Unprivileged mode prompt. You will then be prompted for the enable password. After
successfully entering this password, you will be in Privileged mode. This mode is marked by the
pound symbol (#) after the system name.
The mode sequence looks like this:
PIX> ?
enable
Enter privileged mode or change privileged
mode password
Control page length for pagination
Disable, end configuration or logout
pager
quit
PIX> enable
Password: *****
PIX#
From the Privileged mode, you can manage the flash, view the configuration, use the show
commands, view the logs, and enter any Unprivileged mode command. The command disable
returns to Unprivileged mode from Privileged mode.
Configuration Mode
To enter Configuration mode on the PIX Firewall, type the configure terminal command.
After entering this command, the prompt will change to include the word config, indicating
that you’re in the Configuration mode. While in this mode, you can modify the current running
configuration in the PIX Firewall’s memory. You can also enter any Unprivileged and Privileged
command while in Configuration mode. So if you wanted to view the configuration while in
30
Chapter 1
PIX Firewall Basics
Configuration mode just enter the write terminal command to view the current configuration in RAM. This is a different behavior from Cisco IOS where you must exit the configuration
mode to enter Unprivileged or Privileged commands. Any command you type will take effect
immediately but still needs to be saved to flash memory, making the changes permanent. You
can return to Privileged mode by typing the command exit.
Editing in the CLI
The PIX Firewall’s CLI uses the same editing conventions as the Cisco IOS router software.
These conventions are special Ctrl-key combinations or arrow keys that allow you to move the
cursor to different places. Table 1.1 lists the key combinations commonly used when editing the
PIX Firewall’s configuration.
TABLE 1.1
PIX Firewall CLI Editing Keys
Key
Function
Ctrl+P or up arrow
Displays the previously accepted commands. This is handy when you
need to enter several similar commands or the same command several
times in a row.
Ctrl+N or down
arrow
Displays the next accepted command. Note that if you make a syntax error
and a command is not accepted, it will not be displayed in the history.
Ctrl+W
Deletes the word to the left of the cursor.
Ctrl+U
Deletes the entire line.
Basic Commands
This section presents some of the basic Privileged mode commands. Other commands will be
covered in other chapters when we discuss their respective technologies. These commands are
used most often when configuring the PIX Firewall and are organized here alphabetically.
The clear Command
The clear command resets counters or caches held in the PIX Firewall’s memory. This is useful
during troubleshooting. You might want to clear the interface statistics, the ARP table, or the
xlate table. You can also use this command to clear the PIX Firewall’s configuration and clear
the contents of the flash before installing a new image. The following is an example of the
options available when running version 6.2 of the PIX Firewall operating system:
PIX# clear ?
arp
Change or view the arp table, and set the arp timeout value
Using the PIX Firewall CLI
blocks
capture
flashfs
local-host
logging
pager
passwd
shun
tcpstat
traffic
uauth
xlate
PIX# clear
31
Show system buffer utilization
Capture inbound and outbound packets on one or more interfaces
Show, destroy, or preserve filesystem information
Display or clear the local host network information
Clear syslog entries from the internal buffer
Control page length for pagination
Change Telnet console access password
Manages the filtering of packets from undesired hosts
Display status of tcp stack and tcp connections
Counters for traffic statistics
Display or clear current user authorization information
Display current translation and connection slot information
The clock set Command
PIX Firewalls use an internal clock, similar to that on PCs, for a number of purposes. The two primary uses are for generating timestamps on the SYSLOGs and as part of the Public Key Infrastructure (PKI) Protocol, to make sure that certificates and other security constructs are removed as they
expire. Thus, it is important to set your clock correctly. To do this, use the clock set command.
The syntax is as follows:
clock set hh:mm:ss month day year
The copy Command
The copy command is used to copy an image or PDM file from a TFTP server onto the flash.
This command uses the URL syntax, as follows:
copy tftp[:[[//location][/path]]] flash[:[image | pdm]]
After this command is executed, the PIX Firewall will prompt you for the IP address of the
TFTP server and the source filename that you want to copy.
Unlike the copy TFTP operation on Cisco routers using IOS, when upgrading
from 5.x to 6.x images, the PIX Firewall does not warn you about erasing all
files on the flash, or ask you over and over if you really, really want to copy the
file. It just does it. Fortunately, once it has finished verifying that the copy was
successful, you have the option of not installing the new image.
The debug Commands
The debug commands provide detailed, real-time information about events on the PIX Firewall.
These include information about packets traversing the firewall, special services such as DHCP
32
Chapter 1
PIX Firewall Basics
and failover, the crypto processes of IPSec and ISAKMP (Internet Security Association and Key
Management Protocol), and more. Here is an example of the debug output for the RIP routing
process:
PIX# debug rip
RIP trace on
PIX# 226: RIP: interface outside received v1 update
from 10.2.0.6
227: RIP: interface outside received v2 update
from 10.2.0.5
228: RIP: update contains 4 routes
229: RIP: interface inside sending v1 update
to 255.255.255.255
230: RIP: interface outside received v2 update
from 10.2.0.5
231: RIP: update contains 4 routes
Most debug operations will use the command debug, followed by a keyword, such as rip,
as in the above example. However, the packet-debugging feature is much more powerful, and
the syntax is correspondingly complex:
PIX# debug packet ?
usage: [no] debug packet ifname
[src sip [netmask <smask>]]
[dst dip [netmask <dmask>]]
[proto
icmp |
tcp [sport <sport>] [dport <dport>] |
udp [sport <sport>] [dport <dport>] ]
[rx|tx|both]
PIX# debug packet
As you can see, this feature allows you to explicitly define the types of packets you want to
view. This is useful for verifying that your filters are operating as you intended.
The enable Command
The enable command controls access to Privileged mode. Usually the command will be used
without any additional parameters but there is an optional privilege level parameter that can be
used. The following is the enable command syntax:
enable [priv-level]
Using the PIX Firewall CLI
33
By default the enable command asks for the level 15 enable password but you can specify the
privilege level from 0 to 15. We will talk about how these privilege levels are used when we talk
about the privilege command in Chapter 3, “ACLs, Filtering, Object Grouping, and AAA.”
Now let’s talk about how to configure the enable password for each level.
The enable password Command
The enable password command is used to set the password that allows access to the Privileged
mode. The password is alphanumeric and can be at least three characters and up to 16 characters long. Optionally there is a level parameter followed by the privilege level, which creates a
password for that particular privilege level. The syntax is as follows:
enable password password [level priv-level] [encrypted]
If you are entering a password that is already encrypted, you must use the encrypted keyword after your password. Also, an encrypted string will always be exactly 16 characters long
(so you cannot tell how long the unencrypted password is).
The passwd Command
The passwd command sets the password for telnet and SSH access to the PIX Firewall. Telnet
and SSH will be discussed in the next chapter. The syntax is as follows:
passwd password [encrypted]
The encrypted keyword works just like the enable password command.
The perfmon Command
The perfmon command provides a convenient interface for accessing a number of statistics all
at once. This command has three parts:
PIX# perfmon ?
Usage: perfmon interval seconds
perfmon quiet | verbose
perfmon settings
PIX# perfmon
The first command tells the PIX Firewall how often to report the statistics. The second command turns reporting on and off. The last command shows the current settings. Here is an
example of these commands and the perfmon report:
PIX# perfmon
PIX# perfmon
PIX# perfmon
interval: 10
verbose
PIX#
interval 10
verbose
settings
(seconds)
34
Chapter 1
PERFMON STATS:
Xlates
Connections
TCP Conns
UDP Conns
URL Access
WebSns Req
TCP Fixup
TCPIntercept
HTTP Fixup
FTP Fixup
AAA Authen
AAA Author
AAA Account
PIX#
PIX Firewall Basics
Current
0/s
0/s
0/s
0/s
0/s
0/s
0/s
0/s
0/s
0/s
0/s
0/s
0/s
Average
0/s
0/s
0/s
0/s
0/s
0/s
0/s
0/s
0/s
0/s
0/s
0/s
0/s
The reload Command
The reload command reboots the PIX Firewall after prompting you to confirm that you would
like the PIX Firewall to reboot itself. Optionally, you can use the keyword noconfirm to bypass
confirmation. The syntax is as follows:
reload [noconfirm]
The show checksum Command
To ensure the integrity of the configuration, the PIX Firewall calculates a cryptographic checksum of the configuration. The show checksum command has no optional parameters and displays the checksum as a series of four 4-byte numbers in hexadecimal format. As part of your
security procedures, after the PIX Firewall is initially configured, you should use the show
checksum command and record the checksum. You can then use this as part of your audits, to
verify that no one has tampered with the configuration. Here is an example of the output of the
show checksum command:
PIX# show checksum
Cryptochecksum: eb30f570 92b0f5e6 e29ee8dc 5f0aa42a
PIX#
The show interface Command
The show interface command is used often because it provides a great deal of information
about the interfaces on the PIX Firewall. The syntax is as follows:
show interface [hardware_address]
Using the PIX Firewall CLI
35
If the optional hardware address is given, the output is limited to information about the
address specified; otherwise, information is displayed about all interfaces.
The show interface command is most often used to verify that the interface is “up/up,”
which refers to the hardware and the line protocol—in this case, Ethernet. In other words, it
checks layers 1 and 2 of the OSI model, respectively. The show interface command is also
used to show the IP address and the activity on the interface, including packet and byte counts
for inbound and outbound traffic, and error statistics. The following shows sample output of
this command.
PIX# show interface ethernet0
interface ethernet0 "outside" is up, line protocol is up
Hardware is i82559 ethernet, address is 0050.54ff.076d
IP address 10.2.0.20, subnet mask 255.255.255.0
MTU 1500 bytes, BW 100000 Kbit full duplex
6063 packets input, 608203 bytes, 0 no buffer
Received 1684 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun,
0 ignored, 0 abort
45 packets output, 3530 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collisions, 0 deferred
0 lost carrier, 0 no carrier
input queue (curr/max blocks): hardware (128/128)
software (0/1)
output queue (curr/max blocks): hardware (0/1)
software (0/1)
PIX#
The show tech-support Command
The show tech-support command has no optional parameters and is often used at the request
of Cisco’s Technical Assistance Center (TAC). It is a convenient way to dump the output of several show commands to the screen, so you can cut and paste the output into an e-mail message
and forward it to the TAC to help them troubleshoot a problem.
The shun Command
The shun command allows an administrator to quickly respond to an incident by deleting the
connection information of a given source address, and rejecting any future packets from that
source, without changing the configuration rules of the PIX Firewall. Because the configuration
of ACLs and conduits can become quite complex, the shun command can save a great deal of
time, which is often critical during an attack. We will go into more detail about the shun command in Chapter 4, “Advanced Protocol Handling, Attack Guards, and Intrusion Detection.”
36
Chapter 1
PIX Firewall Basics
The syntax of the shun command is as follows:
PIX# shun ?
Usage: shun src_ip [dst_ip sport dport [prot]]
no shun src_ip
show shun [src_ip|statistics]
clear shun [statistics]
PIX# shun
The who Command
The who command shows the TTY ID and IP address of each active telnet session on the PIX
Firewall. The TTY ID is important because this ID is used with the kill command to terminate
active telnet connections. You can provide an optional IP address parameter to display all sessions from that IP address. The following is an example of the command syntax:
PIX# who ?
Usage: who ip
PIX# who
The write Command
The write command can be used to copy the current configuration to a number of different
locations, as follows:
To copy the current configuration to flash:
write memory
To display the current configuration on the terminal:
write terminal
To copy the current configuration to a TFTP server:
write network [[server_ip]:[filename]]
To copy the current configuration to a floppy disk, if one is available:
write floppy
To copy the current configuration to the failover standby server:
write standy
You can also erase the configuration on the flash by using the following command:
write erase
Exam Essentials
37
The commands we covered in this section will get you started configuring your PIX Firewall.
You will refer back to this section often because PIX Firewall administrators use these commands almost daily.
Summary
This chapter began by defining the term firewall and explaining that the role of a firewall is to
protect the network at the perimeter from outside attacks. We then looked at the three common
firewall technologies in use today:
Packet-filtering firewalls use rules to deny packets based on the content of the headers.
Application proxies are layer 7–aware programs that communicate with systems on
untrusted networks on behalf of hosts in the trusted network.
Stateful firewalls permit or deny packets based on other packets, typically on a session
basis.
Next, we focused on the PIX Firewall where we examined the unique hardware and software
components in a PIX Firewall and how they operate together to provide a formidable security
solution. We then introduced the Firewall Service Module (FWSM), which runs the PIX Firewall operating system, and how to set up the module to work with both Cisco IOS and CatOSbased switches.
Finally, we covered the PIX Firewall CLI (command-line interface) and the common commands used in the day-to-day operation and management of the PIX Firewall.
Now that you have a basic understanding of firewalls, and the operation of the PIX Firewall
specifically, this knowledge will provide a foundation for the advanced topics in later chapters.
Exam Essentials
Know what the PIX Firewall protects against and what it doesn’t protect against. Understand the concept of a network’s perimeter. Understand the types of attacks and which ones can
be detected and defeated by firewalls.
Understand the difference between translation slots, connection slots, and the xlate table.
Be able to describe the purpose of each of these components. Know when they are created and
where they exist.
Know how to describe a modern screened subnet, or DMZ. Understand why DMZs exist
and their advantages and disadvantages. Be able to describe the flow of information in and out
of a DMZ.
38
Chapter 1
PIX Firewall Basics
Remember the differences between the various firewall technologies. Describe the operation
of application proxies, packet filters, and stateful firewalls. Identify the advantages and disadvantages of each type.
Understand the FWSM You need to be able to describe the features of the FWSM, the differences it has from a stand-alone PIX Firewall, and the commands to configure the module for
both Cisco IOS– and CatOS-based switches.
Know the different modes of the CLI. Distinguish between the User mode, Privileged mode,
and Configuration mode on the PIX Firewall operating system CLI. Know how to get to each
mode and what passwords are required.
Know how to use the show commands. Describe the output of common show commands.
Know which command is the most appropriate for displaying various types of information.
Key Terms
Before you take the exam, be certain you are familiar with the following terms:
application proxies
packet-filtering firewalls
connection slots
proxy servers
defense in depth
screened subnet
DMZ
secure VLAN interface
firewall
stateful firewalls
inside interface
translation slot
Network Management Processor
xlate table
outside interface
Review Questions
39
Review Questions
1.
You configure a PIX Firewall to block all traffic except HTTP. Later, you decide to test the firewall by telneting into an internal server from the outside network. To your surprise, the telnet
is successful! Which of the following could not be an explanation for this?
A. There is an alternative path into the network, bypassing the PIX Firewall.
B. You have misconfigured the PIX Firewall.
C. Since you are the administrator, the PIX Firewall permitted your telnet session.
D. The configuration of the PIX Firewall has been changed since you last configured it.
2.
You configure two static NAT translations on a PIX Firewall. How many translation slots and
connection slots will this generate in the xlate table?
A. 2 translation slots, 2 connection slots
B. 2 translation slots, 0 connection slots
C. 0 translation slots, 2 connection slots
D. 0 translation slots, 0 connection slots
3.
You have two workstations on the inside network and a server on the outside network of a PIX
Firewall. You open a Web browser on each of the workstations and point it to the server. You
also telnet from one workstation to the server. How many connection slots and translation slots
are in the xlate table of the PIX Firewall?
A. 2 translation slots, 3 connection slots
B. 3 translation slots, 2 connection slots
C. 1 translation slot, 5 connection slots
D. 1 translation slot, 6 connection slots
4.
Users have started complaining about slow network response on traffic that flows across a PIX
Firewall that you administer. Which command would you use to quickly gather performance
statistics on the firewall?
A. show performance
B. show CPU
C. perfmon
D. statistics
5.
How many Firewall Service Modules do you need to install in the 7600 Series router if you need
to have 12Gbps of firewall throughput?
A. One
B. Three
C. Five
D. Two
40
6.
Chapter 1
PIX Firewall Basics
You want to allow telnet access to a server but prevent users from issuing commands that delete
files. Which type of firewall would be the most appropriate?
A. Packet filtering
B. Application proxy
C. Stateful inspection
D. Class III
7.
You have been asked to design a network where performance is the foremost priority. Which
type of firewall would you employ?
A. Packet filtering
B. Application proxy
C. Stateful inspection
D. Class III
8.
Which of the following commands will display the statistics of a single interface?
A. show interface
B. show interface outside
C. show interface 1
D. show interface ethernet1
9.
On the PIX 535, in which slots can the VPN accelerator (PIX-VPN-ACCEL) and four-port
Ethernet (PIX-4FE) card be placed? (Choose all that apply.)
A. 32-bit/66Mhz
B. 32-bit/32Mhz
C. 64-bit/33Mhz
D. 64-bit-66Mhz
10. How many interfaces are available on the PIX 501 Firewall?
A. One 10BaseT port and a four-port 100BaseTX switch
B. Two 10BaseT ports
C. Three 100BaseTX ports
D. Six 100BaseTX ports
Answers to Review Questions
41
Answers to Review Questions
1.
C. The PIX Firewall will not automatically change its rules to accommodate administrators, especially since it has no way to determine or verify which traffic is from an administrator.
2.
D. The xlate table holds only active entries. The PIX Firewall must first see a packet matching
the configuration before it puts an entry into the xlate table. Configuring a static mapping does
not automatically use a slot in the table.
3.
A. One translation slot is generated from each workstation, and one connection slot is generated
for each socket.
4.
C. The perfmon command shows many statistics. The show performance and statistics
commands do not exist. The show CPU command shows only the utilization of the CPU.
5.
B. Each FWSM provides 5Gbps throughput, you will need to have three FWSM installed in the
chassis. You can have only four modules per chassis, so answer C is not supported.
6.
B. Application proxies are the only firewalls that operate at the Application layer.
7.
A. Packet-filtering firewalls need only to view the packet headers and match them against predetermined rules. Application proxies must inspect the payload as well. Stateful firewalls make
more complicated decisions (even though the configuration is less complicated). There is no such
thing as a Class III firewall.
8.
D. The proper syntax of this command uses the hardware address, not the name.
9.
B. These cards can be placed only in 32bit/33Mhz slots on the PIX 535 or the system will hang
on bootup.
10. A. The PIX 501 Firewall has one 10BaseT port for connection to the external network and a
four-port 100BaseTX switch for connection to the inside network.
Chapter
2
PIX Firewall
Configuration
THE FOLLOWING TOPICS ARE COVERED IN
THIS CHAPTER:
Understanding the CLI and using some general commands
How to configure the DHCP server
An overview of Network Address Translation (NAT)
An overview of Port Address Translation (PAT)
How to configure Remote Access to the PIX Firewall
Understand how to configure static, dynamic, and
multicast routing
In this chapter, we will discuss the configuration of the PIX Firewall. We’ll begin by discussing the preparatory work you should
complete before you configure a PIX Firewall, which includes
configuration of the hostname, remote access, and logging facilities. Then you will learn how
to set up a PIX Firewall to allow the traffic of your choice to pass between the inside, outside,
and DMZ interfaces. This includes the configuration of interfaces, NAT, and PAT. This chapter
also covers how to configure a PIX Firewall to participate in Routing Information Protocol
(RIP) domains and forward multicast traffic to downstream hosts that need it using Stub Multicast Routing (SMR).
Preparing for Firewall Configuration
To configure the PIX Firewall, you must answer the following questions at a minimum:
What am I trying to protect?
What am I trying to protect it from?
How many networks will be connected and what are their addresses?
Which of these networks do I trust most?
Which of these networks do I trust least?
Are there any other paths to get from one network to another?
What routing protocols are involved and how are they configured?
Will address translation be required?
If so, how many addresses need to be translated, and how many addresses are available to
translate them?
What are my application requirements?
Which applications will pass through the firewall, and on which interfaces will they arrive
and depart?
What protocol and/or port number will they use?
Who are the users of each application?
What are the source and destination IP addresses?
What are my organization’s security policies?
Using Common Global Configuration Commands
45
The answers to these questions will determine much of the configuration. As we go through
the configuration procedures in the rest of this chapter, we will point out where the answers to
these questions are used.
Cisco has provided a PDF file from Appendix A of the PIX Firewall and VPN
Configuration Guide for PIX Firewall version 6.2 with tables so you can enter
most of this information at URL http://www.cisco.com/univercd/cc/td/doc/
product/iaabu/pix/pix_62/config/cfgforms.pdf.
Using Common Global Configuration
Commands
Before we delve into the important aspects of configuring the PIX Firewall, let’s take a brief look
at several commands that are largely optional:
telnet
ssh
clock
ntp
domain-name
hostnames
name/names
dhcpd
logging
Each of these commands plays a part in making the PIX Firewall more secure or more userfriendly, and they affect the PIX Firewall as a whole, rather than any one particular interface or rule.
The Remote Access Commands
By default there is no remote access to the PIX Firewall, but the firewall can be configured to
allow telnet, SSH, and HTTP remote console access. We will discuss the telnet and SSH commands here, but the HTTP console access will be discussed in Chapter 5, “Firewall Failover and
PDM,” when we talk about the Cisco PIX Device Manager (PDM).
The telnet Command
The telnet command is used to configure telnet access to the PIX Firewall console. If you enter
just an IP address, the firewall will add that IP address to each internal interface. Optionally you
46
Chapter 2
PIX Firewall Configuration
can specify a network mask and interface name. If a mask is used, then the firewall will add the
IP address and mask to each internal interface. If an interface is specified, then the firewall will
add the IP address and mask to the specified interface only. If you want to allow telnet access
from any host, then use 0 0 as the IP address and mask.
Here is an example of using the telnet command with the irrelevant portions omitted:
PIX(config)# telnet 0 0
PIX(config)# telnet 160.109.12.2 255.255.255.255 outside
PIX(config)# wr t
Building configuration...
: Saved
:
PIX Version 6.2(2)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 dmz security99
hostname PIX
telnet 160.109.12.2 255.255.255.255 outside
telnet 0.0.0.0 0.0.0.0 inside
telnet 0.0.0.0 0.0.0.0 dmz
telnet timeout 5
PIX(config)#
As you can see from the output, the single telnet 0 0 command produced two telnet commands in the configuration file. This is because it added the IP address and mask to all internal
interfaces, which are inside and dmz. You can also see that there is a telnet timeout command with the value of 5 in the configuration. The default telnet idle timeout is five minutes,
which can be changed from one to 60 minutes with the telnet timeout command.
You might be wondering why the PIX Firewall would allow telnet access to the outside interface, which doesn’t sound very secure. The PIX Firewall will allow direct telnet console access
to the outside interface only if the telnet traffic is IPSec-protected. Therefore, to enable a telnet
session to the outside interface, configure IPSec on the outside interface, include IP traffic generated by the PIX Firewall in the access list, then enable telnet on the outside interface.
The ssh Command
Secure Shell (SSH) is a more secure access method than telnet and it is configured just as it would
be with telnet but with the ssh command. The PIX Firewall supports SSH version 1, which provides strong authentication and traffic encryption capabilities. It has the exact same parameter
structure and default values as telnet, so we will not go over it again.
There are a couple of differences between telnet and SSH. The first is that, with SSH, you can
directly access the PIX Firewall console on the outside interface without using IPSec. Since SSH
is more secure than telnet, the PIX Firewall will allow direct access on the outside interface without the need to encapsulate the traffic in an IPSec tunnel.
Using Common Global Configuration Commands
47
The second difference is that, with SSH, you need to issue more commands to set up RSA
encryption keys. To issue RSA keys, you need to set up a domain name—which is discussed later
in this chapter—with the domain-name and hostname commands plus the ca generate rsa
key and ca save all commands. For the ca generate rsa key command the options are
512, 768, 1024, or 2048, which is the modulus value. The ca save all command is used to
permanently save the public keys to flash memory.
Here is an example of how to set up your RSA keys to enable SSH console access to the PIX
Firewall:
pixfirewall(config)# hostname PIX
PIX(config)# domain-name sybex.com
PIX(config)# ca generate rsa key 1024
For <key_modulus_size> >= 1024, key generation could
take up to several minutes. Please wait.
PIX(config)# ca save all
PIX(config)#
If you have not configured AAA, which will be discussed in the next chapter, then to gain
access to the PIX Firewall console via SSH, at the SSH client, enter the username as pix and
enter the telnet password. You can set the telnet password using the passwd command, discussed in Chapter 1, “PIX Firewall Basics,” with the default telnet password being cisco.
The clock Command
The clock command is used to set the system clock, time zone, and summer time information.
Before version 6.2 of the PIX Firewall operating system, the syntax was too simple. The PIX
Firewall’s clock was not aware of daylight saving time (DST). Thus, it didn’t automatically
switch twice per year and didn’t support time zones. This has been thankfully corrected because
both of these problems can cause headaches for those using the logging timestamp feature.
All log entries are coded with the actual time, as opposed to the number of seconds elapsed since
the last reboot, so you could be in for some head-scratching date math.
To set the time and clock on the PIX Firewall, use the clock set command followed by the
time in the format hh:mm:ss, where hh is a 24-hour clock. You can optionally specify the
month day year or day month year. The new clock command options allow you to set the
time zone and when summer time starts and ends for DST. To configure the time zone, use the
clock timezone command followed by the zone-name and hour-offset values. If you live in
a time zone with half-hour offsets, you can optionally specify minutes after the hour value.
Here is an example of setting the time zone for central daylight time (CDT):
PIX(config)# set timezone CDT -6
PIX(config)#
To ensure the time will be adjusted for daylight saving, you must specify when the summer
time occurs. This is done using the clock summer-time command. You need to specify the
48
Chapter 2
PIX Firewall Configuration
zone-name then the keyword recurring. The following is an example of setting the summer
time for the central time zone:
PIX(config)# set summer-time CDT recurring
PIX(config)#
To ensure that you have configured the clock settings correctly, you can use the show clock
command with the optional detail parameter. Here is the output from these commands:
PIX(config)# sho clock
15:19:45.530 CDT Mon Apr 28 2003
PIX(config)# sho clock detail
15:19:48.760 CDT Mon Apr 28 2003
Time source is NTP
Summer time starts 02:00:00 CDT Sun Apr 6 2003
Summer time ends 02:00:00 CDT Sun Oct 26 2003
PIX(config)#
Now you are ready to make sure the time is always up to date using a Network Time Protocol (NTP) server.
The ntp Command
Setting the clock on the PIX Firewall is nice but what happens if the clock looses a second every
24 hours. If you are like us, you like to have everything nice and synchronized so that when
you are troubleshooting a problem, the time is the same on your firewalls and the routers or
switches. That way you know that an event on your router corresponded two-tenths of a second
after an event on your firewall.
The clock is pretty reliable on the PIX Firewall, but you would rather it be synchronized with
other equipment on your network. The NTP is used to accomplish clock synchronization.
If you are familiar with NTP syntax in IOS, you will be happy to find out it is very similar
on the PIX Firewall. Here is the command used to set up the IP address of the server to get time:
ntp server ip_address [key key_number] source interace [prefer]
The key_number will be discussed later, but the interface parameter is used to specify the
interface used to communicate with the NTP server. Since you can have multiple NTP servers
configured, you can set one to be preferred over the others with the prefer option.
There are some commands used to configure NTP authentication to make sure you are getting time from a trusted source. The ntp authenticate command is used to globally enable
NTP authentication for the PIX Firewall.
To configure an MD5 authentication key, you use the ntp authencication-key number
MD5 value command. The number is a number from 1 to 4,294,967,295, and the value is the
key value, which is an arbitrary string of up to 32 characters. You can have multiple authentication keys configured so you need to know which key to send to which server. This is where
the key_number is used in the ntp server command discussed above.
Using Common Global Configuration Commands
49
The ntp trusted-key key_number command is used to define one or more key numbers
that the NTP server needs to provide in its NTP packets for the PIX Firewall to accept synchronization with the NTP server.
To make sure your NTP communications are configured correctly, you can use the show ntp
status command. You can also use the show ntp associations command to see the NTP
peers and their stratum and reference clocks. The following is an example of using these commands to troubleshoot your NTP configuration:
PIX(config)# show ntp status
Clock is synchronized, stratum 5, reference is 135.166.127.25
nominal freq is 250.0000 Hz, actual freq is 249.9985 Hz, precision is
2**18
reference time is C258009C.694453C1 (14:33:48.411 CDT Mon Apr 28 2003)
clock offset is 1.1066 msec, root delay is 33.49 msec
root dispersion is 8.10 msec, peer dispersion is 0.35 msec
PIX(config)# show ntp associations
address
ref clock
st when poll reach delay offset disp
*~135.166.127.25 175.172.8.85 4
43
128 377
3.5
-0.27 1.7
* master (synced), # master (unsynced), - candidate, ~ configured
PIX(config)#
Remember that when configuring NTP support for the PIX Firewall, you need
to allow inbound NTP traffic from the NTP server to reach the firewall or else
your clock will not be able to synchronize.
The domain-name and hostname Commands
The domain-name command accepts a single parameter, which is the domain name and is
used to set the IPSec domain name. The domain-name and hostname commands combine to
allow the administrator to specify the fully qualified domain name (FQDN). The primary purposes of these commands are to facilitate RSA keys, which use the FQDN as an input, and
for IPSec.
The hostname command also accepts single parameter, which is the name of the host.
Although it is also part of the RSA key’s input, this command is most often used to set the PIX
CLI prompt. The following in an example of using these commands:
pixfirewall(config)# hostname PIX
PIX(config)# domain-name sybex.com
PIX(config)#
50
Chapter 2
PIX Firewall Configuration
The name/names Commands
There are a few commands that work together to provide aliases for IP addresses, much like the
/etc/hosts file in a Unix host. The purpose of the name command is to make the configuration
easier to read.
To enable this aliasing, simply type the word names from the PIX(config)# prompt. Then
create an alias by using the name keyword followed by an IP address and the name (up to 16
characters) that you want to use.
For instance, you might type the following:
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
names
name 192.168.10.53 proxy1
name 192.168.100.5 pix-outside
name 192.168.10.1 pix-inside
Then you could use the word proxy1, pix-outside, or pix-inside in place of the IP
address in all the access-list, ip address, nat, and conduit statements. This enhances
security by reducing the risk of incorrect configurations from typos. It also makes the output
from show and other commands much easier to read, as you can see from the example below:
PIX(config)# ip address outside pix-outside 255.255.255.0
PIX(config)# ip address inside pix-inside 255.255.255.0
PIX(config)# show ip address
System IP Addresses:
ip address outside pix-outside 255.255.255.0
ip address inside pix-inside 255.255.255.0
Current IP Addresses:
ip address outside pix-outside 255.255.255.0
ip address inside pix-inside 255.255.255.0
PIX(config)#
The dhcpd Command
The PIX Firewall can act both as a DHCP client as well as a DHCP server. We will be discussing
the DHCP server in this section.
Support for the DHCP server within the PIX Firewall means that the firewall can use DHCP to
configure clients directly connected to the inside interface. This DHCP feature is designed for the
remote home or branch office that will establish a connection to an enterprise or corporate network.
The DHCP server feature does not support BOOTP requests and failover
requests.
Using Common Global Configuration Commands
51
To configure a pool of addresses to use for client configuration, you need to use the dhcpd
address command, followed by the start and end addresses in the range separated by a hyphen,
and the interface where the client will reside. As stated above, the only interface that you can
enable for DHCP for is the inside interface, so the addresses range must be in the same network
as the IP address configured on the inside interface. Once the address range has been configured,
you need to enable the DHCP server feature by using the dhcpd enable inside command.
Here is an example of the dhcpd address and dhcpd enable commands:
PIX(config)# dhcpd address 192.168.1.2-192.168.1.254 inside
PIX(config)# dhcpd enable inside
PIX(config)#
If you are using the Cisco PIX 501 Firewall, there is a limit on the number of
IP addresses that can be included in the DHCP address pool. If you have a
10-user license, you can have only 32 addresses in the pool, and if you have
a 50-user license, you can have only 128 addresses in the pool.
There are other DHCP commands that can be used to configure various DHCP options for
the clients. These are dns, wins, and domain. The commands used to create these DHCP
options are dhcpd dns followed by one or two IP addresses, dhcpd wins followed by one or
two IP addresses, and dhcpd domain followed by a domain name.
The DHCP server feature can also support other option codes, which you might need to support for your DHCP clients. These options are configured using the dhcpd option command.
You can specify either an ASCII string or IP address option types. For example, here are two
options used by Cisco IP Phones to know where to contact a TFTP server to download their
configurations:
PIX(config)# dhcpd option 66 ascii tftp.mynet.com
PIX(config)# dhcpd option 150 ip 10.109.23.3 10.109.23.4
PIX(config)#
Option 66 is used to provide an IP address or hostname of a single TFTP server, and option
150 is used to provide a list of TFTP server IP addresses where the IP phone can get its code and
configuration.
What happens if you have configured the outside interface to get its IP address from an outside DHCP server and would like to use the same DNS, WINS, and domain name options for
your inside clients? You can do this with the dhcpd auto_config client_interface command, where the client_interface is the DHCP client interface. Currently, the only interface that can be enabled for DHCP client support is the outside interface, so the client_
interface parameter should always be outside. This command will automatically configure DNS, WINS, and domain name values from the DHCP client to the DHCP server. If you
also configure dns, wins, and domain options, then the CLI commands will overwrite the
auto_config options.
52
Chapter 2
PIX Firewall Configuration
You can adjust the DHCP lease time using the dhcpd lease lease_length command,
which defaults to 3,600 seconds but can be from 300 to 2,147,483,647 seconds. Other commands that need to be addressed are the show dhcpd, which displays the binding and
statistics information, and the clear dhcpd command, which clears all of the dhcpd commands, bindings, and statistics information.
The logging Command
SNMP and SYSLOG logging on the PIX Firewall are controlled by the logging command. This
command directs the output of the logging process to several different places, including the console or a SYSLOG daemon on a Unix host (or software that mimics this on a Windows
machine). The logs can also be displayed via telnet. In all cases, logging must be explicitly
enabled by using the following commands:
To turn logging on and off, from the config prompt:
[no] logging on
To change the size of the of the queue for storing SYSLOG messages:
logging queue queue_size
To display the logs on the console:
[no] logging console level
To let the failover standby unit also send SYSLOG messages, which is disabled by default:
[no] logging standby
To store the logs in a buffer on the PIX that allows them to be displayed with the show
logging command:
[no] logging buffered level
To include the device ID of the PIX Firewall in the SYSLOG message:
[no] logging device-id {hostname | ipaddress if_name | string text}
To send logs to a remote host using the SYSLOG facility:
[no] logging host [interface-name]
ip_address [protocol/port]
To specify that SYSLOG messages sent to the server have a timestamp value on each message:
[no] logging timestamp
To display the logs on telnet sessions:
[no] logging monitor level
Configuring PIX Firewall Interfaces
53
It is possible to send these messages to multiple hosts. You might want to do
this for redundancy or to let two different organizations keep tabs on the PIX
Firewall, for example. However, sending messages to more than one host
entails additional resource usage, so make sure that you don’t overload the
processor.
Configuring PIX Firewall Interfaces
The PIX Firewall must act as a gateway between two or more networks. As such, it must have,
at a minimum, two physical network interfaces.
Actually configuring interfaces on the PIX Firewall is much different than configuring other
Cisco devices, such as IOS routers and switches. For starters, you don’t enter an Interface Configuration mode. Instead, you configure the interfaces from the PIX(config)# prompt. Also,
you begin by assigning a name and security level to the hardware interface. After you’ve
assigned these, most configuration commands use the name of the interface instead of its hardware address.
Since IP is the only layer 3 protocol supported by the PIX Firewall, you must gather some specific information before configuring its interfaces:
IP address of each interface
Subnet mask of each interface
Relative security of each interface
Of course, each interface must be on a separate IP network because the PIX Firewall does not
currently support subinterfaces or secondary IP addresses (often called multinetting). However,
if you’re using the PIX Firewall’s DHCP client, you don’t actually need the IP address and subnet mask of the interface, but you will need a DHCP server. The DHCP client feature is available
only on the PIX Firewall outside interface.
Now let’s talk about giving a meaningful name to your interfaces, so you can easily recognize
what is being protected, assigning an appropriate security level for those interfaces, setting
interface properties, assigning IP addresses, and changing the MTU.
Naming an Interface and Assigning a Security Level
To name an interface, use the nameif command. The syntax for this command is as follows:
PIX(config)# nameif ?
usage: nameif <hardware_id> <if_name> <security_lvl>
no nameif
PIX(config)#
54
Chapter 2
PIX Firewall Configuration
Here, hardware_id represents the actual name, such as ethernet0, and security_lvl is
any integer between 0 and 100. As for the if_name, that’s a little tricky. The if_name is any
string you make up, with the exception that the name inside is reserved for security level 100.
The value 100, which indicates the most trusted interface, is always named inside. By convention, an interface with a security value of 0, which indicates the least trusted interface, is usually
named outside; however, this is not required—the interface with security level 0 can be named
anything you want.
Here are some examples of using the nameif command:
PIX# show nameif
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 DMZ security10
PIX# config term
PIX(config)# nameif ethernet1 inside 90
interface name "inside" is reserved for interface with security100
Type help or '?' for a list of available commands.
PIX(config)# nameif ethernet1 cheese 100
security 100 is reserved for the "inside" interface
Type help or '?' for a list of available commands.
PIX(config)#
Notice in the examples above and below that when you try to give the same name to two different interfaces, the PIX Firewall’s CLI swaps the name rather than giving you an error or
allowing two interfaces to have the same name.
Also notice that the security value follows the displaced DMZ interface, but the interface named
in your command (in this case, ethernet2) receives the security level specified in your command.
Next, let’s look at some examples that show that it is not necessary to have an inside interface or an outside interface.
PIX(config)# nameif ethernet0 cheese 0
PIX(config)# show nameif
nameif ethernet0 cheese security0
nameif ethernet1 inside security100
nameif ethernet2 DMZ security10
PIX(config)# nameif ethernet2 cheese 10
interface 0 name "cheese" swapped with interface 2 name "DMZ"
PIX(config)# show nameif
nameif ethernet0 DMZ security10
nameif ethernet1 inside security100
nameif ethernet2 cheese security10
PIX(config)# nameif ethernet2 cheese 0
PIX(config)# show nameif
Configuring PIX Firewall Interfaces
55
nameif ethernet0 DMZ security10
nameif ethernet1 inside security100
nameif ethernet2 cheese security0
PIX(config)# nameif ethernet1 whiz security11
PIX(config)# exit
PIX# show nameif
nameif ethernet0 DMZ security10
same security as “cheese”
nameif ethernet1 whiz security11
no “inside” or “outside”
nameif ethernet2 cheese security10
same security as “DMZ”
PIX#
Notice in the example above that when we chose the same security level for this interface, we
created two interfaces with the same security level. This poses an interesting problem for the
ASA, because of the method in which NAT translation slots are created: Which interface will
be permitted to access the other by default, and which interface will be denied by default?
Cisco’s answer to this is that both interfaces are denied by default. In fact, no direct communication at all is ever possible between two interfaces configured with the same security level!
Although accidentally configuring two interfaces with the same security level
and having to troubleshoot the subsequent connectivity issue would be no fun
at all, this feature can be not only valid, but very useful. For example, if you
wanted an extremely high level of security, you might want to force traffic
between two networks through a proxy server or other bastion host. You could
configure the two networks with the same security level and put the proxy on
a third, higher-security network. This might also be useful in a B2B scenario,
where you have two customer networks that need to communicate with you,
but definitely not each other.
To summarize the use of the nameif command with one more example, if you wanted to give
the first Ethernet interface of a PIX Firewall the name YellowZone and a security value of 20,
you would type the following:
PIX(config)# nameif ethernet0 YellowZone 20
PIX(config)#
For some reason, the PIX Firewall uses the term Ethernet somewhat liberally.
Unlike with the IOS, where Ethernet refers only to the 10BaseT specification
and FastEthernet refers to 100BaseTX and 100BaseFX, on the PIX Firewall,
Ethernet refers to both 10Mbps and 100Mbps specifications. This is important
because many administrators habitually define the auto-negotiation properties
of Fast Ethernet, but not Ethernet. If you have hard-coded the speed and duplex
values on your Catalyst switch, remember to define them in the PIX Firewall as
well, even though the interface says Ethernet.
56
Chapter 2
PIX Firewall Configuration
Setting Interface Properties and
Shutting Down the Interface
After you enter a nameif statement for each interface on the firewall you wish to use, you will
continue the configuration by setting the layer 2 properties. To do this, use the interface command. The syntax of this command is as follows:
PIX(config)# interface ?
usage: interface <hardware_id> [<hw_speed> [<shutdown>]]
PIX(config)#
For Ethernet interfaces, the interface command controls the speed and duplex, and allows
the interface to be administratively shut down.
The hw_speed parameter is one of the following keywords:
auto, which sets the interface to use auto-negotiation.
10BaseT, which sets the interface to 10Mbps, half-duplex.
100BaseTX, which sets the interface to 100Mbps, half-duplex.
100full, which sets the interface to 100Mbps, full-duplex.
aui, which sets the interface to 10Mbps, half-duplex for an AUI cable.
bnc, which sets the interface to 10Mbps, half-duplex for a BNC cable.
On older PIX Firewalls that support Token Ring, the available choices are 4, which sets the
ring speed of the interface to 4Mbps, and 16, which sets the ring speed of the interface to
16Mbps.
Using the shutdown keyword is intuitively obvious. Just type the hardware address and the
word shutdown, and the interface is disabled, like so:
PIX(config)# interface ethernet0 shutdown
PIX(config)#
However, once the interface is down, how to bring it back up is not so obvious. Unlike with
the IOS, you do not type no interface ethernet0 shutdown or interface ethernet0
enable. Instead, you enter the interface command again, but without the shutdown keyword. The tricky part is that when you disable the interface, you do not need to include the hw_
speed value, but when you enable the interface, you must include this value.
If you need to bounce an interface or disable it temporarily, be sure to make a
note of what the hw_speed setting is. Otherwise, when you enable it, you could
set the speed or duplex incorrectly, which would result in intermittent connectivity or no connectivity at all!
Configuring PIX Firewall Interfaces
57
So, to bring this interface back up, issue the following command:
PIX(config)# interface ethernet0 auto
PIX(config)#
One last item of interest in this sequence is in the output of the show interface command.
In the Cisco IOS, when an interface is “administratively down,” the line protocol is also down
regardless if there is signal on that interface. Here, we see that the interface is administratively
down, but the line protocol is still up: This will happen only if there is an Ethernet signal on that
interface. Otherwise the interface will be administratively down and line protocol will be down
like Cisco IOS.
PIX(config)# interface ethernet0 shutdown
PIX(config)# exit
PIX# show interface ethernet0
interface ethernet0 "YellowZone" is administratively down, line protocol is up
Hardware is i82559 ethernet, address is 0050.54ff.076d
IP address 10.2.0.20, subnet mask 255.255.255.0
MTU 1500 bytes, BW 100000 Kbit full duplex
15 packets input, 3153 bytes, 0 no buffer
Received 15 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
1 packets output, 64 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collisions, 0 deferred
1 lost carrier, 0 no carrier
input queue (curr/max blocks): hardware (128/128) software (0/1)
output queue (curr/max blocks): hardware (0/2) software (0/1)
PIX# conf t
PIX(config)# interface ethernet0 auto
PIX(config)#
From this point on, most of your configuration commands will refer to the interface by name
instead of the hardware address. In this case, we’ll use YellowZone instead of ethernet0.
Assigning an IP Address
Now, it’s time to assign an IP address to the interface. For this, we use the ip address command. The syntax for this command is as follows:
PIX(config)# ip address ?
usage: ip address <if_name> <ip_address> [<mask>]
58
Chapter 2
PIX Firewall Configuration
ip address <if_name> dhcp [setroute] [retry <retry_cnt>]
ip local pool <poolname> <ip1>[-<ip2>]
ip verify reverse-path interface <if_name>
ip audit [name|signature|interface|attack|info] ...
show|clear ip audit count [global] [interface <interface>]
PIX(config)#
This command has two options of interest. For most users, all interfaces on the PIX Firewall
will have static IP addresses. However, the PIX Firewall also supports dynamic address assignment via DHCP for use in the small office, home office (SOHO) environment, where cable
modems and DSL-based Internet connections are common.
This dynamic address can also be used for PAT, which will be explained later
in this chapter.
In our example, we’ll configure the YellowZone interface with an IP address of 10.1.1.1 /16:
PIX(config)# ip address yellowzone 10.1.1.1 255.255.0.0
PIX(config)#
Note that if the mask is not given, the default classful mask is used. And as you would suspect, this is the mask of the interface. So, all hosts, routers, and other devices on this subnet
should be configured with the same mask. Also note that while we entered the name YellowZone as proper case, and it displays in the show commands as proper case, when you are entering it in subsequent commands, it is not case-sensitive.
If you were connecting the outside address to a cable modem of an ISP that does not use static
addresses, you would enter the following command:
PIX(config)# ip address yellowzone dhcp setroute
PIX(config)#
Here, the setroute keyword tells PIX to enter a default route in its routing table. The route
points to the “default gateway” address received from the cable modem’s DHCP server.
The PIX Firewall failover feature is not compatible with DHCP.
Setting the Maximum Transfer Unit
The last interface configuration command we’ll cover is the mtu command. This command is
used to set the maximum transfer unit (MTU), which is the maximum size of a layer 2 frame.
This command is used for both Ethernet and Token Ring. The default for Ethernet is 1,500
bytes, and unless you have a good reason for changing it, it should probably be left at the default
Configuring NAT and PAT
59
setting. One of these good reasons often used is, when you are encrypting traffic using IPSec,
if you leave it at the default, when it is encrypted and encapsulated again, it will be larger than
1,500 bytes. Since Ethernet supports packets only up to 1,500 bytes, the PIX Firewall will need
to split the packet into two smaller packets, which is very in efficient. If you drop the MTU to
1,400, then the resulting IPSec protected packet will not be larger than 1,500 bytes and can be
transmitted in a single packet.
The syntax for the mtu command is as follows:
PIX(config)# mtu ?
usage: mtu <if_name> <bytes> | (64-65535)
PIX(config)#
Configuring NAT and PAT
After configuring the interfaces on the PIX Firewall, the next step is to configure NAT and PAT.
We will begin this section with a brief introduction to NAT and PAT, and then describe when
and how to configure each.
In the previous chapter, we introduced the NAT mechanisms used by the PIX
Firewall. Here, we will provide a more generic explanation of address translation with NAT and PAT. Although we use Cisco’s terminology, these concepts
could be applied to any vendor, unless otherwise noted.
Understanding Address Translation
To be perfectly honest, address translation is a hack—a workaround, specified in RFC 1631
and RFC 3022, to provide IP address expansion and alleviate the problem of IP address depletion.
As such, it breaks the rules of IP, which solves an immediate problem, but not without consequences.
To solve this problem of more hosts than addresses, RFC 1918 specifies three ranges of
addresses (one from each class) that are reserved for private use:
10.0.0.0 to 10.255.25.255
172.16.0.0 to 172.31.255.255
192.168.0.0 to 192.168.255.255
The basic idea is that these addresses are not globally unique. In other words, every organization in the world could use the 10.0.0.0 /8 network at the same time, so there is now a theoretically unlimited supply of addresses, because they can be reused. However, these addresses
are blocked from the routing tables on the backbone of the Internet. Therefore, to get a packet
from a private address across the Internet, it must be translated into a globally unique and registered address. There are two common techniques used to translate addresses: NAT and PAT.
60
Chapter 2
PIX Firewall Configuration
NAT Global and Local Addresses
NAT is, in theory, a simple one-to-one mapping of addresses. When a packet with a source IP
address such as 10.1.1.100 passes through the NAT process, the IP address in the packet is
translated to a single public IP address, such as 202.199.17.23, and vice versa. These public, or
global, IP addresses are unique and typically advertised on the Internet. If another host on the
“ten” network sent a packet through NAT at the same time, it would need to be translated into
another public address; for example, 10.1.1.101 might be translated to 202.199.17.24.
In practice, NAT is not so simple. Consider that each packet has two IP addresses: a source
and a destination. Depending on the circumstances, you might want to translate either one or
both of these IP addresses. Thus, it’s necessary to distinguish between inside and outside
IP addresses, as follows (these terms are consistent across both the PIX and IOS NAT
implementations):
Inside local The inside local address is the IP address that a host on the private network is
using. In our example, this would be 10.1.1.100.
Inside global The inside global address is the IP address into which the inside IP address is
translated. This is typically a globally unique and routable IP address, which hosts on the outside network would use to communicate with the inside local address. In our example, this is
202.199.17.23.
Obviously, all IP addresses are routable in the usual definition of the term,
which is in the context of the OSI model. In this section, by routable, we specifically mean that the appropriate hosts on the network have a route to this IP
address. For example, the Internet backbone routers do not know how to get to
the “ten” addresses because they don’t have a route entry. So, we say that IP
address isn’t routable on the Internet, although it might be routable inside your
network.
Outside global Typically, the outside global address is a globally unique and routable IP
address of a host that resides on the outside network.
Outside local The outside local address is the IP address used to translate the outside global
IP address. This IP address may or may not be registered, but it must be routable on the inside
network. Our simple example below in the “PAT” section doesn’t use an outside local IP
address.
The terms inside and outside are used with respect to NAT, not the names of interfaces on
the PIX Firewall. Remember that you might have several interfaces on a PIX Firewall, and you
might need to translate IP addresses between each of them.
The outside global and outside local IP addresses typically come into play when you want
to translate both the source and destination of a packet. We will explore this in some of our
examples in the “Configuring NAT on Multiple Interfaces” section later in this chapter.
Configuring NAT and PAT
61
Static and Dynamic NAT
To further complicate matters, NAT may be configured statically or dynamically. Static configuration is often used for inbound packets to Web or other servers. For instance, you might
have a Web server on a DMZ, and the DMZ might be configured with private IP addresses. If
a host on the global network wants to access the Web server, it cannot, because it has no idea
which IP address is being used for translation. To resolve this problem, configure a static translation between the outside global and outside local IP addresses.
In a typical organization, there might be dozens of hosts, such as PCs, and only a couple registered IP addresses. When a host sends a packet to the global network, the PIX Firewall will
choose the first available registered IP address from a pool of addresses that you configure. This
is the inside global IP address. If another inside host sends a packet to the global network, the PIX
Firewall will again choose the next available IP address. If there are no more available addresses,
that host will be unable to communicate with the global network. This behavior is referred to as
dynamic, because the host does not know (or care) what its inside global IP address will be, and
it might be different every time it accesses the Internet. The host on the global network always
knows what the inside global IP address is, because it is in the source address field of the IP header.
Although dynamic translation helps solve the address-depletion issue, it still constrains concurrent connections to the total number of registered IP addresses. For example, if you have
1,000 computers on your network and only 32 registered IP addresses, only 32 of those 1,000
computers can communicate with the Internet at a time. PAT, often called overloading, was created to solve this very problem.
PAT
PAT is a method of multiplexing a potentially large number of private IP addresses through a
single registered IP address. This is possible because the PIX Firewall keeps track of the source
ports used and translates ports as well as IP addresses.
For instance, if a couple PCs on the local network request a Web page from a server on the
global network, the first PC will send a packet addressed as follows:
Source IP
Source Port
Destination IP
Destination Port
10.1.1.100
1026
199.206.253.29
80
For our example, we’ll suppose that the firewall’s outside interface is addressed
199.206.12.143 and the server’s IP address is 199.206.253.29. When this packet is received on
the inside interface, the PIX Firewall will modify only the source IP address and port. It will not
modify the destination information. The source IP address is changed to make the packet appear
as if it originated from the outside interface of the PIX Firewall. In other words, the inside local
IP address is replaced with the inside global IP address, just as with NAT. However, the source
port is also translated to the first unused port above 1024. So, as the packet leaves the PIX Firewall, it looks like this:
Source IP
Source Port
Destination IP
Destination Port
199.206.12.143
1025
199.206.253.29
80
62
Chapter 2
PIX Firewall Configuration
Now, when the next host sent a packet, if dynamic NAT were being used, with only one registered IP address, it would be denied. But with PAT, it is just given the next highest port. In this
example, we’ll suppose the traffic is sent to the same server, although it could be any destination.
Source IP
Source Port
Destination IP
Destination Port
10.1.1.101
1032
199.206.253.29
80
When PIX receives this packet, it also translates it using the single registered IP address, but
it uses a different source port, as shown below:
Source IP
Source Port
Destination IP
Destination Port
199.206.12.143
1026
199.206.253.29
80
To the Web server, it appears as if the same host were making two requests, but it can distinguish between these via the source port. When the server responds, PIX knows where to send
the response, because it knows which destination port maps to which local IP address and port.
Because there are 65,535 ports available to TCP and UDP, PAT is capable of supporting a
very large number of privately addressed devices. Usually one outside IP address can support up
to 64,000 inside hosts.
Address Translation Consequences
As we mentioned earlier, IP address translation comes with a few side effects. Aside from mild
reactions such as headaches and dizziness as a result of trying to keep the “inside local, outside
global” monikers straight, and the increased difficulty during troubleshooting, NAT actually
breaks some things.
The most common problem is that many protocols include information about IP addresses
in the payload of the packets, instead of taking it only from the headers. The security protocol
IPSec is famous for being incompatible with NAT, because it tracks the sender’s address for
anti-spoofing and nonrepudiation purposes. When the receiver gets the packet, and the value in
the IP source address field of the IP header is different from the value in the payload (because the
header was translated), the packet is not accepted or decrypted. This is now not such a problem
since current versions of Cisco IOS can use IPSec over UDP that works with PAT, but DHCP,
routing protocols, and other protocols are similarly affected.
Cisco’s implementation of NAT makes special allowances to enable some protocols, such as
DNS A and PTR records and queries, Microsoft’s NetMeeting, and FTP. However, it does not
support protocols with varying frame formats or frames that are encrypted, such as SNMP and
PPTP. For this reason, it is possible to have traffic pass through the PIX Firewall without being
translated, but the traffic is still handled as if it were being translated. This configuration will
be covered in the “Identity NAT” section later in this chapter.
Configuring NAT and PAT
63
NAT, PAT, and Security
In addition to the negative side effects discussed in the previous section, IP address translation
produces a positive side effect as well: enhanced security. However, popular opinion regards
this added security more highly than it deserves. Specifically, many people think that if a host
is on the “ten” network and connected to the Internet via NAT, hackers will be totally unable
to reach this host, because they do not have a route to it. The problem is that this is true only
part of the time. The different types of address translation—static NAT, dynamic NAT, and
PAT—offer different levels of security.
Static NAT offers no security whatsoever. While it is true that there isn’t a route to the 10.0.0.0 /8
network on the Internet backbone, that doesn’t matter—the intruders will be using the inside global address instead of the inside local address. In other words, any malicious traffic sent to the
inside global address will simply be translated to the inside local address and passed on by NAT.
Dynamic NAT will make it practically impossible to directly communicate with a host on the
inside network until that host attempts to communicate with the outside network. In other
words, as long as there is no address translation in the firewall (called a translation slot in the
PIX Firewall, as described in the previous chapter), you’re fairly safe. However, the instant you
open a browser window or any other application on a client that accesses the Internet, the firewall will dynamically create a translation. Until that translation times out, the host is just as vulnerable as it would be if it had a registered address. So, the only protection dynamic NAT really
offers is that the internal hosts are moving targets. Attackers never know which host they will
get when attacking an inside global address.
PAT offers a considerable amount of security. This is because only the port you use is exposed
to the Internet. For example, suppose that you’re running an anonymous FTP service on your host
for internal use, and you also open a browser window and initiate a HTTP session to the Internet
from the same host that uses a source port of 1026. When an intruder scans the firewall’s address,
it will find only your 1026 connection (which is fairly safe) and not the TCP port 21. The intruder
will continue to be oblivious to the other listening ports on your host, including the anonymous
FTP. With static and dynamic NAT, a ping sent to the inside global address will be passed on to
the host (inside local), but this is impossible with PAT.
The issue here is that many people assume all versions of NAT provide the same level of protection as PAT, which leaves them with a very false sense of security. Fortunately, if you are
using a PIX Firewall, by default, it won’t allow any of those outside connections—such as scans
or Pings—inbound, even with a static address translation entry. But even though the differences
in the levels of security provided by address translation do not necessarily apply to PIX Firewall
users, it is important to understand that it is the ASA of the PIX Firewall that is providing the
protection, not the NAT process itself.
Unfortunately, a lot of people have purchased cheap cable-modem routers that
have been labeled “firewalls.” Many of these “firewalls” perform only NAT.
They have the ability to block ports, but ports aren’t blocked by default. Without
the ASA, the protection offered by NAT on these routers is nearly worthless.
64
Chapter 2
PIX Firewall Configuration
Configuring NAT
Although NAT might appear confusing at first, it’s really quite simple if you understand one
thing: NAT is always configured between a pair of interfaces. This makes it easy to focus on
only two interfaces at a time, even if you have multiple interfaces to configure. And to make
things even easier, there are only two commands to deal with—one per interface. If you are
using NAT between multiple interfaces, you have a separate NAT command on the inside interfaces and one on the outside interfaces.
The address translation on the PIX is always performed between a local and global address,
and all you need to do is pick the interfaces. You do not need to define which one is local and
which one is global, because the local interface is always the higher security value. This will
become very important later, when we look at some examples of address translation between
three and six interfaces in the “Configuring NAT on Multiple Interfaces” section.
Another important aspect of NAT configuration is the order of operation on the PIX Firewall. Knowing this order will help you understand why NAT is relevant only between pairs of
interfaces, and later, it might help you troubleshoot problems.
For an outbound packet (traveling from a higher-security interface to a lower-security interface), when the PIX Firewall receives the packet, the first thing it does is to determine the outgoing interface based on routing information. At this point, it knows the incoming and outgoing
interfaces, and which one is local and global, because it knows their relative security levels.
Then it searches for a translation slot. Once it finds one or creates one, it checks for security
rules, such as ACLs, then translates the packet and sends it on its way.
For an inbound packet (traveling from a lower-security interface to a higher-security interface), the operation is a little different. First, it checks the ACLs, then it determines the outgoing
interface, based again on routing information. Last, it checks for a translation slot.
There are of course, dozens more tasks that the PIX Firewall performs. We have
simplified the operation greatly to make it easier to understand. For more detailed
information, visit the PIX Firewall documentation pages at www.cisco.com.
Now, let’s take a look at the commands used to configure NAT. We’ll begin with the simple
examples and work progressively up to complex configurations, as we add interfaces and rules
to deal with common, real-life situations.
The nat and global Commands
There are two commands used to configure NAT on the PIX Firewall: nat and global.
The nat command configures the local interface. It defines the networks to be translated.
This command has the following syntax:
PIX(config)# nat ?
usage: [no] nat [(<if_name>)] <nat_id> <local_ip> [<mask>
[<max_conns> [emb_limit> [<norandomseq>]]]]
[no] nat [(if_name)] 0 [access-list [<acl-name>]]
PIX(config)#
Configuring NAT and PAT
65
The global command configures the global interface. It defines what the translated network
will be. The global command has the following syntax:
PIX(config)# global ?
usage: [no] global [(<ext_if_name>)] <nat_id> {<global_ip>
[-<global_ip>] [netmask <global_mask>]} | interface
PIX(config)#
Notice that the nat command uses the if_name and local_ip parameters, while the global
command uses the ext_if_name and global_ip parameters. The relationship of these is a host
with address local_ip sending a packet to the PIX Firewall’s if_name will appear as global_
ip to devices beyond the PIX Firewall’s ext_if_name. The emb_limit is used to set the number
of embryonic connections that will be supported to the protected systems. This is used to type
and stop a SYN flood attack. We will cover this more in Chapter 4, “Advanced Protocol Handling, Attack Guards, and Intrusion Detection.”
For a simple example of using the nat and global commands to configure NAT, consider
the two networks separated by a PIX Firewall, shown in Figure 2.1. One host is on the RFC
1918 private network 10.1.1.0 /24, and the other is on the public network 65.24.200.0 /24.
Here, we want any packet that is sent from the inside network 65.24.200.0 to the outside network 10.1.1.0 to be translated.
FIGURE 2.1
Simple NAT example
Global pool
10.1.1.8–10.1.1.15
PIX Firewall
Outside
Inside
.1
65.24.200.0/24
10.1.1.0/24
.1
.100
.2
Host
Host
Destination IP
Source IP
Destination IP
Source IP
10.1.1.100
10.1.1.8
10.1.1.100
65.24.200.2
66
Chapter 2
PIX Firewall Configuration
Do not be fooled by tricky questions: the local and global interfaces are determined only by the security values. It does not matter which address is private
or public! Of course, in the real world, your most trusted inside network will
almost always use private addresses, while your untrusted outside network
will use public addresses. We have configured this example backwards, just to
demonstrate the point.
In this case, the if_name would be inside, and the ext_if_name would be outside. The
local_ip would be 65.24.200.0 with a mask of 255.255.255.0.
The global_ip could be many different values, depending on your environment and how
you want the PIX Firewall to behave. In this case, we’ll assign the addresses 10.1.1.8 through
10.1.1.15 to the pool. This means up to eight hosts on the inside network could have translations at a time, and these eight hosts will appear to the outside world as .8 through .15.
The last required parameter for the nat and global commands is nat_id. The NAT ID is
an arbitrary number between 0 and 2 billion, which allows you to tell the PIX Firewall which
global addresses you want to use to translate internal addresses. This might make more sense
when we start configuring multiple interfaces. For now, we can pick any number we want, as
long as we use the same number in both the nat and global commands.
Using a NAT ID of 0 tells the PIX not to do any translation. We’ll discuss this in
more detail later in the chapter, in the “Identity NAT” section.
So, now we’re ready to configure NAT on the PIX Firewall shown in Figure 2.1. We’ll start
by verifying that our interfaces are named and addressed correctly, using the show nameif and
show ip commands:
PIX# show nameif
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 intf2 security10
PIX# show ip
System IP Addresses:
ip address outside 10.1.1.1 255.255.255.0
ip address inside 65.24.200.1 255.255.255.0
ip address intf2 127.0.0.1 255.255.255.255
Current IP Addresses:
ip address outside 10.1.1.1 255.255.255.0
ip address inside 65.25.200.1 255.255.255.0
ip address intf2 0.0.0.0 0.0.0.0
PIX#
Configuring NAT and PAT
67
Now, we’re ready to tell the PIX Firewall which addresses we want translated, using the nat
command:
PIX(config)# nat (inside) 1 65.24.200.0 255.255.255.0
PIX(config)#
Don’t forget the parentheses around the if_name and ext_if_name parameters!
The unusual thing about this command is the mask field. Unlike the ip address command,
where you use the mask of the interface, here the mask is used to tell the PIX Firewall how many
addresses to include in the range. For instance, even though the actual interface 65.24.200.1 has
a 24-bit mask, we could use the following command:
PIX(config)# nat (inside) 1 65.24.200.0 255.255.255.128
PIX(config)#
This tells the PIX Firewall that we want only the first half of the address range (65.24.200.1
through 65.24.200.127) to be translated.
Similarly, we could use the following command:
PIX(config)# nat (inside) 1 65.24.200.14 255.255.255.255
PIX(config)#
By using the full 32-bit mask, we are telling PIX that we want only the host 64.24.200.14 to
be translated. In this case, none of the other clients on that network would be translated.
Next, we’ll tell the PIX Firewall which addresses we want these translated into, using the
global command:
PIX(config)# global (outside) 1 10.1.1.8-10.1.1.15
PIX(config)#
Remember that the NAT ID (in this case, 1) can be anything you want, as long
as it’s the same in both the nat and global commands.
This is all that is required to allow hosts on the inside network to access the outside network. Once this command is in place, the default behavior of the PIX Firewall is to let all
hosts included in the nat command (in this case, 65.24.200.1 through 65.24.200.254) make
outbound connections, but hosts that want to initiate connections back in are still restricted.
To allow a host on the outside network to initiate a connection, we use a third command:
static.
68
Chapter 2
PIX Firewall Configuration
Optionally, you can allow all hosts on the inside to be translated by typing the
command nat (inside) 1 0 0, with 0 0 being a shortcut for 0.0.0.0 0.0.0.0. As
you can imagine, this can make configuration a lot less difficult, especially if you
have a lot of subnets on your internal network that don’t lend themselves to
address summarization. However, it is a good idea to explicitly declare the
IP addresses that are allowed out, because it will make spoofing almost impossible. Nobody wants the embarrassment or liability of having their network used
as an attack launch pad because they haven’t implemented anti-spoofing filters.
The static Command
The static command allows a host on the outside network to initiate a connection to a host
on the inside network. The static command is different from the nat and global commands
because it operates by itself. You enter all the information in one command rather than two.
Here is the syntax of the static command:
PIX(config)# static ?
usage: [no] static [(internal_if_name, external_if_name)]
{<global_ip>|interface} <local_ip> [netmask <mask>]
[<max_conns> [<emb_limit> [<norandomseq>]]]
[no] static [(internal_if_name, external_if_name)] {tcp|udp}
{<global_ip>|interface} <global_port>
<local_ip> <local_port> [netmask <mask>]
[<max_conns> [<emb_limit> [<norandomseq>]]]
PIX(config)#
For example, let’s say we have a Web server on our inside network with an IP address of
65.24.200.22. We want all hosts on the outside network to be able to reach this service via the
global address 10.1.1.16. To configure this, we would enter the following command:
PIX(config)# static (inside, outside) 10.1.1.16 65.24.200.22
PIX(config)#
The static command can be somewhat confusing because the interfaces are
entered as inside then outside, but the IP addresses are entered as outside then
inside. Just remember inside outside, outside inside for the static command
and you should be fine.
Configuring NAT and PAT
69
Identity NAT
Occasionally, you will want the protection of a PIX Firewall but do not need or desire address
translation. This might be the case for several reasons:
Your entire network is using registered addresses.
The firewall’s job is to protect some critical area of the internal network from the rest of the
internal network, where both are using private addresses. An example is a large company’s
cluster of accounting or human resource systems that should be accessed only by people in
certain departments.
Using NAT breaks some protocols, such as SNMP, PPTP, and a lot of streaming media protocols.
The problem here is that without a translation slot, nothing gets through the PIX Firewall,
and translation slots are created only by the NAT process (as described in the previous chapter).
The solution to this problem is to still send packets through the NAT process, but not actually
translate them. In other words, the source and destination fields in the IP headers are not modified as they pass through the PIX Firewall. This is often called identity NAT.
We configure identity NAT by using the nat 0 command. For example, if the inside interface
of the PIX Firewall is 10.1.1.1 /24, and we do not want this network to be translated, we can
accomplish this with the following command:
PIX(config)# nat (inside) 0 10.1.1.0 255.255.255.0
PIX(config)#
Note that a corresponding global command is not required for identity NAT.
When we enter this command, the PIX Firewall confirms our instruction:
PIX(config)# nat (inside) 0 10.1.1.0 255.255.255.0
nat 0 10.1.1.0 will be non-translated
PIX(config)#
The operation of the nat 0 command, both syntactically and under the hood,
has changed dramatically over the last several versions of the PIX operating
system. This book deals with only the current implementation as of version
6.0(1). Even so, we are going into substantially more detail than you can expect
to see on the exam. If you are using a different version, read the Command Reference documentation on Cisco’s website before using the nat 0 command.
70
Chapter 2
PIX Firewall Configuration
Now, let’s suppose we want the 10.1.1.0 subnet on the inside interface translated as usual,
but we have one host, with IP address 10.1.1.15, that frequently establishes IPSec-encrypted
tunnels across the PIX Firewall, so we want every host on this network to be translated except
10.1.1.15. To configure this, we use two commands (not including the corresponding global
commands on the outgoing interfaces):
PIX(config)# nat (inside) 1 10.1.1.0 255.255.255.0
PIX(config)# nat (inside) 0 10.1.1.15 255.255.255.255
PIX(config)#
Here is the output of the show nat command after these statements have been entered on the
PIX Firewall:
PIX(config)# nat (inside) 1 10.1.1.0 255.255.255.0
PIX(config)# nat (inside) 0 10.1.1.15 255.255.255.255
nat 0 10.1.1.15 will be non-translated
PIX(config)# show nat
nat (inside) 0 10.1.1.15 255.255.255.255 0 0
nat (inside) 1 10.1.1.0 255.255.255.0 0 0
PIX(config)#
Notice that even though the commands were typed out of order, PIX sorted the longest subnet mask to the top of the list.
In these examples, using a zero in the nat_id field tells the PIX Firewall to allow packets
from the specified hosts to pass through the firewall without being translated. However, there
is another use for this command that can be quite confusing. We will explain it in the next section, because it is important that it not be confused with identity NAT.
Access Blocking with ACLs
When there are many internal networks to be translated, it can be easy to make data-entry
errors. To reduce this possibility, recent versions of the PIX operating system have made the nat
command more powerful, but somewhat confusing. In this section, we will explain the proper
way to tell the PIX Firewall which networks to translate.
As an example, let’s say we have the 10.1.0.0 /20 subnet further broken into 16 24-bit subnets,
from 10.1.0.0 /24 to 10.1.15.0/24. All of these access the Internet through the inside interface of
our PIX Firewall. Let’s further suppose that we want all of these networks to be translated, except
for the hosts between 10.1.9.128 and 10.1.9.191. However, in this case, we’re not talking about
identity NAT, because we don’t want these hosts to have any access at all. In other words, PIX
should not create a translation slot for hosts in the range 10.1.9.128 /26.
There are two ways to accomplish this task. The first way is shown below, including the commands and the output of the show nat command.
PIX(config)# nat (inside) 1 10.1.0.0 255.255.255.0
PIX(config)# nat (inside) 1 10.1.1.0 255.255.255.0
Configuring NAT and PAT
71
PIX(config)# nat (inside) 1 10.1.2.0 255.255.255.0
PIX(config)# nat (inside) 1 10.1.3.0 255.255.255.0
PIX(config)# nat (inside) 1 10.1.4.0 255.255.255.0
PIX(config)# nat (inside) 1 10.1.5.0 255.255.255.0
PIX(config)# nat (inside) 1 10.1.6.0 255.255.255.0
PIX(config)# nat (inside) 1 10.1.7.0 255.255.255.0
PIX(config)# nat (inside) 1 10.1.8.0 255.255.255.0
PIX(config)# nat (inside) 1 10.1.9.0 255.255.255.128
PIX(config)# nat (inside) 1 10.1.9.192 255.255.255.192
PIX(config)# nat (inside) 1 10.1.10.0 255.255.255.0
PIX(config)# nat (inside) 1 10.1.11.0 255.255.255.0
PIX(config)# nat (inside) 1 10.1.12.0 255.255.255.0
PIX(config)# nat (inside) 1 10.1.13.0 255.255.255.0
PIX(config)# nat (inside) 1 10.1.14.0 255.255.255.0
PIX(config)# nat (inside) 1 10.1.15.0 255.255.255.0
PIX(config)# exit
PIX# show nat
nat (inside) 1 10.1.9.192 255.255.255.192 0 0
nat (inside) 1 10.1.9.0 255.255.255.128 0 0
nat (inside) 1 10.1.0.0 255.255.255.0 0 0
nat (inside) 1 10.1.1.0 255.255.255.0 0 0
nat (inside) 1 10.1.2.0 255.255.255.0 0 0
nat (inside) 1 10.1.3.0 255.255.255.0 0 0
nat (inside) 1 10.1.4.0 255.255.255.0 0 0
nat (inside) 1 10.1.5.0 255.255.255.0 0 0
nat (inside) 1 10.1.6.0 255.255.255.0 0 0
nat (inside) 1 10.1.7.0 255.255.255.0 0 0
nat (inside) 1 10.1.8.0 255.255.255.0 0 0
nat (inside) 1 10.1.10.0 255.255.255.0 0 0
nat (inside) 1 10.1.11.0 255.255.255.0 0 0
nat (inside) 1 10.1.12.0 255.255.255.0 0 0
nat (inside) 1 10.1.13.0 255.255.255.0 0 0
nat (inside) 1 10.1.14.0 255.255.255.0 0 0
nat (inside) 1 10.1.15.0 255.255.255.0 0 0
PIX#
Here, we type one nat statement for each 24-bit network, except for the 10.1.9.0 subnet,
where we type two statements, so as not to include the addresses that we do not want translated.
In other words, we explicitly define all the networks that we want translated.
It’s easy to see how mistakes could be made by issuing so many commands. To make matters
worse, the PIX Firewall again sorts our longest subnet masks to the top of the list. While this
72
Chapter 2
PIX Firewall Configuration
made things easier to read and understand earlier, it now makes it very difficult, because the
subnets are no longer in numerical order. In large organizations, where there are often hundreds
of networks, variable-length subnet masking (VLSM) is in use, and subnets often aren’t contiguous, this could get out of hand very quickly!
Now compare that method with the access-list feature implemented as of version 5.3:
PIX(config)# access-list block permit ip 10.1.9.128 255.255.255.192 any
PIX(config)# nat (inside) 1 10.1.0.0 255.255.240.0
PIX(config)# nat (inside) 0 access-list block
PIX(config)# exit
PIX# show nat
nat (inside) 0 access-list block
nat (inside) 1 10.1.0.0 255.255.240.0 0 0
PIX# show access-list block
access-list block permit ip 10.1.9.128 255.255.255.192 any (hitcnt=0)
4PIX#
Again, although the corresponding global command has been omitted, we accomplished in
three commands what previously took 17. Not only is the input far easier, and by extension less
error-prone, but the output is much simpler and easier to comprehend. The difference here is
that the entire 10.1.0.0 /20 network is covered in one easy-to-read statement, and the address
ranges you don’t want are defined in an ACL, then applied with the nat 0 statement.
When you are troubleshooting a network problem or responding to an attack,
time is critical. Any steps you can take to shorten the time required to understand your configuration will directly affect the time it takes to respond to the
situation.
In this section and the previous section, you have seen not only the value of both identity
NAT and the ability to block address translation using ACLs, but also that these commands are
easily confused. Let’s review their use:
Use nat (interface) 0 network subnet-mask when you want certain hosts to be
known outside the PIX Firewall by their actual address.
Use nat (interface) 0 access-list access-list when you want to keep certain
hosts from ever sending traffic through the PIX Firewall by preventing them from creating
a translation slot.
ACLs will be covered in detail in the next chapter.
Configuring NAT and PAT
73
Configuring PAT
The configuration of PAT is even easier than NAT. We use the same nat command:
PIX(config)# nat (inside) 1 65.24.200.0 255.255.255.0
PIX(config)#
However, for the global command, we make one slight modification:
PIX(config)# global (outside) 1 10.1.1.8
PIX(config)#
By listing only a single address in the global pool (in this case, 10.1.1.8), all the hosts from
65.24.200.1 to 65.24.200.254 will be seen on the outside network as 10.1.1.8. In other words,
we’ve configured PAT. This IP address does not need to be the same address that is being used
by the outside interface. Plus you can have NAT and PAT configured concurrently, even to the
same interface.
You might be asking yourself how you can use PAT when DHCP is used on the
outside interface and you never know what the IP address is going to be. In this
situation you can substitute the outside IP address with the interface parameter and the PIX Firewall will use the IP address from DHCP for PAT. The syntax
would be global (outside) 1 interface.
Here’s an example of this command in action:
PIX(config)# global (outside) 1 10.1.1.8
Start and end addresses overlap with existing range
Type help or '?' for a list of available commands.
PIX(config)# no global (outside) 1 10.1.1.8-10.1.1.15
PIX(config)# global (outside) 1 10.1.1.8
Global 10.1.1.8 will be Port Address Translated
PIX(config)#
We start by attempting to configure a PAT address that is currently part of an existing global
pool. As you can see, the PIX Firewall won’t allow that. You cannot have overlapping address
ranges (although you can use NAT and PAT at the same time, as you’ll see later in the “Configuring Six Interfaces” section). You must remove the first range before assigning the second.
Another point of interest is that the PIX Firewall lets you know what you’ve done. This helps
the PIX Firewall be more secure by preventing a lot of accidental misconfiguration.
Let’s take a look at using static PAT for inbound traffic. A common situation for a small to
medium business is to use PAT but want to have a few servers publicly available. Consider the
example shown in Figure 2.2.
74
Chapter 2
FIGURE 2.2
PIX Firewall Configuration
Static PAT example
.2
WWW server
PIX Firewall
Inside
.1
FTP server
202.199.87.56
192.168.1.0/24
.3
Outside
.4
Telnet server
Destination IP: Port
Source IP: Port
Destination IP: Port
Source IP: Port
192.168.1.2 : 80
x.x.x.x : y
202.199.87.56 : 80
x.x.x.x : y
192.168.1.3 : 21
x.x.x.x : y
202.199.87.56 : 21
x.x.x.x : y
192.168.1.4 : 23
x.x.x.x : y
202.199.87.56 : 23
x.x.x.x : y
After PAT translation
Before PAT translation
Here, we have a Web server, an FTP server, and a Unix-based server that is accessed via telnet. Our fictitious business wants all three of these services to be available to the outside network, but has only a single global address.
We’ll readdress our networks here, so that the inside network is 192.168.1.0 /24 with the
three servers using .2, .3, and .4 respectively. The PIX Firewall will be .1, of course. The ISP has
assigned us a single registered address for our outside interface of 202.199.87.56.
This scenario presents a few challenges. First, we will need to use the PIX Firewall’s outside
interface address as the global PAT address. Also, we need to direct inbound traffic as follows:
Inbound HTTP traffic destined for TCP port 80 to 192.168.1.2
Inbound FTP traffic destined for TCP port 21 to 192.168.1.3
Inbound telnet traffic destined for TCP port 23 to 192.168.1.4
No traffic to any other port will be allowed to pass inbound, but all the PCs on the 192.168.1.0
network must be able to access the Internet through the PAT translation. Our configuration will
require three static commands: one for each service. And we’ll need one nat command and one
global command to allow our internal users outbound access.
This scenario—where packets sent to a single global IP address are sent to different local IP
addresses based on their TCP port—is often referred to as port redirection. Port redirection uses
Configuring NAT and PAT
75
the same static command we used to map IP addresses on a one-to-one basis in the “Static and
Dynamic NAT” section earlier in the chapter.
The major difference in static NAT and port redirection is that in port redirection, we are
adding the optional port number and protocol. The protocol for all three of our requirements
is TCP. The port number depends on the service, but can be given in the decimal equivalent of
the protocol’s assigned number or simply as a keyword. We will use both methods in the following configuration as an example.
The static Commands for Outside to Inside Requirements
Three static commands take care of our outside-to-inside requirements. (Although a few of
these parameters, such as the two zeros on the end of each static command, are optional, we
included them for completeness.)
For the inbound HTTP traffic, we use this command:
PIX(config)# static (inside, outside) tcp interface 80 192.168.1.2
➥80 netmask 255.255.255.255 0 0
PIX(config)#
This command tells the PIX Firewall that any traffic that arrives on the outside interface, destined for TCP port 80 of the outside interface, should be transmitted out the inside interface to
192.168.1.2, TCP port 80. Also, it tells the PIX Firewall to change the destination IP address
field in the IP header to 192.168.1.2.
Notice the keyword interface. This keyword is used to indicate the external or lowersecurity interface so that the actual IP address of the PIX Firewall’s outside interface can be
used, instead of dedicating a global pool of IP addresses as in the previous examples. Using this
interface can occasionally be complicated, but it definitely saves IP addresses.
For the inbound FTP traffic, we use this command:
PIX(config)# static (inside, outside) tcp interface 21 192.168.1.3
➥21 netmask 255.255.255.255 0 0
PIX(config)#
This command tells the PIX Firewall that any traffic that arrives on the outside interface, destined for TCP port 21 of the outside interface, should be transmitted out the inside interface to
192.168.1.3, TCP port 21. Also, it tells the PIX Firewall to change the destination IP address
field in the IP header to 192.168.1.3.
For the inbound telnet traffic, we use this command:
PIX(config)# static (inside, outside) tcp interface telnet
➥192.168.1.4 telnet netmask 255.255.255.255 0 0
PIX(config)#
This command is just like the previous two, except that it sends the traffic destined for TCP
port 23 to 192.168.1.4. Notice that we used the keyword telnet in this example, instead of the port
number in decimal, to illustrate the flexibility. Note that in the show commands, and also in
76
Chapter 2
PIX Firewall Configuration
Configuration mode, PIX will replace these port numbers with its keywords automatically. One
more thing to remember is that the port numbers do not need to be the same. You can change
from port 53 (domain) on the outside to port 80 (www) on the inside. This might be useful when
you are trying to hide the outside port to an inside host by choosing a high port, such as 43234,
to be translated to port 23 (telnet) to access an inside host.
The nat and global Commands for Inside to Outside Requirements
For internal hosts to also access the external network, we need a nat and global statement. The
nat statement is identical to the ones used previously, but in the global statement, we see the
same interface keyword. This allows our internal hosts to use the same address as the outside
interface as well, again saving IP addresses. Using the interface keyword allows us to change
the IP address of the outside interface without having to change all the corresponding nat,
global and static commands.
PIX(config)# nat (inside) 1 192.168.1.0 255.255.255.0
PIX(config)# global (outside) 1 interface
PIX(config)#
These two commands tell the PIX Firewall to allow all traffic from the 192.168.1.0 network
on the inside interface to access resources on the outside interface, after being translated with
PAT using the IP address of the outside interface.
Checking the Configuration
After entering these commands, we exit the Configuration mode and type a few show commands to see how it looks.
PIX# show global
global (outside) 1 interface
PIX# show nat
nat (inside) 1 192.168.1.0 255.255.255.0 0 0
PIX# show static
static (inside,outside) tcp interface www 192.168.1.2 www netmask
➥255.255.255.255 0 0
static (inside,outside) tcp interface ftp 192.168.1.3 ftp netmask
➥255.255.255.255 0 0
static (inside,outside) tcp interface telnet 192.168.1.4 telnet
➥netmask 255.255.255.255 0 0
PIX#
The show commands indicate that our commands were accepted as expected. Notice that the
port numbers we typed have been converted to the recognized keywords for easy reading.
Configuring NAT and PAT
77
Now let’s test it. We’ve set up hosts on either side of the firewall and attempted to telnet to
202.199.87.56, then pointed our Web browser to the same address. The show xlate command
should prove our configuration is working. The output is shown below:
PIX# show xlate
2 in use, 2 most used
PAT Global 202.199.87.56(23) Local 192.168.1.4(23)
PAT Global 202.199.87.56(80) Local 192.168.1.2(80)
PIX#
As you can see, requests to port 23 were forwarded to 192.168.1.4 TCP port 23, while
requests to port 80 were sent to 192.168.1.2 TCP port 80. FTP command sessions would work
similarly, but without the fixup protocol command, our data sessions would be denied. We’ll
discuss this in more detail in Chapter 4, “Attack Guards, Intrusion Detection, and Advanced
Protocol Handling.”
Configuring NAT on Multiple Interfaces
In practice, networks often start out simply, much like the configurations we’ve shown in the
previous sections, but they almost always grow both in size and complexity, as new segments
and services are added and the amount of traffic increases. In this section, we’ll explain the relationships between interfaces when there are more than just two.
The configuration of multiple interfaces might seem complicated, because of
the way packets are translated as they go from one network to another. But as
long as you remember that translations always go between pairs of interfaces,
and focus on just the pair in question, configuring multiple interfaces on the
PIX Firewall will be much easier to comprehend and troubleshoot.
Configuring Three Interfaces
We’ll start with a simple scenario with three interfaces, including the Internet on the outside
interface, a DMZ network containing proxy and Web servers, and two private networks on the
inside interface. For the ASA, we’ll assign 100 to the inside interface, 0 to the outside interface,
and 10 to the DMZ interface. Here’s a summary:
Interface
Security Level
Inside (two private networks)
100
DMZ (proxy and Web servers)
10
Outside (Internet)
0
78
Chapter 2
PIX Firewall Configuration
Changing the DMZ interface to a security value of 50 wouldn’t change the PIX
Firewall’s behavior. That is, increasing or decreasing the value won’t automatically make it more or less secure. What’s important is the value relative to the
other interfaces. In this case, as long as it is more than the outside interface and
less than the inside interface (that is, between 1 and 99), any number will have
the same effect.
This scenario, shown in Figure 2.3, is quite common. In this scenario, we will assume that
our ISP is allowing us to use the 12 unused, registered addresses on the outside network for our
NAT global pool. However, we have 100 user PCs on our 10.1.1.0 /24 subnet and another 100
user PCs on 10.1.2.0 /24 subnet. Since 200 is much larger than 12, we’ll obviously need to make
some allowances here.
FIGURE 2.3
A simple multiple-interface scenario
10.1.1.0/24
WWW server
Router
.25
.3
192.168.1.0/24
DMZ
10.1.1.0/24
Inside
10.1.1.0/24
.1
ISP
Outside
.1
.2
PIX
.1
Internet
37.20.5.0/28
Router
.2
Router
Further, let’s suppose the users on the 10.1.1.0 subnet are allowed unrestricted access
directly to the Internet, but users on the 10.1.2.0 subnet must use a proxy server in the DMZ
to access the Internet. These users will be translated from the inside to the DMZ using the global
pool 192.168.1.101 to 192.168.1.199. If more than 99 simultaneous connections are needed,
the .200 address should be used for PAT. If there are more than 99 simultaneous connections
from the 10.1.1.0 subnet to the Internet, the 37.20.5.14 address should be used for PAT.
The proxy server (IP address 192.168.1.25) on the DMZ is allowed to initiate connections
to the Internet using NAT, but may not initiate connections to the inside network. The Web
server (IP address 192.168.1.75) is allowed to talk to a database (IP address 10.1.1.50) on the
inside network.
Configuring NAT and PAT
79
Of course, hosts on the Internet are not allowed to initiate any connections to the inside network, and they may initiate requests to the Web server only on the DMZ network.
Configuring NAT between the Inside and Outside Interfaces
Now that we understand the requirements, let’s begin by configuring NAT between the inside
and outside networks. According to our requirements, the only connectivity allowed between
the inside and outside interfaces is from the 10.1.1.0 network, and these addresses are supposed
to be translated using the addresses 37.20.5.5 through 37.20.5.13. After those are used, any
subsequent connections should be translated via PAT using the 37.20.5.14 address. No connections are required from the outside to the inside, so no static commands are necessary. The
commands required for this configuration are as follows:
PIX(config)# nat (inside) 1 10.1.1.0 255.255.255.0
PIX(config)# global (outside) 1 37.20.5.5-37.20.5.13
PIX(config)# global (outside) 1 37.20.5.14
PIX(config)#
Configuring NAT between the Inside and DMZ Interfaces
Next, we’ll configure NAT between the inside and DMZ interfaces. Our primary requirement
here is to allow 10.1.2.0 devices access to the proxy server, so that they can access the Internet. However, any internal device is allowed to access the DMZ. These devices should be
translated into 192.168.1.101 to 192.168.1.199. As we did with the outside interface, we’ll
use the 192.168.1.200 address for PAT, just in case more than 99 people are accessing it at
once. So our commands here are very similar, except that we also have a requirement for the
Web server to initiate connections into the inside network. This will require an additional
static command:
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
nat (inside) 2 0 0
global (dmz) 2 192.168.1.101-192.168.1.199
global (dmz) 2 192.168.1.200
static (inside,dmz) 192.168.1.2 10.1.1.50 netmask 255.255.255.255
Now you can see the importance of having a NAT ID. This arbitrary number tells the PIX
Firewall exactly which addresses we want to translate when there are multiple outbound interfaces. As you will see in the next pair of interfaces, it also lets us tell the PIX Firewall which global addresses we want to use when there are multiple inbound interfaces.
Notice in the configuration above that the nat statement still uses the inside interface, but the
corresponding global statements use the DMZ interface. In all of these cases, the nat statement
is used on the higher-security interface, while the global statements are used on lower-security
interfaces.
80
Chapter 2
PIX Firewall Configuration
Configuring NAT between the DMZ and Outside Interfaces
Next, we’ll configure NAT between the DMZ and the outside interface. To fulfill the requirement that the proxy server be the only device allowed to initiate connections out, we’ll choose
yet another arbitrary NAT ID and use another pair of nat and global statements. To allow any
external device to initiate connections to the Web server, we’ll need another static command.
The commands are as follows:
PIX(config)# nat (dmz) 3 192.168.1.25 255.255.255.255
PIX(config)# global (outside) 3 37.20.5.4
PIX(config)# static (dmz, outside) 37.20.5.3 192.168.1.75 netmask
➥255.255.255.255
PIX(config)#
Here again, we see that the interface with the highest security level is now the DMZ interface,
so the nat statement is on the DMZ interface, while the global statement is on the outside
interface. Also, by specifying just the proxy server and using a 32-bit mask (255.255.255.255),
we have prevented any other host on that network from creating a translation slot in the PIX
Firewall.
Outbound Connections from the DMZ
While it might seem safe to allow any device on your DMZ to initiate outbound connections to
the Internet, this isn’t necessarily a good idea. Despite the fact that the network is more trusted
than the Internet, it’s not totally trusted. As an example of what can go wrong, consider the
NIMDA virus and variants from September 2001. This outbreak was particularly annoying,
because the virus had several delivery mechanisms. Aside from the often-used Outlook e-mail
macros, it could also spread from IIS Web server to IIS Web server.
The moral of the story is that a Web server initiating a connection to the Internet is highly suspicious. Unless there is a well-documented need for this privilege, turn it off.
Reviewing the Configuration
We’ll wrap up this example by showing the relevant part of the configuration (to save space,
we’ve omitted the irrelevant information):
PIX# wr t
Building configuration...
: Saved
Configuring NAT and PAT
81
:
PIX Version 6.0(1)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 dmz security10
hostname PIX
interface ethernet0 auto
interface ethernet1 auto
interface ethernet2 auto
ip address outside 37.20.5.2 255.255.255.240
ip address inside 10.1.0.1 255.255.255.0
ip address dmz 192.168.1.1 255.255.255.0
global (outside) 1 37.20.5.5-37.20.5.13
global (outside) 1 37.20.5.14
global (outside) 3 37.20.5.4
global (dmz) 2 192.168.1.101-192.168.1.199
global (dmz) 2 192.168.1.200
nat (inside) 1 10.1.1.0 255.255.255.0 0 0
nat (inside) 2 0.0.0.0 0.0.0.0 0 0
nat (dmz) 3 192.168.1.25 255.255.255.255 0 0
static (dmz,outside) 37.20.5.3 192.168.1.75 netmask 255.255.255.255 0 0
static (inside,dmz) 192.168.1.2 10.1.1.50 netmask 255.255.255.255 0 0
route inside 10.1.1.0 255.255.255.0 10.1.0.3 1
route inside 10.1.2.0 255.255.255.0 10.1.0.2 1
: end
[OK]
PIX#
Notice the routing statements required to make the connectivity work. Also notice that we
have configured two different PAT addresses on the outside interface. This functionality was
implemented in version 5.3. It works great, but it can be confusing. Be careful that you don’t try
to assign two PAT addresses to the same NAT ID.
Configuring Six Interfaces
Figure 2.4 shows the setup for our next example, which is much more complex than the one
described in the previous section. Here, we have an organization with an internal network that
is connected to the Internet and two partners. We also have a DMZ, which hosts servers that
our business partners use, and we have a dedicated remote-access network, where users can dial
in from home and access services, such as their e-mail.
82
Chapter 2
FIGURE 2.4
PIX Firewall Configuration
Complex six-interface NAT scenario
Remote access server
PSTN
192.168.2.0/24
10.0.0.0/8
Access
ISP
PIX
Inside
Outside
.1
Internet
200.199.187.0/30
.1
DMZ
Router
192.168.1.0/24
Router
Router
16.0.0.0/8
Partner A
15.0.0.0/8
Partner B
We want to implement the following basic rules:
Hosts on the inside interface can access anything (we assume our partners have firewalls of
their own, which prevent us from arbitrarily accessing their equipment).
Only a small group of hosts on the 10.6.98.0 /24 inside interface need to access the remoteaccess segment, so they can use a shared bank of 32 modems to dial out.
Hosts on the partner networks can access the DMZ.
Hosts on the partner networks cannot access each other or use our Internet connection. We
assume they have their own ISP.
Mobile users on the access segment can access anything except the inside interface. That is
restricted to the e-mail server on 10.1.1.100.
Hosts on the Internet cannot initiate connections into any other network.
Configuring NAT and PAT
83
To implement this, we will assign our interfaces the following security level values:
Interface
Security Level
Inside
100
Access
80
Partner A
40
Partner B
40
DMZ
20
Outside
0
Although we assigned all of these values, except the inside network, arbitrarily, the relative
numbers are important. They immediately accomplish several of the goals. Primarily, by assigning the same security value to both customer networks, we make it impossible for those two
interfaces to communicate directly with one another. And the order of interfaces from highest
to lowest allows us to configure the nat and global statements appropriately.
We’ll start our configuration by addressing access to the interfaces in order of security value,
from the lowest to the highest. It is critical that you remember that NAT is always between a
pair of interfaces.
With six interfaces, we potentially have a lot of pairs of interfaces, but each pair does not
require its own NAT ID. In fact, giving each its own NAT ID would create problems (although
it’s possible), because the global ranges cannot overlap and the nat ranges cannot be identical.
Having several smaller ranges is much less efficient. So in the sections below, we will combine the
statements into groups based on the appropriate NAT IDs for efficiency and ease of understanding, but it does not change the fact that NAT operates only between a given pair of interfaces.
As an example, if a host on the inside network were translated to 192.168.2.50 for traffic to
the DMZ interface, that same host could be translated to a completely different IP address when
it conversed with devices through another PIX interface. In this case, that single host would
have multiple translation slots.
Configuring the Outside Interface
The outside interface, of course, has the lowest security value. For this interface, we will use one
PAT address for all clients coming from the access and inside networks, as shown below:
PIX(config)# nat (inside) 1 10.0.0.0 255.0.0.0
PIX(config)# nat (access) 1 192.168.2.0 255.255.255.0
PIX(config)# global (outside) 1 interface
PIX(config)#
84
Chapter 2
PIX Firewall Configuration
Here we demonstrate multiple nat statements paired with a single global statement, which
is the opposite of the three-interface scenario described in the previous section. Note that neither
of our partners or the DMZ hosts is allowed to use our Internet connection, but if access were
allowed, we could easily add three more nat statements. (Note that it is impossible to combine
these into one statement by aggregating addresses, because you still must specify the interface,
and there are three different interfaces.)
Configuring the DMZ Interface
The next highest interface is the DMZ. Since everyone except the outside interface is allowed to
access these hosts, we would normally have four nat commands that explicitly define their
respective networks and one global command. However, the nat commands for the inside and
access segments are already assigned explicitly with a NAT ID of 1. The problem is that you
cannot specify the same network in another nat command, because PIX will return a “duplicate
NAT entry” error. Our solution is to shorten the subnet mask to include all networks for the
inside and access segments, as shown below:
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
nat (inside) 2
nat (access) 2
nat (partnera)
nat (partnerb)
global (dmz) 2
0 0
0 0
2 16.0.0.0 255.0.0.0
2 15.0.0.0 255.0.0.0
192.168.1.64-192.168.1.254
Normally this would be nominally less secure because it is theoretically possible to do spoofing. But because this is a DMZ segment, we will accept that very small risk and leave our explicit
(and correct) statement for use in the NAT ID 1 group that allows access to the Internet.
That takes care of our nat statements. For the global command, we reserve the first 62
addresses for servers on the DMZ segment, and we use the rest for our global NAT pool. It is
also important to note that each of these four interfaces with a nat statement must have a higher
security value than the interface with the global statement.
Configuring the Partner Interfaces
The next interfaces are our partner interfaces. Here, it is appropriate to reuse the nat statements
from NAT ID 1, which permit only the inside and access segments, and use the interface
addresses to do PAT. Thus, our statements are as follows:
PIX(config)# global (partnera) 1 interface
PIX(config)# global (partnerb) 1 interface
PIX(config)#
Configuring the Access Interface
Access to the access segment is next. Here we will use another NAT ID to distinguish between
the two we are already using on the inside interface. And since there are only 32 modems, there’s
Configuring Routing
85
no point to using more than 32 addresses in the global pool, because we can have only 32 simultaneous users.
PIX(config)# nat (inside) 3 10.6.98.0 255.255.255.0
PIX(config)# global (access) 3 192.168.2.64-192.168.2.95
PIX(config)#
Configuring the Inside Interface
Finally, we need to allow access to the inside network, but the only connectivity permitted here
is from the access segment to an e-mail server, which requires only a single static statement.
This statement allows hosts to access the server using a global address of 192.168.2.63. Therefore, it is important that this address be in the remote user’s DNS or a static hosts file.
PIX(config)# static (inside,access) 192.168.2.63 10.1.1.100 netmask
➥255.255.255.255
PIX(config)#
The static command doesn’t actually allow access, of course. It allows the
specified host only to create a translation slot from a lower-security interface to
a higher one. To actually allow access, you must combine this statement with
an access-list or conduit command. These commands will be discussed in
the next chapter.
Configuring Routing
In most cases, your network is made up of a number of subnetworks. There might be one or
more at each branch office, or you might have the network configured so that each floor or each
closet gets its own IP subnet. In any case, there are likely several internal routers. The hosts on
most, if not all, of these subnets will need access to external networks, such as business partners
or the Internet.
These internal and external networks are, of course, separated by the PIX Firewall, and so
routing on the firewall becomes an issue. Typically, the internal routers use an internal routing
protocol, such as OSPF or EIGRP, to communicate Network layer reachability information
(NLRI). Presumably, in such a case, each internal network knows about all the other internal
networks. They also typically use a default route for destinations they don’t know about. In
most of your internal networks, this default route points to the PIX Firewall, which means all
traffic leaving the network goes through the PIX Firewall. The PIX Firewall, in turn, generally
needs a default route to which it can deliver the packets that pass inspection. Recall from the
previous chapter that if the traffic doesn’t pass through the firewall, it can’t possibly offer any
protection.
86
Chapter 2
PIX Firewall Configuration
In this section, we will cover the commands used to configure IP routing on the PIX Firewall.
Our goals are to configure the PIX Firewall
To generate a default route so that internal routers know where to send packets destined
for the external networks.
So that it knows where to send packets to internal destinations.
To route multicasting traffic without requiring you to configure GRE tunnels to pass multicast traffic.
Configuring Dynamic Routing
Unfortunately as of version 6.2 of the operating system, the only way for the PIX Firewall to
communicate with other routers is via the RIP, and even then, all it can do is generate a single
default route and listen for other routes. So, in most circumstances, you might be better off configuring static default routes on your internal Cisco routers that point to the PIX Firewall’s
inside interface. Another option is to allow the PIX Firewall to generate the default route via
RIP, and then redistribute it into a more useful, stable, and secure routing protocol on the Cisco
routers before the default route is passed on to the rest of the network.
Generating a Default Route
To generate a default route using RIP, you use the rip command. The syntax of the rip command is as follows:
PIX(config)# rip ?
usage: [no] rip <if_name> default|passive [version <1|2>]
➥ [authentication <text|md5> <key> <key id>]
PIX(config)#
Here’s an example of a rip command:
PIX(config)# rip inside default version 2
PIX(config)#
This command sends the route 0.0.0.0 mask 0.0.0.0 to the multicast address 224.0.0.9 on
the inside interface. This will be received and processed by all RIPv2-speaking routers.
Specifying version 1 of RIP will cause the same route to be sent to the broadcast address
255.255.255.255. This is illustrated below, using the output of the debug rip command:
PIX# debug rip
RIP trace on
PIX# configure terminal
PIX(config)# rip inside default version 1
PIX(config)# exit
Configuring Routing
87
PIX# 8: RIP: interface inside sending v1 update to 255.255.255.255
PIX# configure terminal
PIX(config)# rip inside default version 2
PIX(config)# exit
PIX# 9: RIP: interface inside sending v2 update to 224.0.0.9
PIX# no debug rip
RIP trace off
PIX#
Although using RIP to broadcast the default route automates the route-learning
process and is extremely easy to configure, it is less secure than using static
routes. Distance-vector protocols such as RIP are also more susceptible to routing loops than their link-state cousins.
Configuring the PIX Firewall to Route Packets
The next issue to consider is configuring the PIX Firewall so that it knows where to send its
packets.
If either the inside or outside networks are using the RIP protocol, we can configure the PIX
Firewall to listen to those updates so that it learns its routes dynamically. This is accomplished
with the rip command, using the passive keyword instead of the default keyword. For
instance, to configure the PIX Firewall to listen for RIP updates on the inside interface, you
would use the following command:
PIX(config)# rip inside passive
PIX(config)#
You can also specify the version and enable authentication with this command.
Configuring Static Routing
The alternative to using dynamically learned routes is to manually configure static routes. These
routes are configured using the route command, which has the following syntax:
PIX(config)# route ?
usage: [no] route <if_name> <foreign_ip> <mask> <gateway> [<metric>]
PIX(config)#
As an example, consider the network shown in Figure 2.5. In this network, we see three internal networks: the directly connected user segment, a remote-user segment, and the WAN link
that connects them. The outside interface is connected to our ISP’s router, which leads to the
Internet, and the DMZ interface has a handful of servers.
88
Chapter 2
FIGURE 2.5
PIX Firewall Configuration
PIX Firewall routing example
Servers
Local office
192.168.1.0/24
DMZ
PCs
Inside
10.1.1.0/24
.2
Router
ISP
Outside
.1
.6
Internet
202.198.25.4/30
PIX
Router
10.1.3.0/30
Router
Remote office
10.1.2.0/24
PCs
Before we begin entering commands, let’s discuss what routes are needed. First, the PIX Firewall automatically enters directly connected networks in its routing table, so no manual entry
is needed for the local-user segment, the DMZ, or the network attached to the outside interface.
You can use the show route command to see the routing table, as follows:
PIX# show route
inside 10.1.1.0 255.255.255.0 10.1.1.1 1 CONNECT static
DMZ 192.168.1.0 255.255.255.0 192.168.1.1 1 CONNECT static
outside 202.198.25.4 255.255.255.252 202.198.25.5 1 CONNECT static
PIX#
Notice that all three of the directly connected networks shown in Figure 2.5 are listed in the
routing table shown here.
Configuring Routing
89
Next, the PIX Firewall needs to know how to get to the remote-user segment. This will
require a manual route. Since we assume there is no business need for external hosts to communicate with the routers that connect the local and remote offices, we do not need a route to
the WAN subnet.
Last, we will need a default route pointing to the ISP’s router. This route also requires a manual entry.
Our commands to configure routing on the PIX Firewall in Figure 2.5 are as follows:
PIX(config)# route inside 10.1.2.0 255.255.255.0 10.1.1.2
PIX(config)# route outside 0.0.0.0 0.0.0.0 202.198.25.6
PIX(config)#
After entering these commands, we can check the routing table again to verify our changes.
PIX# show route
outside 0.0.0.0 0.0.0.0 202.198.25.6 1 OTHER static
inside 10.1.1.0 255.255.255.0 10.1.1.1 1 CONNECT static
inside 10.1.2.0 255.255.255.0 10.1.1.2 1 OTHER static
DMZ 192.168.1.0 255.255.255.0 192.168.1.1 1 CONNECT static
outside 202.198.25.4 255.255.255.252 202.198.25.5 1 CONNECT static
PIX#
We see that the two routes have been added as expected. Also notice that, while the routes
are all static, the “static” routes are designated by the keyword OTHER, and the directly connected networks are designated by the keyword CONNECT.
One other point of interest in the output of the show route command is that the directly connected interfaces have the same metric (1) as the static routes. This might seem a little unusual
if you’re used to working with the IOS, where directly connected interfaces always have a metric
of 0 and static routes with a next-hop IP address have a metric of 1. This curious situation might
lead you to believe that it’s possible to create all sorts of bizarre routing situations on the PIX
Firewall, where traffic destined for directly connected interfaces could take a nonoptimal path.
To illustrate that this isn’t the case, let’s see what happens when we attempt to misconfigure the
PIX Firewall shown in Figure 2.5.
PIX# configure terminal
PIX(config)# route dmz 10.1.1.0 255.255.255.0 192.168.1.2
Route already exists
PIX(config)# route dmz 10.1.1.0 255.255.255.0 192.168.1.2
Route already exists
PIX(config)# route inside 10.1.2.0 255.255.255.0 10.1.1.3
cannot add route entry
Type help or '?' for a list of available commands.
PIX(config)# route inside 10.1.2.0 255.255.255.0 10.1.1.3
PIX(config)# exit
1
2
1
2
90
Chapter 2
PIX Firewall Configuration
PIX# show route
outside 0.0.0.0 0.0.0.0 202.198.25.4 1 OTHER static
inside 10.1.1.0 255.255.255.0 10.1.1.1 1 CONNECT static
inside 10.1.2.0 255.255.255.0 10.1.1.2 1 OTHER static
inside 10.1.2.0 255.255.255.0 10.1.1.3 2 OTHER static
DMZ 192.168.1.0 255.255.255.0 192.168.1.1 1 CONNECT static
outside 202.198.25.4 255.255.255.252 202.198.25.5 1 CONNECT static
PIX#
First, we attempt to reroute traffic destined for the local network on the inside interface out
through the DMZ interface, with the same metric as the inside interface. PIX Firewall points out
our mistake and rejects our command. Next, we try the same command, but with a higher metric.
A higher metric on an IOS-based router would tell the router to use this route only if the first route
fails. However, PIX Firewall doesn’t like this either. While these are unusual, but potentially useful, configurations, keep in mind that the PIX Firewall consistently foregoes features in favor of
security.
Next, we try to tell the PIX Firewall about an alternative route to the remote-user network, which
is not directly connected. By assigning an equal-cost route (both routes have a metric of 1), we might
expect PIX Firewall to load-balance the traffic destined for 10.1.2.0 /24 between both the 10.1.1.2
and 10.1.1.3 (not pictured in Figure 2.5) routers. But alas, the PIX Firewall isn’t too keen on load
balancing either, although the error message it returns is somewhat less precise.
Finally, we try the same route again, but with a higher metric. The PIX Firewall adds this
route to its table, as shown by the show route command.
The following are important points to remember about PIX Firewall routing:
The PIX Firewall is not a router.
You can’t achieve load balancing by manipulating route metrics.
Static routes are more secure than those learned via RIP.
While the routing scenarios discussed here are common, you might need a far
more complex routing environment. Thus, it is not necessarily appropriate to
replace a full-featured Cisco router with a PIX Firewall just because you need
more security. This is particularly true if your network’s routing is complex or
if you wish to enable quality of service (QoS) or use features such as policy
routing.
Configuring Multicast Routing
The PIX Firewall, in operating system version 6.2 or higher, supports Stub Multicast Routing
(SMR), which enables it to pass multicast traffic between interfaces. The PIX Firewall acts as an
IGMP proxy agent, which forwards IGMP messages from hosts to the upstream multicast
Configuring Routing
91
router. The PIX Firewall does not participate in a dynamic multicast routing protocol such as
DVMRP or PIM.
The SMR feature allows hosts that need to receive multicast traffic from a multicast router,
which is on another interface on the PIX Firewall, without having to create a GRE tunnel. The
PIX Firewall will forward IGMP reports from downstream hosts to the upstream multicast
router and it will forward multicast traffic from the upstream multicast router to the downstream hosts.
By default the PIX Firewall will not forward multicast traffic, so you will need to enable the
interface to forward multicast traffic by using the multicast interface command followed
by the interface name. When you enter this command, you are placed in Multicast Configuration mode and the prompt changes to (config-multicast)#. From this mode, you can only
enter igmp commands to configure multicast parameters. The following is an example of the
Multicast mode:
PIX(config)# multicast interface outside
PIX(config-multicast)# ?
igmp
Configure IGMP on an interface
PIX(config-multicast)# igmp ?
Usage: [no] igmp max-groups <number>
[no] igmp forward interface <interface_name>
[no] igmp access-group <acl-id>
[no] igmp version <1|2>
[no] igmp join-group <group>
[no] igmp query-interval <seconds>
[no] igmp query-max-response-time <seconds>
PIX(config-multicast)#
Now that the interface will forward multicast traffic on the interface, we need to enable the
forwarding of all IGMP host Report and Leave messages received on the interface. The igmp
forward interface command is used to specify the interface where the upstream multicast
router is located so it can forward the IGMP messages out that interface. The IGMP commands
are only available in the Multicast Configuration mode with the exception of the show igmp
and clear igmp commands.
Optionally you can configure the PIX Firewall to join a multicast group and received multicast traffic for that group. This might be used for a client that might not be able to respond via
IGMP but still requires the multicast stream. The command to join a multicast group is igmp
join-group followed by a Class D IP address to join. These Class D IP addresses are reserved
for multicast traffic and are in the range from 224.0.0.0 to 239.255.255.255. Additionally, you
can control which multicast traffic will be allowed by using the igmp access-group command
followed by the name of an access list.
If the multicast traffic source in on a higher security level interface from the hosts receiving
the stream, you must specifically configure the PIX Firewall to forward traffic from the source.
The command to create a static route from the source to the multicast group address is mroute,
92
Chapter 2
PIX Firewall Configuration
followed by the source address and mask and inbound interface name, then the destination
address and mask and outbound interface name. The following is an example of using the
mroute command:
PIX(config)# mroute 10.1.1.1 255.255.255.255 outside 225.1.1.1
➥255.255.255.255 inside
PIX(config)#
The other IGMP commands are used to customize the multicast on an interface. The igmp
version command is used to specify the IGMP version to use, with the default being 2. The igmp
query-interval command configures the number of seconds between IGMP query messages.
The maximum query response time can be used only with IGMP version 2 and can be configured
by using the igmp query-max-response-time command. The igmp max-groups command is
used to configure the maximum number of groups allowed to be active on the interface.
The PIX Firewall has some show and debug command that can be used to view and troubleshoot the multicast feature. The show multicast command is used to view the multicast routing configuration and the show igmp is used to view the IGMP parameters. Both of these
commands can take an optional interface parameter followed by the name of the interface to
view. The show mroute command will allow you to view the static and dynamic multicast
routes active on the PIX Firewall. The only debug commands available are debug igmp, which
enables debugging of IGMP events, and debug mfwd, which enables the debugging for multicast
forwarding events.
Summary
In this chapter, we began by explaining what information you need to gather before configuring
a PIX Firewall. Then we discussed the common global commands used to configure services such
as DNS, DHCP, remote access, and logging, and how to set the system clock and NTP support.
Next, we discussed basic interface configuration, as well as advanced, multiple-interface configuration. Following that, we covered Network Address Translation (NAT) and Port Address
Translation (PAT) in detail. Finally, we described how to configure the PIX Firewall to share a
default route with other routers and how to receive information from other routers.
Exam Essentials
Know NAT and PAT inside and out. You need to have a very solid grasp of the NAT and
PAT operations, including the difference between static and dynamic NAT, what values you
would expect to see in packets passing through the PIX Firewall, and how to configure both
NAT and PAT.
Hands-On Lab
93
Understand how to configure routing on the PIX Firewall. The PIX is not a router, but it has
limited IP and multicast routing capabilities. Know how to configure RIP to send and receive
routes, how to set a static route, and how to get the PIX Firewall to forward multicast routing
without GRE tunnels.
Understand the security level value. Know what the security level value means in relation to
other interfaces and how the ASA (Adaptive Security Algorithm) uses it. Also, know what the
default values are for different names and interfaces and how to change them.
Know how to configure PIX Firewall interfaces. Know how to set IP addresses, MTU, and
layer 2 information, such as speed and duplex. Also know how to set the interface name.
Know the configuration basics. Be able to configure logging, DHCP server, and remote access
and to set the system clock, NTP support, and hostname. Know what other processes depend
on this information.
Key Terms
Before you take the exam, make sure you’re familiar with these terms:
identity NAT
outside local
inside global
Port Address Translation (PAT)
inside local
port redirection
Network Address Translation (NAT)
Stub Multicast Routing (SMR)
outside global
Hands-On Lab
In this section, we will put together some of what we have learned in this chapter. This handson lab section will be configuring a PIX Firewall to protect a small branch office. We will configure the outside interface to receive its IP address from an outside DHCP server. We will also
configure DHCP server on the inside interface and pass the DNS and domain-name DHCP
options from the outside DHCP server to internal DHCP clients. We will allow access to the
Internet for internal clients and also allow telnet access to the PIX Firewall from any host on the
internal network. We will also be configuring the system clock, NTP support, domain-name,
and logging settings.
94
Chapter 2
PIX Firewall Configuration
The following graphic displays the physical layout of the PIX Firewall.
PIX
ISP
Inside Clients
DHCP
Server
This section includes the following labs:
Lab 2.1: Enable the DHCP client on the outside interface.
Lab 2.2: Configure the inside IP address.
Lab 2.3: Enable the DHCP server on the inside interface using the DHCP options from the
outside interface.
Lab 2.4: Configure PAT on the outside interface for internal client gaining access to the
Internet.
Lab 2.5: Configure telnet access on the inside interface, system clock, NTP support, and
loggings settings.
Lab 2.6: Verifying proper operation of the configuration.
LAB 2.1
Enable the DHCP client on the outside interface.
1.
Enter the command to change the hostname to PIX.
2.
Enable the outside interface (ethernet0) using automatically determined speed and duplex
settings.
3.
Enable the DHCP client on the outside interface and use the setroute option to set the
default route.
Hands-On Lab
95
LAB 2.2
Configure the inside IP address.
1.
Enable the inside interface (ethernet1) using automatically determined speed and duplex
settings.
2.
Configure the IP address of 192.168.21.254 with a mask of 255.255.255.0 on the inside interfaces.
LAB 2.3
Enable the DHCP server on the inside interface using the DHCP options from the outside interface.
1.
Create the pool of 50 DHCP IP addresses.
2.
Use the DHCP options from the outside interface.
3.
Enable the DHCP server on the inside interface.
LAB 2.4
Configure PAT on the outside interface for internal client gaining access to the Internet.
1.
Specify which IP addresses will be translated.
2.
Use the outside interface as the IP address to use for PAT.
LAB 2.5
Configure telnet access on the inside interface, system clock, NTP support, and
loggings settings.
1. Enable telnet access to the inside interface.
2. Update the system clock and set the time zone to CDT.
3. Enable NTP support to the NTP server at IP address 198.60.22.240 (time.xmission.net).
4. Send SYSLOG messages to IP address 192.168.21.250.
96
Chapter 2
PIX Firewall Configuration
LAB 2.6
Verifying proper operation of the configuration.
1. Enter the command to view the IP addresses on the PIX Firewall.
2. Enter the command to make sure DHCP is working.
3. Enter the command to ensure the clock is configured correctly.
4. Enter the command to check NTP and logging status.
Answer to Lab 2.1
pixfirewall# conf t
pixfirewall(config)# hostname PIX
PIX(config)# interface ethernet0 auto
PIX(config)# ip address outside dhcp setroute
dhcp client start discover: wait until failover switch to active
PIX(config)# ....
Allocated IP address = 175.172.140.225, netmask = 255.255.255.0, gateway =
175.172.140.1
PIX(config)# exit
PIX#
Your output will differ from the example above due to the presence and configuration of a DHCP server.
Answer to Lab 2.2
PIX# conf t
PIX(config)# interface ethernet1 auto
PIX(config)# ip address inside 192.168.21.254 255.255.255.0
PIX(config)# exit
PIX#
Answer to Lab 2.3
PIX# conf t
PIX(config)# dhcpd address 192.168.21.1-192.168.21.50 inside
Hands-On Lab
PIX(config)# dhcpd auto_config outside
PIX(config)# dhcpd enable inside
PIX(config)# exit
PIX#
Answer to Lab 2.4
PIX# conf t
PIX(config)# global (outside) 1 interface
Warning: Start and End addresses overlap with broadcast address.
outside interface address added to PAT pool
PIX(config)# nat (inside) 1 0 0 0
PIX(config)# exit
PIX#
Answer to Lab 2.5
PIX# conf t
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
PIX#
telnet 0 0 inside
clock set 14:24:00 28 April 2003
clock timezone CDT -6
clock summer-time CDT recurring
ntp server 198.60.22.240 source outside
logging host inside 192.168.21.250
logging on
exit
Answer to Lab 2.6
PIX# conf t
PIX(config)# show ip address
System IP Addresses:
ip address outside 175.172.141.246 255.255.255.0
ip address inside 192.168.21.254 255.255.255.0
Current IP Addresses:
ip address outside 175.172.141.246 255.255.255.0
ip address inside 192.168.21.254 255.255.255.0
97
98
Chapter 2
PIX Firewall Configuration
PIX(config)# show dhcpd
dhcpd address 192.168.21.1-192.168.21.50 inside
dhcpd lease 3600
dhcpd ping_timeout 750
dhcpd auto_config outside
**auto_config dns 175.168.80.3 175.167.96.38
**auto_config wins 175.167.81.34 155.168.134.33
**auto_config domain sybex.com
dhcpd enable inside
PIX(config)# show clock det
15:16:15.867 CDT Mon Apr 28 2003
Time source is NTP
Summer time starts 02:00:00 CDT Sun Apr 6 2003
Summer time ends 02:00:00 CDT Sun Oct 26 2003
PIX(config)# show ntp status
Clock is synchronized, stratum 5, reference is 135.166.127.25
nominal freq is 250.0000 Hz, actual freq is 249.9985 Hz, precision is 2**18
reference time is C2580ACE.711DCB0F (15:17:18.441 CDT Mon Apr 28 2003)
clock offset is 0.0399 msec, root delay is 33.49 msec
root dispersion is 8.29 msec, peer dispersion is 3.27 msec
PIX(config)# show logging
Syslog logging: enabled
Facility: 20
Timestamp logging: disabled
Standby logging: disabled
Console logging: disabled
Monitor logging: disabled
Buffer logging: disabled
Trap logging: disabled
History logging: disabled
PIX(config)# exit
PIX#
Your output will differ from the example above due to the presence and configuration of a DHCP server and reachability of the timeserver.
Review Questions
99
Review Questions
1.
You wish to configure a PIX Firewall so that an HTTP request packet can travel from the outside
interface to a Web server on the DMZ interface. To configure NAT, which commands would be
appropriate?
A. static
B. nat and global
C. This cannot be done.
D. There is not sufficient information given to answer this question.
2.
You are using telnet to administer your PIX Firewall. You wish to see the contents of the log as
they are generated in real time, so you enter the commands logging on and logging console.
However, you do not see the logs you expect. What is the most likely cause?
A. You have an ACL blocking the logs’ transmission over the telnet session.
B. You neglected to enter the logging monitor command.
C. The errors have been sent to a SYSLOG collector instead.
D. Your buffers are full and must be cleared before additional log entries can be processed.
3.
You configure a static NAT entry on a PIX Firewall, but when you attempt to send traffic
through the PIX Firewall, the traffic is blocked. What is the most likely cause?
A. You are out of global addresses.
B. You didn’t configure the fixup command.
C. You didn’t configure an inbound ACL.
D. The xlate table has been paused and must be resumed.
4.
Which of the following can you do by default? (Choose all that apply.)
A. Ping the inside interface
B. Ping the outside interface
C. Ping a host on the outside interface from a host on the inside interface
D. Ping a host on the inside interface from a host on the outside interface
E. None of the above
5.
You type the command nat (inside) 0 10.1.1.5 255.255.255.255. What does this do?
A. Prevents host 10.1.1.5 from creating a translation slot
B. Prevents host 10.1.1.5 from being translated, but still allows the host through the PIX
Firewall
C. Associates the host 10.1.1.5 with the corresponding global group 0
D. Allows host 10.1.1.5 to be translated into any global address
100
6.
Chapter 2
PIX Firewall Configuration
What is the first 100BaseT interface on a PIX Firewall known as?
A. Ethernet0
B. FastEthernet0
C. Ethernet1
D. FastEthernet1
7.
Which of these commands configures PAT to use the 10.1.1.1 address?
A. global (outside) 1 10.1.1.1 pat
B. global (outside) 1 10.1.1.1
C. pat (outside) 1 10.1.1.1
D. nat (outside) 1 10.1.1.1 pat
8.
An architect has given you a list of commands to use to configure a PIX Firewall. Two of these
commands are as follows:
ip address inside 192.168.1.2 255.255.255.0
nat (inside) 1 192.168.1.0 255.255.255.240 0 0
What will happen when you enter these commands?
A. The PIX Firewall will reject the second command because the mask does not match.
B. The PIX Firewall will reject the second command because the interface does not match.
C. Only the hosts 0 through 15 will be allowed to create translation slots.
D. Only the hosts 0 through 31 will be allowed to create translation slots.
9.
The PIX Firewall supports which type of load balancing?
A. Equal cost
B. Unequal cost
C. Unequal cost load balancing, but only with EIGRP
D. None of the above
10. How many inside interfaces can you have?
A. One to six
B. Zero to six
C. Zero or one
D. Exactly one
Answers to Review Questions
101
Answers to Review Questions
1.
D. The outside interface is usually 0, but it could be set to something higher than the DMZ interface. Alternatively, the DMZ interface could be set to 0. The answer depends on which interface
is higher.
2.
B. The logging monitor command directs output to telnet sessions.
3.
C. Even with a static NAT entry, inbound traffic is blocked by default, and an ACL must be used
to explicitly permit the traffic.
4.
A. For security reasons, all others are denied by default.
5.
B. This is identity NAT because the PIX Firewall it will not translate traffic from host 10.1.1.5.
6.
A. The PIX starts numbering interfaces at 0, but refers to all Ethernet-based interfaces as “Ethernet,” regardless of interface speed.
7.
B. PAT is configured by putting only one address in the global NAT pool.
8.
C. You can assign any legal mask. The 255.255.255.240 mask creates a subnet with 16
addresses, starting at 0.
9.
D. The PIX Firewall does not support load balancing.
10. C. You can rename the inside interface so that there are no interfaces, but you cannot have two
or more interfaces with the same name.
Chapter
3
ACLs, Filtering,
Object Grouping,
and AAA
THE FOLLOWING TOPICS ARE COVERED IN
THIS CHAPTER:
Creating and using ACLs
Converting Conduit commands to ACLs
Configuring URL filtering using Websense and N2H2
Using the Point-to-Point Protocol over Ethernet
(PPPoE) client
Configuring and using group objects
Configuring authentication, authorization, and
accounting (AAA)
Installing CiscoSecure Access Control Server for
Windows 2000/NT (CSNT)
Overview of using downloadable PIX ACLs
Using TACACS+ for command authorization
In the previous chapters, we’ve mentioned access control several
times in passing. This chapter is devoted to the various ways you
can identify and block traffic from the Network layer through the
Application layer.
We will look at the specifics of access control lists (ACLs) on the PIX Firewall and how to
convert conduit commands to access-list commands. Next we’ll show you how the PIX Firewall
can filter URLs using a Websense or N2H2 server, which are popular third-party products. We
will next discuss how to configure Point-to-Point Protocol over Ethernet (PPPoE) on the PIX
Firewall.
We will cover the configuration of object grouping and installation and configuration of an
authentication, authorization, and accounting (AAA) server using CiscoSecure Access Control
Server (ACS). Finally, we will talk about downloadable PIX ACLs and how to configure and use
them on a PIX Firewall.
Using PIX Firewall ACLs
The PIX Firewall operating system has a tiny fraction of the options and functionality for an
ACL that a Cisco IOS router has. But then, those options and functionality are not really necessary. If you think about it, all the functionality in Cisco IOS ACLs is basically an attempt to
emulate a true stateful firewall. Almost all of these features are built into the PIX’s Adaptive
Security Algorithm (ASA).
ACLs on the PIX Firewall are fairly new. They are, for the most part, meant to replace the
conduit and outbound commands. ACLs also select which IP traffic IPSec protects and which
it does not protect. In PIX Firewall 5.0 or higher, the access-list command replaces both of
these statements. Unlike IOS ACLs, which can be bidirectional, PIX Firewall operating system
ACLs affect only traffic inbound to the PIX Firewall on a given interface. Thus, an accesslist statement must be bound to the inside and outside interfaces to control bidirectional traffic using the access-group command.
Recall from Chapter 2, “PIX Firewall Configuration,” that by default, all traffic
from a lower security interface to a higher security interface is denied, but a
static statement could be created to allow certain traffic in. Conversely, all
traffic from higher security interfaces to lower security interfaces is permitted
by default, but the outbound command can be used to restrict certain traffic.
Using PIX Firewall ACLs
105
In fact, there are quite a few differences in the way ACLs are processed on the PIX Firewall
versus how they are processed in the Cisco IOS, beyond the differences in features. The primary
difference is that the order of a list is not important on the PIX Firewall. In Cisco IOS ACLs, the
rules are processed sequentially and the first match is the rule that was used. In the PIX Firewall,
when packets are evaluated against an ACL, they always take the longest match (the longest
subnet mask).
In the following sections, we will look at the syntax involved with creating ACLs on the PIX
Firewall, applying a PIX ACL, and converting conduits to ACLs.
Creating a PIX ACL
The syntax for the PIX Firewall access-list command is as follows:
PIX(config)# access-list ?
Usage: [no] access-list compiled
[no] access-list <id> compiled
[no] access-list <id> deny|permit <protocol>|object-group
➥<protocol_obj_grp_id>
<sip> <smask> | object-group <network_obj_grp_id>
[<operator> <port> [<port>] | object-group <service_obj_grp_id>]
<dip> <dmask> | object-group <network_obj_grp_id>
[<operator> <port> [<port>] | object-group
➥<service_obj_grp_id>]
[no] access-list <id> deny|permit icmp
<sip smask> | object-group <network_obj_grp_id>
<dip dmask> | object-group <network_obj_grp_id>
[<icmp_type> | object-group <icmp_type_obj_grp_id>]
PIX(config)# access-list
As you can see, the syntax of the access-list command closely resembles the syntax of the
IP-extended ACL in the Cisco IOS. The id value can be either a number or a string. The
protocol value is commonly IP, TCP, UDP, or ICMP. The source and destination IP address,
mask, and port are much the same as well. One notable difference here is that the source mask
is actually a regular mask and not the wildcard bits used in Cisco IOS ACLs. The operator
value is also similar and is usually eq followed by a number or keyword, such as www, telnet,
or ftp, where the number can be from 1 to 254 to represent other protocol numbers.
Unlike in Cisco IOS, where there are different types of access lists, there is only one type of
access list on the PIX Firewall. In Cisco IOS, the number of the access list determines its type,
but on the PIX Firewall, the number is meaningless. In fact, the access-list identifier can be any
number or string value.
Let’s talk about one feature that is common between Cisco IOS ACLs and Cisco PIX Firewall
ACLs: compiled or turbo ACL. On the PIX Firewall, the turbo ACL feature is turned on globally
with the access-list complied command and turned off with the no access-list compiled
command. By default, the turbo ACL feature is turned off, but the turbo ACL feature is used only
106
Chapter 3
ACLs, Filtering, Object Grouping, and AAA
for access lists with 19 or more entries. You can also turn on the turbo ACL feature for a certain
access-list with the access-list id compiled command.
The turbo ACL feature on the PIX Firewall uses flash memory and so the minimum amount
of flash memory required to run the feature is 2.1MB. If memory allocation fails, the turbo ACL
lookup tables will not be generated. You can use the turbo ACL feature only on PIX Firewall
platforms that have 16MB or more of flash memory.
The Firewall Service Module (FWSM), which has 128MB of flash, has the turbo
ACL feature enabled by default.
If the turbo ACL feature is configured, some ACL or ACL group modifications can trigger
regeneration of the turbo ACL internal configuration. If you have a large number of ACLs, this
could noticeably consume CPU resources. Consequently, we recommend modifying turbocomplied access lists during nonpeak system-usage hours.
Applying a PIX ACL
The access-group command binds an ACL to an interface, just as it does in the Cisco IOS. The
syntax for the PIX access-group command is as follows:
PIX(config)# access-group ?
usage: [no] access-group <access-list> in interface <if_name>
PIX(config)# access-group
The primary difference here is that the keyword in is always used because, as we mentioned
previously, ACLs in the PIX Firewall operating system filter only inbound traffic. Thus, the out
keyword doesn’t exist. It is possible, however, to apply the same ACL to multiple interfaces.
Also, this command is issued with the interface name as a parameter, from the global-configuration prompt, rather than in the context of an interface, as is the case in the Cisco IOS, where
your prompt is Router(config-if)#.
Converting Conduits to ACLs
Cisco has stated that the conduit command has been replaced with the access-list command and will no longer be supported in later releases of the PIX Firewall operating system.
What are you supposed to do with older PIX Firewall configurations now that the conduit
command will soon not be supported? We will discuss how to convert those conduit commands to access-list commands in this section.
Since the conduit and static commands go hand in hand, we need to look briefly at the
static command syntax. Remember from Chapter 2 that the static command syntax is
static (high_interface,low_interface) global_ip local_ip netmask mask
This will translate a global IP address on the less trusted interface to a local IP address on the
more trusted interface.
Using PIX Firewall ACLs
107
Before the access-list command was instituted, for a host to gain access to an inside IP
address from the lower-trusted interface, you needed to use a conduit command. Let’s look at
the format of the conduit command:
conduit [deny | permit] protocol global_ip global_mask
➥ global_operator global_port [global_port] foreign_ip foreign_mask
➥ foreign_operatorforeign_port [foreign_port]
Many of these can be collapsed by certain keywords, such as host or any. For example, here
is a static and conduit command to allow Web traffic from the outside interface to
109.135.102.5 to be translated and given access to the internal host at 192.168.1.5:
PIX(config) # static (inside,outside) 109.135.102.5 192.168.1.5
➥netmask 255.255.255.255
PIX(config)# conduit permit tcp host 109.135.102.5 eq www any
PIX(config)#
As you can see, the conduit command will allow Web access to the host at 109.135.201.5
from any IP address.
Now let’s look at the syntax of the access-list command so you can get an idea how to do the
conversion:
access-list acl_name [deny | permit] protocol source_ip source_mask
➥operator port destination_ip destination_mask operator port
To convert the above conduit command to an access-list command, you must recognize
that the global_ip is the same as the destination_ip, and the foreign_ip is the same as the
source_ip. See Figure 3.1 for an illustration of this point. You must also remember that to
implement the access-list command, you must use the access-group command on the
inbound interface.
The following is the replacement access-list command with the corresponding access-group
command on the inbound interface:
PIX(config)# access-list web_host permit tcp any host 109.135.102.5
➥ eq www
PIX(config)# access-group web_host in interface outside
PIX(config)#
FIGURE 3.1
Conduit to access-list conversion
conduit permit tcp host 109.135.102.5 eq www any
access-list acl_out permit tcp any host 109.135.102.5 eq www
108
Chapter 3
ACLs, Filtering, Object Grouping, and AAA
URL Filtering
Websense and N2H2 are third-party products used by a CiscoSecure PIX Firewall. These products allow an administrator to filter URLs (typically HTTP Web browsing) in a number of different ways. The most common is purchasing a subscription that periodically updates a
database on a Windows server with a list of almost all the resources on the Internet. These URLs
are put in categories such as news, sports, finance, and so on. This allows administrators to set
a policy on the Windows server, such as “our users are not allowed access to sports Web sites.”
In theory, this provides some reduction of the legal liability for employers and other concerned
organizations, without inhibiting “legitimate” or “work-related” Web browsing activity.
In the following sections, we will discuss how URL filtering works and how it is configured
on the PIX Firewall.
How Does URL Filtering Work?
At a high level, the URL filtering architecture is again consistent with the policy enforcement
points (PEP) and policy decision points (PDP) we discussed at the beginning of Chapter 1, “PIX
Firewall Basics.” In this instance, the policy repository and PDP is the Windows server running
URL-filtering software and the PEP is the PIX Firewall.
The Websense and N2H2 products are implemented as plug-ins on a PIX Firewall. This plugin communicates with a Websense or N2H2 server, which runs on a Windows server. Specifically, each time an HTTP request passes through the PIX Firewall, the PIX Firewall hands the
requested URL to the plug-in, and then transmits the URL request to the Web server. The plugin asks the URL server if the URL is approved and then returns the answer. By the time the
requested Web page is returned from the Web server, the PIX Firewall usually has an answer
from the Websense or N2H2 URL server, and discards or forwards the Web page as instructed.
Configuring the PIX Firewall for URL Filtering
Since the bulk of the intelligence is implemented on the Websense or N2H2 server, the configuration of the PIX Firewall is very straightforward. There are only two base commands:
url-server and filter url.
The first, url-server, tells the PIX Firewall the address of the Websense or N2H2 server.
It has the following syntax:
PIX(config)# url-server ?
Usage: [no] url-server [<(if_name)>] [vendor websense] host
➥ <local_ip> [timeout <seconds>] [protocol TCP|UDP [version 1|4]]
[no] url-server [<(if_name)>] vendor n2h2 host <local_ip>
➥ [port <number>] [timeout <seconds>] [protocol TCP|UDP]
PIX(config)# url-server
URL Filtering
109
If you are using Websense, you don’t need to specify a vendor since it is the default server
type. Typically if you are using Websense, the url-server command is as simple as this:
PIX(config)# url-server (inside) host 10.1.1.5
PIX(config)#
The default timeout is five seconds for Websense, but it can be changed by including the
timeout keyword. You can also change the protocol type and version used to communicate
with the Websense server.
If you are using UDP, which is not the default, as the transport to the Websense
server, you must set the protocol version to 4.
As you can see from the syntax above, if you are using an N2H2 server you must specify the
vendor n2h2 parameter. You also specify the same timeout and protocol options that are available under Websense, with the exception of the protocol version.
You can specify up to 16 URL servers, but only one type of URL filtering can be active at a
time, either Websense or N2H2, but not both. Also if you change the configuration on the PIX
Firewall, you must update the URL server; the firewall does not update the configuration on the
URL server and vice versa.
The second base command, filter url, tells the PIX Firewall what traffic to pass to the
Websense or N2H2 server for inspection. It has the following syntax:
PIX(config)# filter ?
Usage: [no] filter url <port> [-<port>]|except <lcl_ip> <mask>
➥ <frgn_ip> <mask> [allow] [proxy-block] [longurl-truncate |
➥ longurl-deny] [cgi-truncate]
[no] filter ActiveX|Java <port> [-<port>] <lcl_ip> <mask>
➥ <frgn_ip> <mask>
PIX(config)# filter
Here is an example:
PIX(config)# filter url http 10.0.0.0 255.0.0.0 0 0 allow
PIX(config)#
This command tells the PIX Firewall that all HTTP requests from 10.0.0.0 /8 to any destination
must be inspected by the URL server. If you didn’t specify the allow parameter, and the Websense or N2H2 server is unavailable, then the PIX Firewall would stop outbound HTTP traffic
until the server is back on line. You can specify a range or ports to filter with the port [-port]
parameter, but it can also be the keyword http, as we have used in the example above.
As you can see from the syntax of the filter command above, you can also filter ActiveX and
Java traffic from a local IP address range to a foreign IP address range on a specified port or
ports. The filter activex command will block outbound ActiveX, Java applets, and other
110
Chapter 3
ACLs, Filtering, Object Grouping, and AAA
HTML <object> tags from outbound packets. The filter java command will filter out Java
applets returning from a previously established outbound connection. Here is an example of
Java applet and ActiveX blocking on all outbound connections:
PIX(config)# filter activex 80 0 0 0 0
PIX(config)# filter java 80 0 0 0 0
PIX(config)#
The cgi-truncate parameter will send a CGI script as a URL, and the proxy-block
parameter will prevent users from connecting to an HTTP proxy server. You can also specify
a range of IP addresses to be excluded from the URL filtering using the filter url except
command followed by the local IP address and foreign IP address ranges. This makes it easy to
exclude some IP addresses from URL filtering.
If you are dealing with long URLs, then you can use the longurl-deny or longurl-truncate
commands to specify what the PIX Firewall is going to do with them. The longurl-deny parameter will deny the URL request if it is over the URL buffer size limit or the URL buffer is not available. The longurl-truncate parameter will send only the hostname or IP address to the
Websense server if the URL is over the buffer limit. You can adjust the URL buffer size using the
url-block block command followed by the block buffer size limit parameter. If you are using
Websense, then you can optionally specify the long URL size with the url-block url-size command followed by a number from 2K to 4K specifying the size of the URL.
Let’s touch on one more command briefly for completeness: the url-cache command. This
command will cache Web server responses that are pending a permit or will deny response from
a Websense or N2H2 server. This is used if the Web server responds faster than the Websense
or N2H2 server, which prevents the Web server’s response from being loaded twice. This command is used to enable URL caching and set the size of the cache.
The command also increases throughput by caching the URL access privileges from the URL
server. The PIX Firewall will look in the URL cache first for a matching permit or deny instead
of forwarding the request to the URL server. The following is the syntax for the url-cache
command:
PIX(config)# url-cache ?
Usage: [no] url-cache <dst|src_dst> size <Kbytes>
PIX(config)# url-cache
The parameters of the url-cache command are dst or src_dst. The dst parameter is used
if all users share the same filtering policy on the URL server and it will cache entries based upon
the URL destination address. If all users do not share the same filtering policy on the URL
server, then use the src_dst parameter, which will cache entries based upon both the source
and destination of the URL request. These parameters must be followed by the size keyword
then a number, which will specify the size of the cache in the range of 1 to 128KB.
Note that the url-cache command does not update the Websense accounting logs if you are
using protocol version 1. They are updated for Websense protocol version 4 and if you are using
the N2H2 URL server.
PPPoE and the PIX Firewall
111
If you change the filtering policy on the Websense or N2H2 server, you will
need to disable the cache with the no url-cache command and then reenable
the cache to make those policy changes apparent to the PIX Firewall URL cache.
PPPoE and the PIX Firewall
Support for the PPPoE client was introduced in version 6.2 of the PIX Firewall operating system. It is mainly targeted to the small office, home office (SOHO) level PIX Firewalls (501 and
506E models), where they might be hooked to a cable modem or DSL router. Currently the
PPPoE client is supported only on the outside interface but it supports the Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), and MSCHAP authentication protocols, with PAP being the default.
PPPoE is used to provide an authenticated method of assigning IP addresses to client systems.
PPPoE clients are typically personal computers connected to an ISP over a broadband connection. ISPs use PPPoE because it supports the higher-speed access speeds while using their existing remote access infrastructure and it is relatively easy for customers to use.
The PPPoE client (in this case it is the PIX Firewall) and the PPPoE server must be on the same
layer 2 bridged network. PPPoE uses two phases. The first phase is the Active Discovery Phase
in which the PPPoE client locates a PPPoE server, called an access concentrator (AC). A Session
ID is assigned and the PPPoE layer is established. In the second phase, called the PPP Session
Phase, PPP options are negotiated and authentication is performed. Once the link setup is completed, PPPoE functions as a layer 2 encapsulation method, allowing data to be transferred over
the PPP link within PPPoE headers.
You must configure the PPPoE client username and password before enabling
PPPoE on the interface.
In this section, we will talk about how to enable, configure, and verify the operation of the
PPPoE client on the PIX Firewall.
Configuring the PPPoE Client Username and Password
To configure the username and password used to authenticate the PIX Firewall to the AC, use
the vpdn command. The first step is to define the virtual private dial-up network (VPDN) group
to be used for the PPPoE client using the following command:
vpdn group group_name request dialout pppoe
where you would replace the group_name parameter with a descriptive name for the PPPoE
client.
112
Chapter 3
ACLs, Filtering, Object Grouping, and AAA
If your ISP requires authentication, you must select an authentication protocol using the following command:
vpdn group group_name ppp authentication method
The group_name is the group name you defined in the first step, and the method is one of the
authentication methods, which are PAP, CHAP, or MS-CHAP.
When using CHAP or MS-CHAP, the username may be referred to as the
remote system name, while the password may be referred to as the CHAP
secret.
Next, you need to create a username and password—which are usually assigned by the ISP—
for the PPPoE connection by using the following command:
vpdn username username password pass
Finally, you associate the username to the VPDN group by using the following command:
vpdn group group_name localname username
Enabling PPPoE on the PIX Firewall
The PPPoE client does not run by default, so to enable the PPPoE functionality on an interface,
you use the ip address interface pppoe command. This will start the PPPoE process and
assign the IP address received from the AC to the interface. You can optionally specify the
setroute command, which will allow the AC to set default route for the client. You can reenter
this command to clear and restart the PPPoE session. The current session will be shut down and
a new one will be restarted.
Remember, currently the PPPoE client can be enabled only on the outside
interface.
PPPoE is not supported in conjunction with DHCP because with PPPoE the IP address is
assigned by the PPP server. The maximum transfer unit (MTU) size is automatically set to 1,492
bytes, which is the correct value to allow PPPoE overhead within an Ethernet frame without
having to fragment the outgoing Ethernet frame.
What happens if you are using a static IP address from your ISP? You can enable PPPoE in
this situation by manually entering the IP address, using the following command:
ip address interface ipaddress mask pppoe
PPPoE and the PIX Firewall
113
This command causes the PIX Firewall to use the specified IP address and mask instead of
negotiating with the PPPoE server to assign an IP address dynamically.
The following is an example of the commands used to configure the PPPoE client on the PIX
Firewall. Some of the irrelevant portions have been omitted:
PIX(config)#write terminal
PIX Version 6.2
nameif ethernet0 outside security0
nameif ethernet1 inside security100
hostname PIX
interface ethernet0 10baset
interface ethernet1 10full
ip address outside pppoe setroute
ip address inside 172.16.16.2 255.255.255.0
vpdn group pppoex request dialout pppoe
vpdn group pppoex localname sybex
vpdn group pppoex ppp authentication pap
vpdn username sybex password *********
: end
PIX(config)#
As you can see from the output above, we are using the setroute option on the ip address
command to create a default route back to the access concentrator. We have also defined the
username of sybex and a password to be used for PAP authentication.
Verifying PPPoE Operation
To confirm your configuration is working properly, Cisco has provided some diagnostic commands that show the configuration and operation of the PPPoE client.
The show ip address outside pppoe command will display the current PPPoE client configuration information. The following is the output from this command:
PIX(config)# show ip address outside pppoe
PPPoE Assigned IP addr: 192.168.121.1 255.255.255.255 on Interface:
➥ outside
Remote IP addr: 192.168.148.36
PIX(config)#
The show vpdn tunnel pppoe command shows the information for the currently running
PPPoE tunnels. The following is the output from this command:
PIX(config)# show vpdn tunnel pppoe
114
Chapter 3
ACLs, Filtering, Object Grouping, and AAA
PPPoE Tunnel Information (Total tunnels=1 sessions=1)
Tunnel id 0, 1 active sessions
time since change 20239 secs
Remote MAC Address 00:08:E3:9C:4C:71
3328 packets sent, 3325 received, 41492 bytes sent, 0 received
PIX(config)#
The show vpdn session pppoe command displays the status of currently active PPPoE sessions. The following is the output from this command:
PIX(config)# show vpdn session pppoe
PPPoE Session Information (Total tunnels=1 sessions=1)
Remote MAC is 00:08:E3:9C:4C:71
Session state is SESSION_UP
Time since event change 20294 secs, interface outside
PPP interface id is 1
3337 packets sent, 3334 received, 41606 bytes sent, 0 received
PIX(config)#
The show vpdn pppinterface command shows the interface identification value of the
PPPoE tunnel. A PPP virtual interface is created for each PPPoE tunnel. The following is the output from this command:
PIX(config)# show vpdn pppinterface
PPP virtual interface id = 1
PPP authentication protocol is PAP
Server ip address is 192.168.148.36
Our ip address is 192.168.121.1
Transmitted Pkts: 3348, Received Pkts: 3345, Error Pkts: 0
MPPE key strength is None
MPPE_Encrypt_Pkts: 0, MPPE_Encrypt_Bytes: 0
MPPE_Decrypt_Pkts: 0, MPPE_Decrypt_Bytes: 0
Rcvd_Out_Of_Seq_MPPE_Pkts: 0
PIX(config)#
The show vpdn group command will display the group defined for the PPPoE tunnel, and
the show vpdn username command displays the local username information. The following is
the output from these commands:
PIX(config)# show vpdn group
vpdn group pppoex request dialout pppoe
vpdn group pppoex localname sybex
Object Groups
115
vpdn group pppoex ppp authentication pap
PIX(config)# show vpdn username
vpdn username sybex password *********
PIX(config)#
Object Groups
In an effort to improve the flexibility in the PIX Firewall configuration, as of version 6.2,
Cisco has implemented the concept of the object group. These object groups can be used with
the standard conduit and access-list commands. They also reduce the number of entries
required to implement a complex security policy. There are four types of object groups that
can be used to make the configuration more readable, understandable, and easier to change.
The four types are:
Protocol
Network
ICMP
Service
In this section, we will discuss how to create and use each type of object group to make it easier to configure and change access lists on the PIX Firewall.
Configuring Object Groups
To configure an object group, the command syntax is
object-group group_type group_id
where group_type is protocol, network, icmp-type, or service. The group_id is an identifier for the group and must be unique.
When configuring a service object group, you must also specify the protocol type being used:
tcp
udp
tcp-udp
After you enter the object group command, you are placed in Object Group Configuration
mode. This mode is where you specify the various objects within this group, and you escape this
mode with the exit command. You can also describe the object group with the description
command used within Object Group Configuration mode.
Once you are in the Protocol Object Group Configuration mode, the command syntax is
protocol-object protocol
116
Chapter 3
ACLs, Filtering, Object Grouping, and AAA
where protocol is either a keyword, such as tcp, udp, or eigrp, or a decimal value of the protocol, such as 17 for UDP and 6 for TCP. This way you can specify a group of protocols that
are to be used together in an access-list.
Below is an example of a protocol object group named branch-prot with the ESP, UDP, and
AH protocol types:
PIX(config)# object-group protocol branch-prot
PIX(config-protocol)# protocol-object esp
PIX(config-protocol)# protocol-object ah
PIX(config-protocol)# protocol-object udp
PIX(config-protocol)#
If you want to specify a group of network objects to get the same treatment, then you would
get into Network Object Group Configuration mode. At this point, you have two options:
either specify a host or specify a group of hosts.
The command syntax to specify a host is
network-object host ip_address
or
network-object host hostname
To use the hostname option, you must have already specified the host using the name command.
To specify a group of hosts or a network of hosts the command syntax is
network-object ip_address mask
This allows you to configure a group of hosts. We have supplied an example below of a network object group that specifies a host and a network to be grouped together:
PIX(config)# name 10.109.2.3 acs-server
PIX(config)# object-group network branch-net
PIX(config-network)# network-object host acs-server
PIX(config-network)# network-object 10.108.0.0 255.255.0.0
PIX(config-network)#
To specify a group of ICMP messages to use in an access-list statement, you would need to
get into ICMP Type Object Group mode. The syntax to add an ICMP type to the group is
icmp-object icmp-type
where icmp-type is either a keyword or number found in Table 3.1.
Object Groups
TABLE 3.1
ICMP Types
Number
Name of ICMP Type
0
Echo-reply
3
Unreachable
4
Source-quench
5
Redirect
6
Alternate-address
8
Echo
9
Router-advertisement
10
Router-solicitation
11
Time-exceeded
12
Parameter-problem
13
Timestamp-request
14
Timestamp-reply
15
Information-request
16
Information-reply
17
Address-mask-request
18
Address-mask-reply
31
Conversion-error
32
Modile-redirect
The following in an example of an ICMP object group configuration:
PIX(config)# object-group icmp-type branch-icmp
PIX(config-icmp-type)# icmp-group echo
PIX(config-icmp-type)# icmp-group time-exceeded
PIX(config-icmp-type)#
117
118
Chapter 3
ACLs, Filtering, Object Grouping, and AAA
As was mentioned earlier, a service object group is used to specify a range of TCP and/or
UDP ports to be defined in a group so the object group command must specify TCP, UDP, or
TCP-UDP. There are two commands that can be used to add a port or range of ports to a service
object group. The first command:
port-object eq service
adds just one service to the service object group.
The second command:
port-object range begin end
is used to add a range of ports to the service object. The service, begin, and end parameters
can be either a keyword, such as domain, or a decimal value of the service. Below is an example
of adding TCP and UDP ports to a service object group named branch-svc:
PIX(config)# object-group service branch-svc tcp-udp
PIX(config-service)# port-object eq domain
PIX(config-service)# port-object range 1024 65535
PIX(config-service)#
You can also nest object groups within each other, also called hierarchical object grouping,
to achieve greater flexibility and modularity when specifying access rules. For example, you can
create two network object groups called Finance and Engineering. Then you can create
another group called All_Nets, which contains both the Finance and Engineering group
objects. The command to do this is group-object object_id, where object_id is the object
to nest within the object being modified. This is the same command used regardless of the object
type being nested.
There are a couple of restrictions when nesting object groups and they are pretty straightforward. You can’t nest an object group within itself and you can’t nest an object group of a different type. The following example will show the scenarios mentioned above and what the PIX
Firewall will do when attempting an illegal operation:
PIX(config)# object-group network Finance
PIX(config-network)# network-object 10.2.2.0 255.255.255.0
PIX(config-network)# exit
PIX(config)#object-group network Engineering
PIX(config-network)# network-object 10.2.3.0 255.255.255.0
PIX(config-network)# group-object Engineering
Adding obj (group-object Engineering) to grp (Engineering) failed;
➥ cause a loop in grp hierarchy
PIX(config-network)# exit
PIX(config)# object-group network All_Nets
PIX(config-network)# group-object Finance
PIX(config-network)# group-object Engineering
Authentication, Authorization, and Accounting (AAA) Services
119
PIX(config-network)# exit
PIX(config)# object-group icmp-type branch-icmp
PIX(config-icmp-type)# object-group Finance
Adding obj to object-group (branch-icmp) failed; object and group
➥ type inconsistent
PIX(config-icmp-type)#
Now if there is another subnet added to the finance network, the only thing that you need
to do is to add that network to the Finance network object group. This will also add the same
network to the All_Nets object group, and your access lists will automatically be updated.
Using Object Groups
To use a group object in an access list, you need to add the keyword object-group in front of
the object identifier within the access list. The following is an example of using each type of
object group within an access list and combining multiple object groups per access-list line:
PIX(config)# access-list 101 permit object-group protocol_object
➥ 10.12.3.0 255.255.255.0 any
PIX(config)# access-list 102 deny ip any object-group network_object
PIX(config)# access-list 103 permit icmp any any object-group
➥ icmp_object
PIX(config)# access-list 104 deny tcp any object-group
➥ service_object any
PIX(config)# access-list 100 permit object-group protocol_object
➥ object-group network_object1 object-group service_object1
➥ object-group network_object2 object-group service-object2
PIX(config)#
If you are familiar with other vendor firewalls, you’ll realize the concept of object groups is
one that has been missing from the Cisco PIX for a while. The reason for the inclusion of object
groups from Cisco will become more apparent when we go over the PIX Device Manager
(PDM) in Chapter 5, “Firewall Failover and PDM.”
Authentication, Authorization, and
Accounting (AAA) Services
AAA is a mechanism used to let a device, in this case a PIX Firewall, know who a user is, what
the user can do, and what the user did. You can have authentication without authorization, but
you cannot have authorization without authentication. A user must be authenticated before the
PIX Firewall knows what that user can do.
120
Chapter 3
ACLs, Filtering, Object Grouping, and AAA
With traditional authentication, a user can gain access to the network by entering their assigned
local username and password for that device. You can’t allow telnet access for one user and not
another. If the user has entered the correct username and password combination, they have access
to the entire network. Plus, local user administration becomes a nightmare as you get more users and
more network access devices. People who leave the company must be removed from every device
they had access to, and there is no way a user can change their password periodically.
With AAA services, you can allow certain users to have access to telnet and FTP services
without allowing them to browse the Web using the HTTP protocol. Once a user has been
authenticated, the PIX Firewall can find out what services they are authorized to access. Once
this information is cached, the PIX Firewall uses a technique known as cut-through proxy to
transparently verify the identity of users as they use any TCP- or UDP-based applications. This
dramatically increases performance without affecting security.
In this section, we will go through the installation and configuration of CiscoSecure Access
Control Server for Windows NT (CSNT), how to implement AAA services on the PIX Firewall,
and how to configure downloadable ACLs.
The ACS server will run both on Windows NT/2000 and Sun Solaris, but we will
cover only the Windows product here.
Installing CiscoSecure ACS for Windows 2000/NT
For anyone who has installed and configured Windows software, CSNT installation is relatively
straightforward. Let’s go through the installation of the software for version 3.1.
We will step through how to install the CSNT version 3.1 on a system without a previous
version. Please complete the following steps:
1.
Log in as the local system administrator to the computer on which you are installing the
software.
2.
Insert the CiscoSecure ACS CD into your CD-ROM drive, which will open the installation
window.
3.
Click Install, and the Software License Agreement window opens.
4.
Read the Software License Agreement and click Accept to agree to the terms and conditions. The Welcome screen opens.
5.
Click Next, which will then open the Before You Begin window.
6.
You are presented with the following list of conditions that must be met before installation
can take place:
End-user clients can successfully connect to the AAA clients.
This Windows 2000 Server can ping the AAA clients.
Any IOS clients are running Cisco IOS release 11.1 or later.
Microsoft Internet Explorer v5.5 or 6.0 or Netscape 6.2 is installed.
Authentication, Authorization, and Accounting (AAA) Services
121
Verify that each condition is met, then select the checkbox for each item, and click Next.
7.
The Choose Destination Location window opens. To install the software in the default
directory, click Next. To use a different directory, click Browse and enter the directory to
use. If the directory does not exist, you are prompted to create it. Click Yes.
8.
The Authentication Database Configuration window opens. Click the radio button for the
authentication databases to be used by CSNT. Select either the CSACS Database Only or
Windows NT User Database option. If you select the first option, the software will use only
the CiscoSecure ACS database for authentication; if you select the second option, the software will check the Windows database if the user is not found in the CSACS database. (If you
select the Windows NT User Database option, you can use the “grant dial-in permission”
attribute on the user to determine access permissions. This enables you to control a user’s
access permissions directly from Windows 2000/NT without using the CiscoSecure administration interface.) Click Next to continue to the Network Access Server Details window.
9.
You have to set up one Network Access Server (NAS) to continue with the software installation. You need to supply the following information about the NAS:
How you will authenticate users:
TACACS+ (Cisco IOS)
RADIUS (Cisco Aironet)
RADIUS (Cisco BBSM)
RADIUS (Cisco IOS/PIX)
RADIUS (Cisco VPN 3000)
RADIUS (Cisco VPN 5000)
RADIUS (IETF)
RADIUS (Ascend)
RADIUS (Juniper)
RADIUS (Nortel)
RADIUS (IPass)
The Name of the access server
The IP address of the access server
The Windows Server IP Address
The key value to be used for TACACS+ or RADIUS
Once this information has been entered, click Next, which will copy the files from the CD
to the computers hard drive.
10. The Advanced Options window appears, and this is where you choose how to customize
the CiscoSecure Administration Interface. You have the following options to either enable
or disable in the interface:
User Level Network Access Restrictions
122
Chapter 3
ACLs, Filtering, Object Grouping, and AAA
Group Level Network Access Restriction
Max Session
Default Time of Day/Day of Week Specification
Distributed System Settings
Database Replication
Once you have enabled the desired options, click Next.
11. The Active Service Monitoring window opens. To enable the CiscoSecure ACS monitoring
service, click on the Enable Log-in Monitoring checkbox. You can then select the action to
take when then login process fails:
No Remedial Action—leaves the service operating as is.
Reboot—restart the computer where it is running.
Restart All—restart all CiscoSecure ACS services, which is the default.
Restart RADIUS/TACACS+—restart only the RADIUS and TACACS+ services.
From this window, you can also check the box to Enable Mail Notification. If this is
selected, you must supply the fully qualified domain name of the SMTP mail server and
mail account to notify. Click Next.
12. The Network Access Server Configuration window opens. The installation software can
help you configure an NAS. If this is not desired, then you need to uncheck the Yes, I Want
To Configure Cisco IOS Now checkbox and click Next.
13. The CiscoSecure ACS Service Initiation window is the last window, and it is used to do
none or more of the following tasks:
Yes, I Want To Start The CiscoSecure ACS Service Now.
Yes, I Want Setup To Launch The CiscoSecure ACS Administrator From By Browser
Following Installation.
Yes, I Want To View The Readme File.
Check the tasks you want performed and click Finish to complete the installation.
Now, let’s discuss the system requirements, how to administer the server, and how CSNT
works, and then have an overview of additional features.
System Requirements
As of the publication of this book, the system requirements to install CSNT are the following:
Pentium III processor running at 550MHz or faster
CD-ROM drive
English-language version of Microsoft Windows 2000 Server with at least Service Pack 3
Microsoft Internet Explorer 5.5 or 6.0 or Netscape Communicator 6.2 or later
256MB of RAM required; 512MB recommended
Authentication, Authorization, and Accounting (AAA) Services
123
250MB of free hard disk space (more might be required if your database will be on the same
machine)
A monitor with 256 colors, 800×600 resolution
Administration
Once the installation process is completed, you will see a final installation window, which asks
if you would like to do one of the following:
View the readme file.
Start the CiscoSecure ACS service now.
Launch the CiscoSecure ACS Administrator from your browser.
Administration of CSNT is usually handled using a Web browser pointing to TCP port 2002
on the machine running CSNT. This means that to administer CSNT, you need a common Web
browser; no special client is required, and you don’t even need to be on the CSNT server to
administer it. You do need to have one of the Web browsers listed in the system requirements
mentioned above.
Once the server is running, you can access, configure, and troubleshoot CSNT using an
HTML/Java interface. Accessing the Web-based administration tool is as simple as opening a
Web page. For example, if you were on the console of the NT server running CSNT, you might
type http://127.0.0.1:2002 into your Web browser to bring up the Web-based administration
tool. CSNT must be running before you can access the Web-based administration interface!
Alternatively, if you were trying to access the Web-based administration tool from a remote
machine, you would type http://10.160.10.31:2002, where 10.160.10.31 is the IP address of
the server.
How CSNT Works
CSNT will work with any network-access device. It can be used with dial-up NASs and firewalls, or it can be used to manage access to switches and routers. The NAS can be literally any
device capable of using the Terminal Access Controller Access Control System Plus (TACACS+)
or Remote Authentication Dial-In User Service (RADIUS) protocol. In this section, we will discuss CSNT when used with Cisco PIX Firewalls.
The PIX Firewall must be configured so that rather than checking local user databases for
authentication, the user-access request is redirected to CSNT for authentication and authorization. (The specific syntax will be discussed later in this chapter.) The firewall uses either the
RADIUS or TACACS+ protocol to send the authentication request to CSNT. CSNT will then
verify the username and password (we will discuss that process shortly) and replies to the firewall. Once the user has been authenticated, CSNT sends a set of authorization attributes to the
firewall. Finally, accounting can be done to keep track of user activity on the network. As was
mentioned, this can become advantageous in situations where you have multiple firewalls.
Let’s talk about how a user can be authenticated to an external user database, how the database can be maintained, and some additional features of CSNT.
124
Chapter 3
ACLs, Filtering, Object Grouping, and AAA
CSNT Authentication through User Databases
CSNT maintains its own database, called the CiscoSecure User Database. When a user-access
request arrives at CSNT, it will first check the CiscoSecure User Database for information
regarding that user. If no matching information is found, CSNT can be configured to check a
number of additional user databases, including the following:
Windows NT
Novell Directory Services (NDS)
Directory Services (DS)
Microsoft Commercial Internet System Lightweight Directory Access Protocol (MCIS
LDAP)
Open Database Connectivity (ODBC)
Additionally, CSNT can use any of the following token-card servers for authentication:
Axent
CryptCard
SafeWord
Security Dynamics, Inc. (SDI)
CiscoSecure User Database Population
The CiscoSecure User Database can be populated in a number of ways:
Manually
With the Database Replication utility
With the Database Import utility
Manual population means the users are added by hand, but to avoid all this work, you can
use the replication and import utilities provided with CSNT.
The Database Replication utility provides fault tolerance and redundancy of your CiscoSecure User Database by allowing several independent CSNT servers to synchronize their data.
In this manner, a new CSNT server can be introduced to the network, configured for database
replication, and thus be populated with a replica of the existing CiscoSecure User Database.
A third option is to use the included Database Import utility, CSUtil.exe. If you have an
existing ODBC-compliant database, you can use this utility to import user information from
that database. (Refer to Cisco’s documentation for formatting and import syntax.)
CSNT Features
CSNT has a rich set of features that allow you to customize and control the AAA process. The
following list is by no means comprehensive, but it does include some of the highlights:
Password aging
User-changeable passwords
Multilevel administration
Authentication, Authorization, and Accounting (AAA) Services
Group administration of users
Maximum sessions for users and groups
Ability to disable an account on a specific date
Time-of-day and day-of-week access restrictions
Ability to disable an account after an amount of failed attempts
Ability to see logged-on users, and to view detailed information for each user
Per-user TACACS+ or RADIUS attributes
Downloadable ACLs
Support for Voice over IP (VoIP)
Windows NT Performance Monitor support for real-time statistics viewing
Configurable accounting and auditing information stored in comma-separated values
(CSV) format
Authentication forwarding
Relational database management system (RDBMS) synchronization
Database replication
Scheduled ACS system backup and ability to restore from the backup file
125
These and other features give you extremely granular control over the AAA process. You
have the ability to control user access. Additionally, CSNT gives you the tools to monitor the
CSNT server, as well as to manipulate the user database.
Implementing AAA on the PIX Firewall
Once ACS has been installed and configured on the server, you will need to configure AAA services for the PIX Firewall. AAA can be configured to use the TACACS+ and/or RADIUS protocol in addition to LOCAL authentication. By default, the PIX Firewall comes preconfigured
with the AAA groups tags of RADIUS, TACACS+, and LOCAL.
The RADIUS group tag is configured with the protocol type of radius, and TACACS+
group tag is configured with the protocol type of tacacs+. With the following command:
aaa-server tag_name protocol protocol_type
you can configure another AAA group tag, where the protocol_type is either tacacs+ or radius.
Next you need to tie one or more servers to the AAA group tag. This is done with the following command:
aaa-server tag_name (interface) host ip_address key_value timeout timeout_value
with the (interface), key_value, and timeout timeout_value being optional parameters.
The first server configured will be used first, and if that server is unreachable, then the firewall will
use the second server configured, and so on, until all configured servers have been attempted. The
AAA server must be reachable from the specified (interface) or from the inside interface if the
126
Chapter 3
ACLs, Filtering, Object Grouping, and AAA
interface parameter is not specified. The default timeout will be set to 10 seconds if the timeout
parameter and value is not specified. If the key_value is not specified, the communications
between the AAA server and the PIX Firewall will be unencrypted. The PIX Firewall will inform
you of this fact when you enter the command without the key_value.
The following is an example of the aaa-server commands:
PIX(config)# aaa-server fred protocol tacacs+
PIX(config)# aaa-server fred host 10.109.2.3
no encryption key found. Using unencrypted mode.
PIX(config)# aaa-server RADIUS (dmz) host 10.108.3.4 abc123 timeout 20
PIX(config)# aaa-server RADIUS (inside) host 10.109.5.4 a1b2c3 timeout 10
PIX(config)#
For RADIUS servers, the PIX Firewall uses the old default TCP/UDP port numbers described
in RFC 2058. These port numbers are 1645 for authentication and 1646 for accounting. Some
newer RADIUS servers may use the port numbers 1812 for authentication and 1813 for
accounting, as defined in RFC 2138 and RFC 2139. If your RADIUS server uses ports other
than 1645 and 1646, then you need to define ports using the following command:
aaa-server radius-authport number and aaa-server radius-acctport number
prior to starting the RADIUS service with the aaa-server command.
RFC 2058 has been updated to reflect that early deployment of RADIUS was
done using the erroneously chosen port number 1645.
When you view the configuration now, you will see that the PIX Firewall has filled in the
defaults for the interface and timeout values. Here is an example with the irrelevant portions of
the configuration being removed:
PIX(config)# wr t
Building configuration...
: Saved
:
PIX Version 6.2(2)
hostname PIX
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server RADIUS (dmz) host 10.108.3.4 acb123 timeout 20
aaa-server RADIUS (inside) host 10.109.5.4 a1b2c3 timeout 10
aaa-server LOCAL protocol local
aaa-server fred protocol tacacs+
aaa-server fred (inside) host 10.109.2.3 timeout 10
PIX(config)#
Authentication, Authorization, and Accounting (AAA) Services
127
Now that the AAA server has been installed and configured and the PIX Firewall has been
configured to communicate with the AAA server, we must now tell the firewall what to authenticate, authorize, or account with the AAA server(s).
Authentication
The PIX Firewall can be configured to authenticate certain inbound or outbound traffic through
the firewall and also certain traffic terminating on the firewall itself. For authentication of
inbound and outbound traffic through the firewall the command used is
aaa authentication include | exclude authen_service inbound |
➥ outbound | interface local_ip local_mask foreign_ip foreign_mask group_tag
The include parameter is used to specify which traffic will be authenticated, where the
exclude parameter is used to exclude traffic that was previously included with the include
command.
The authen_service is the application with which a user is accessing the network. The values here are any, ftp, http, or telnet. The any parameter enables authentication for all TCP
services. To have users prompted for authentication credentials, they must use ftp, http, or
telnet.
The inbound, outbound, or interface is used to specify which direction the traffic, to be
authenticated, will be traveling, or the interface from which to authenticate users. The local_
ip local_mask foreign_ip foreign_mask is the pattern of the traffic to be authenticated.
The address for local_ip is always on the highest security level interface, and foreign_ip is
always on the lowest.
The group_tag is the previously configured AAA server(s) using the specified tag to use for
user authentication.
Here is an example of a configuration to authenticate users from 10.109.0.1 through
10.109.0.254 using the default RADIUS group with the host 10.109.0.24 not needing authentication:
PIX(config)# nat (inside) 1 10.109.0.0 255.255.255.0
PIX(config)# aaa authentication include any outbound 0 0 RADIUS
PIX(config)# aaa authentication exclude outbound 10.109.0.24
➥ 255.255.255.255 RADIUS any
PIX(config)#
Here is a second example where the firewall permits inbound access IP addresses
160.109.200.1 through 160.109.200.30 using all services permitted by the access-list command. The aaa authentication command permits authentication using ftp, http, or
telnet, depending on what the authentication server handles. The authentication server is at
IP address 10.12.16.2 on the inside interface. Here is the example:
PIX(config)# aaa-server AuthIn protocol tacacs+
PIX(config)# aaa-server AuthIn (inside) host 10.12.16.2 thisisakey timeout 20
128
Chapter 3
ACLs, Filtering, Object Grouping, and AAA
PIX(config)# static (inside,outside) 160.109.200.0 10.12.16.0
➥ netmask 255.255.255.224
PIX(config)# access-list acl_out permit tcp 10.12.16.0 255.255.255.0
➥ 160.109.200.0 255.255.255.224
PIX(config)# access-group acl_out in interface outside
PIX(config)# aaa authentication include any inbound 0 0 AuthIn
PIX(config)#
In addition to authenticating traffic using AAA, the PIX Firewall can authenticate users who
are attempting to gain access to the firewall itself. The firewall can authenticate Telnet, SSH, and
HTTP, and enable access to the firewall in addition to the physical serial console connection.
To authenticate access to the PIX Firewall, use the command:
aaa authentication [serial | enable | telnet | ssh | http] console group_tag
You still need to allow access to the firewall with the respective access commands before the
authentication can take place. For example, you must use the telnet or ssh commands before
the aaa authentication telnet console group_tag or aaa authentication ssh
console group_tag commands will work.
There are some default behaviors using authentication to the PIX Firewall that should be discussed. If an aaa authentication service console group_tag command statement is not
defined, you can gain access to the PIX Firewall with no username and the PIX Firewall enable
password (set with the password command). If the aaa commands are defined but the authentication requests timeout, which implies the AAA server might be down or not available, you
can gain access to the PIX Firewall using the username pix and the enable password. By default,
the enable password is not set.
Authorization
Authorization can be accomplished only by using the TACACS+ protocol. This is because
RADIUS authorization is not supported on the PIX Firewall. One thing to note about authentication versus authorization is that the aaa authorization command requires a previously
configured aaa authentication command. However, use of the aaa authentication command does not require the use of the aaa authorization command.
Once a user has been authenticated to access a service or group of services the PIX Firewall
can separately authorize that user to use a service or group of services. The command used to
ask the AAA server to authorize certain traffic is
aaa authorization include | exclude author_service inbound |
➥ outbound | interface local_ip local_mask foreign_ip foreign_mask group_tag
The include and exclude parameters are used in the same way as for the authentication
command.
The author_service is the application with which a user is accessing the network. The values
here are any, ftp, http, telnet, or protocol/port. The protocol/port parameter specifies
a protocol, which is either a name (such as TCP or UDP) or a decimal value (6 for TCP, 17 for UDP,
Authentication, Authorization, and Accounting (AAA) Services
129
1 for ICMP, and so on) followed by an optional port number. For ICMP, the port number is the
ICMP message type instead of a port number.
The inbound, outbound, or interface parameters are used in the same way as for the
authentication command, as are the local_ip local_mask foreign_ip foreign_mask
group_tag parameters.
The following example enables authorization for DNS lookups from the outside interface:
PIX(config)# aaa authorization include udp/53 inbound 0.0.0.0 0.0.0.0 TACACS+
PIX(config)#
You can also specify a range of ports for authorization. In this next example, we want to
exclude all higher UDP ports from authentication:
PIX(config)# aaa authorization exclude udp/1024-65535 outbound
➥ 0.0.0.0 0.0.0.0 TACACS+
PIX(config)#
Another authorization that can be accomplished with TACACS+ is the use of command authorization. Each command entered at the PIX Firewall console can be sent to the AAA server for
authorization. When we say AAA server in the context of command authorization, we are referring to a TACACS+ server because this is the only server type capable of command authorization.
Command authorization can also be done locally, but you need to use the privilege command and assign individuals a certain privilege level to a local user with the username command
and change those commands they should have access to their privilege level or below. Doing
command authorization on the AAA server allows it to scale because making changes to each
PIX Firewall would be tedious and error prone.
The command to use AAA for command authorization is
aaa authorization command tacacs_server_tag
There are certain configuration tasks that need to be performed on the
TACACS+ server to accomplish command authorization, but they are beyond
the scope of this book. For further information, please refer to http://
www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_
note09186a00800949d6.shtml for more information.
Accounting
The accounting aspect of AAA is one of the most useful when you want to keep an eye on what
users are doing with either your Web servers or your outbound traffic. The command syntax to
enable accounting is similar to that for the authentication and authorization commands.
The accounting command syntax is
aaa accounting include | exclude acctg_service inbound | outbound |
➥ interface local_ip local_mask foreign_ip foreign_mask group_tag
130
Chapter 3
ACLs, Filtering, Object Grouping, and AAA
As with the authorization command, the include and exclude parameters are used to
include or exclude traffic to be accounted.
The acctg_service is the application with which a user is accessing the network. The values here are any, ftp, http, telnet or protocol/port. The protocol/port parameter specifies a protocol, which is either a name (such as TCP or UDP) or a decimal value (6 for TCP, 17
for UDP, and so on) followed by an optional port number.
The inbound, outbound, or interface parameters are used in the same way as used for the
authentication and authorization commands, as are the local_ip local_mask
foreign_ip foreign_mask group_tag.
The following is an example of using the aaa accounting command and sending the
accounting information to the configured server(s) defined under the default RADIUS group tag
for all outbound TCP traffic:
PIX(config)# aaa accounting include tcp outbound 0 0 0 0 RADIUS
PIX(config)#
Virtual HTTP and Telnet
When using the PIX Firewall aaa commands to authenticate Web traffic, the command assumes
the AAA server database is shared with the Web server. The PIX Firewall automatically provides the AAA server and Web server with the same information. The way you can get around
this limitation is to use the @ symbol in the username and password. The username to the left
of the @ symbol is sent to the AAA server, and the username to the right of the @ symbol is sent
to the remote server.
This is also true with the password, where the one on the left of the @ symbol is the password
for the AAA user and the other is the password for the remote user. This works with both FTP
and HTTP services. For example, if you are authenticating to an FTP server called “fred” on the
protected side of a PIX Firewall, you would use the following username and password combination to authenticate to both:
C:\>ftp fred
Username: [email protected]
Password: [email protected]
230 User logged in, proceed.
ftp>
This would send the aaa-user and aaa-pass for authentication to the AAA server, and if
that were successful, it would then send ftp-user and ftp-pass to FTP server “fred.” The PIX
Firewall supports usernames up to 127 characters and passwords up to 63 characters. Plus, the
username or password must not contain the @ symbol.
On the PIX Firewall, you can also use special virtual server commands. For example, the syntax of the virtual http command is
virtual http ip_address
Authentication, Authorization, and Accounting (AAA) Services
131
with an optional warn parameter. The warn option is applicable only for text-based browsers
where the redirect cannot happen automatically.
The virtual http command works with the aaa command to authenticate the user, separating the AAA server information from the Web client’s URL request, and redirect the Web client to the Web server specified.
The virtual http command works by redirecting the Web browser’s initial connection
to the specified IP address, which resides in the PIX Firewall, authenticating the user, then
redirecting the browser back to the URL that the user originally requested. For outbound
use, the ip_address parameter must be an address routed to the PIX Firewall, and for
inbound use, the ip_address must be an unused global address.
The following is an example of the virtual http command:
PIX(config)# static (inside,outside) 160.109.2.3 160.109.2.3 netmask
➥ 255.255.255.255
PIX(config)# access-list acl_out permit tcp any host 160.109.2.3 eq 80
PIX(config)# access-group acl_out in interface outside
PIX(config)# aaa authentication include any inbound 160.109.2.3
➥ 255.255.255.255 0 0 TACACS+
PIX(config)# virtual http 160.109.2.3
PIX(config)#
Keep in mind that browsers will cache username and passwords. If an HTTP
session is not timing out, the Web browser might be sending the cached username and password back to the PIX Firewall and reauthenticating the session.
The virtual telnet command allows the Virtual Telnet server to provide a way to preauthenticate users who require connections through the PIX Firewall using services or protocols
that do not support authentication, such as streaming media connections. The following in the
command syntax for the virtual commands:
PIX(config)#
Usage: [no]
[no]
PIX(config)#
virtual
virtual
virtual
virtual
telnet ?
http <ip> [warn]
telnet <ip>
telnet
The virtual telnet command can be used to log in and out of the PIX Firewall, which creates a cached entry in the firewall uauth table. When an unauthenticated user telnets to the virtual IP address, they are challenged for their username and password, and then authenticates
them with the TACACS+ or RADIUS server. The user sees the message “Authentication Successful” once authenticated.
132
Chapter 3
ACLs, Filtering, Object Grouping, and AAA
If the user wishes to log out and clear their entry in the PIX Firewall uauth table, the user can
Telnet to the virtual address. The user is again prompted for their username and password, the
PIX Firewall removes the associated credentials from the uauth table, and the user will get the
message “Logout Successful.”
If inbound users on either the perimeter or outside interfaces need access to the Virtual Telnet
server, a static and access-list command pair must accompany use of the virtual telnet
command. The global IP address in the static command must be a real IP address while the
local address is the IP address of the virtual server.
The following is an example of the virtual telnet command:
PIX(config)# virtual telnet 160.109.201.65
PIX(config)# static (inside,outside) 160.109.201.65 160.109.201.65
➥ netmask 255.255.255.255
PIX(config)# access-list acl_out permit tcp any host 160.109.201.65 eq telnet
PIX(config)# access-group acl_out in interface outside
PIX(config)#
Here is an example of what a Virtual Telnet session would look like:
/bsd/host%telnet 160.109.201.65
Trying 160.109.201.65Ö
Connected to 160.109.201.65
Escape character is ‘^]’.
Username: username
TACACS+ Password: password
Authentication Successful
Connection closed by foreign host.
/bsd/host%
The username and password are those for the user on the TACACS+ server.
Downloadable PIX ACLs
The Downloadable PIX ACLs feature enables you to enter an ACL once in a CiscoSecure ACS
and then have many PIX Firewalls download that ACL when authenticating using the RADIUS
protocol. This is more efficient than entering the ACL into each PIX Firewall. Also, when you
need to change the ACL, you will need to change it in only one place. You need to configure the
PIX Firewall to authenticate using only the RADIUS protocol, since it is the only protocol that
supports this feature.
To configure an ACL on the CiscoSecure ACS, you must enter each PIX ACL command on
a separate line. The downloadable PIX ACLs are not limited in size, but because this feature uses
the standard RADIUS Cisco AV-pairs, you can have a maximum of 4KB. When entering the
ACL using the HTML ACS interface, do not use the access-list keyword or name, but enter the
Authentication, Authorization, and Accounting (AAA) Services
133
rest of the command as if you were typing at the PIX Firewall CLI. Here is an example of what
your ACL should look like:
permit
permit
permit
permit
tcp any host 121.30.200.254
udp any host 121.30.200.254
icmp any host 121.30.200.254
tcp any host 121.30.200.253
The CiscoSecure ACS can back up all the ACLs entered or it can replicate that data to
another ACS box. You can attach the ACL to an ACS user or group profile once you have configured the ACL as a named shared profile component. When the CiscoSecure ACS returns an
attribute with a named ACL as part of the RADIUS access accept packet, the PIX Firewall will
apply the ACL to the user’s session. The CiscoSecure ACS includes a versioning stamp as part
of the transaction to make sure the PIX Firewall has cached the latest version of the ACL. If a
PIX Firewall responds and it does not have the current version of the ACL, the CiscoSecure ACS
will automatically upload the updated ACL to the PIX Firewall.
To enter a downloadable PIX ACL to the ACS, log in to the ACS server and follow
these steps:
1.
In the navigation bar, click Shared Profile Components.
2.
Click Downloadable PIX ACLs.
3.
Click Add, which makes the Downloadable PIX ACLs page appear.
4.
In the Name box of the Downloadable PIX ACLs, you must enter the name of the PIX ACL.
This must be unique.
5.
In the Description box, you can optionally enter a description.
6.
In the ACL Definitions box enter each line of the PIX ACL in the format that we discussed
above.
7.
When you have completed specifying the PIX ACL, click Submit.
These changes take effect immediately, and the ACL is available to be sent to any PIX Firewall that is attempting to authenticate a user who has the ACL name attached to their user or
group profile.
To assign a downloadable PIX ACL to a user account, navigate to the user account and click
on the Assign PIX ACL box. Once that is done, you can select one from the list of previously
configured PIX ACLs then click Submit.
To assign a downloadable PIX ACL to a group profile, you need to edit the setting of the
group. At the top of the page, in the Jump To list, click Downloadable ACLs. Next you need
to click on the Assign PIX ACL check box, then select one from the list of configured PIX ACLs
and click Submit.
134
Chapter 3
ACLs, Filtering, Object Grouping, and AAA
Summary
In this chapter, we explained access-control techniques for the PIX Firewall and how to implement URL filtering using both Websense and N2H2 server types. We introduced you to the new
PPPoE client and how to configure the PIX Firewall to work in conjunction with an ISP using
a PPPoE server. Then we described how the PIX Firewall processes ACLs. You learned that PIX
Firewall ACLs affect only traffic inbound to the PIX Firewall on a given interface. Therefore,
access-list statements must be bound to the inside and outside interfaces to control bidirectional traffic. Next we discussed object groups and how they can make your configuration easier to read and update. We discussed the AAA concept and how to install and configure the
CSNT server. Then we talked about how to implement AAA services on the PIX Firewall.
Finally we discussed downloadable PIX ACLs and how they can save you configuration time.
Exam Essentials
Remember the syntax PIX operating system ACLs. Know how to apply the ACLs to the
desired interfaces and in the proper direction.
Understand what URL Filtering does and how it works. Be able to describe the flow of information between the PIX Firewall plug-in and the URL server. Know how to configure the PIX
Firewall to support URL filtering for both Websense and N2H2 servers.
Be able to configure the PPPoE client. Know the commands used to set up the PPPoE client
authentication type, username, and groups. Also know how to enable the PPPoE client using
both static and dynamic IP addressing.
Understand object groups. Be able to tell why you should use object groups and the different
types of object groups. Know when you can nest object groups and when you are in Object
Group Configuration mode.
Know how to install and configure CSNT. Be able to install and configure the CiscoSecure
Access Control Server for Windows 2000/NT. This includes the options for external authentication including Windows NT, Novell NetWare NDS, LDAP, and any OBDC database.
Be able to configure AAA services for the PIX Firewall. Know which AAA services are available for the PIX firewall and how to configure both traffic-based AAA services in addition to
AAA services that terminate on the firewall.
Know how to configure downloadable PIX ACLs. Know what a downloadable PIX ACL is
and why you would want to use one. Also know how to configure the PIX Firewall and ACS
for downloadable PIX ACLs.
Written Lab
135
Key Terms
Before you take the exam, be certain you are familiar with the following terms:
access concentrator (AC)
Network Object Group
access control list (ACL)
object group
authentication, authorization, and
accounting (AAA)
Password Authentication Protocol (PAP)
Challenge Handshake Authentication
Protocol (CHAP)
Point-to-Point Protocol over Ethernet (PPPoE)
CiscoSecure Access Control Server for
Windows NT (CSNT)
Protocol Object Group
ICMP Type Object Group
service object group
Written Lab
1.
Which types of URL servers are supported by a PIX Firewall running version 6.2 of the
operating system?
2.
How can you make a PIX Firewall ACL an extended ACL?
3.
What are two of the PPP password authentication methods supported by the PPPoE client
on the PIX Firewall?
4.
Which types of object groups are configurable on the PIX Firewall?
5.
What are two types of one-time password token cards supported by CSNT?
6.
What are two types of external user databases ca CSNT use for user authentication?
7.
What command is used to add a TACACS+ server to the PIX Firewall configuration on the
inside interface?
8.
What are the two virtual services available on the PIX Firewall?
9.
Which server protocol explicitly supports authorization?
10. How many lines can be configured in a downloadable PIX ACL?
Chapter 3
136
ACLs, Filtering, Object Grouping, and AAA
Hands-On Lab
Now let us use what we have learned in this chapter, plus some from previous chapters, to configure a PIX Firewall to protect a network. We will configure the outside interface to receive its
IP address from the ISPs PPPoE server using secure authentication. We will configure access-lists
using object groups and URL filtering using the N2H2 server type plus blocking all ActiveX and
Java applets from inbound HTTP traffic.
The following graphic displays the physical layout of the network and PIX Firewall.
Accounting
198.16.13.0/24
.3
.2
Corporate
198.16.15.0/24
WebNet
198.16.14.0/24
HTTP
server on
TCP
ports 8080
.1
& 8181
Router
ISP
PIX
.4
Engineering
198.16.12.0/24
.2
SMTP
Server
PPPoE
Server
URL
Server
This section includes the following labs:
Lab 3.1: Enable the PPPoE client on the outside interface using CHAP authentication.
Lab 3.2: Configure the inside IP address.
Lab 3.3: Configure object groups for various systems and networks on the inside of the
network.
Lab 3.4: Configure Identity NAT for internal client gaining access to the Internet using their
real Internet-routable IP addresses.
Lab 3.5: Configure URL filtering using the N2H2 server type and block all ActiveX and
Java applets.
Lab 3.6: Verifying proper operation of the configuration.
Hands-On Lab
137
LAB 3.1
Enable the PPPoE client on the outside interface using CHAP authentication.
1.
Enter the command change the hostname to PIX.
2.
Enable the outside interface (ethernet0) using automatically determined speed and duplex
settings.
3.
Create a VPDN group named ISP to be used for the PPPoE client.
4.
Create a VPDN username (sybex) and password (sybex) to be used by the PPPoE client,
which are assigned by the ISP.
5.
Configure the PPPoE to use CHAP authentication.
6.
Bind the VPDN group and username so that authentication can take place.
7.
Enable the PPPoE client on the outside interface and use the setroute option to set the
default route from the PPPoE server.
LAB 3.2
Configure the inside IP address.
1.
Enable the inside interface (ethernet1) using automatically determined speed and duplex
settings.
2.
Configure the IP address of 198.16.14.1 with a mask of 255.255.255.0 on the inside
interfaces.
LAB 3.3
Configure object groups for various systems and networks on the inside of the
network.
1.
Create network object groups for each network segment in the diagram.
2.
Create network object groups for each server.
3.
Create a network object for all servers.
4.
Create a network object for the entire network, which contains all other network objects
and server objects.
5.
Create a service object for the special Web traffic on port 8080 and 8181.
6.
Use some of the objects in an access-list applied on the outside interface.
138
Chapter 3
ACLs, Filtering, Object Grouping, and AAA
LAB 3.4
Configure Identity NAT for internal client gaining access to the Internet using their real Internet routable IP addresses.
1.
Specify which IP addresses will be translated.
2.
Configure Identity NAT between the inside and outside interfaces.
LAB 3.5
Configure URL filtering using the N2H2 server type and block all ActiveX and Java
applets.
1.
Configure a URL server at IP address 198.16.12.2 using the N2H2 server type using the
default protocol, port, and timeout settings.
2.
Enable blocking of ActiveX and Java applets from inbound Web traffic.
LAB 3.6
Verifying proper operation of the configuration.
1.
Enter the command to view the PPPoE configuration.
2.
Enter the command to make sure NAT is working.
3.
Enter the commands to view the URL server and filter configuration.
Answer to Lab 3.1
pixfirewall# conf t
pixfirewall(config)# hostname PIX
PIX(config)# interface ethernet0 auto
PIX(config)# vpdn group ISP request dialout pppoe
PIX(config)# vpdn username sybex password sybex
PIX(config)# vpdn group ISP ppp authentication CHAP
PIX(config)# vpdn group ISP localname sybex
PIX(config)# ip address outside pppoe setroute
PIX(config)# exit
PIX#
Hands-On Lab
Answer to Lab 3.2
PIX# conf t
PIX(config)# interface ethernet1 auto
PIX(config)# ip address inside 198.16.14.1 255.255.255.0
PIX(config)# exit
PIX#
Answer to Lab 3.3
PIX# conf t
PIX(config)# object-group network Corporate
PIX(config-network)# network-object 198.16.15.0 255.255.255.0
PIX(config-network)# exit
PIX(config)# object-group network Accounting
PIX(config-network)# network-object 198.16.13.0 255.255.255.0
PIX(config-network)# exit
PIX(config)# object-group network Engineering
PIX(config-network)# network-object 198.16.12.0 255.255.255.0
PIX(config-network)# exit
PIX(config)# object-group network web-server
PIX(config-network)# network-object host 198.16.14.3
PIX(config-network)# exit
PIX(config)# object-group network mail-server
PIX(config-network)# network-object host 198.16.14.4
PIX(config-network)# exit
PIX(config)# object-group network servers
PIX(config-network)# group-object web-server
PIX(config-network)# group-object mail-server
PIX(config-network)# exit
PIX(config)# object-group network AllNetworks
PIX(config-network)# group-object Corporate
PIX(config-network)# group-object Accounting
PIX(config-network)# group-object Engineering
PIX(config-network)# group-object servers
PIX(config-network)# exit
PIX(config)# object-group service special-web tcp
PIX(config-service)# port-object eq 8080
PIX(config-service)# port-object eq 8181
PIX(config-service)# exit
139
140
Chapter 3
ACLs, Filtering, Object Grouping, and AAA
PIX(config)# access-list FromOutside permit tcp any object-group
➥ web-server object-group special-web
PIX(config)# access-list FromOutside permit tcp any object-group
➥ mail-server eq smtp
PIX(config)# access-group FromOutside in interface outside
PIX(config)# exit
PIX#
Answer to Lab 3.4
PIX# conf t
PIX(config)# nat (inside) 0 0 0
nat 0 0.0.0.0 will be non-translated
PIX(config)# exit
PIX#
Answer to Lab 3.5
PIX# conf t
PIX(config)# url-server (inside) vendor n2h2 host 198.16.12.2
PIX(config)# filter activex 80 0 0 0 0
PIX(config)# exit
PIX#
Answer to Lab 3.6
PIX# conf t
PIX(config)# show vpdn
%No active L2TP tunnels
%No active PPTP tunnels
PPPoE Tunnel and Session Information (Total tunnels=1 sessions=1)
Tunnel id 0
time since change 65862 secs
Remote Internet Address 200.10.40.1
Hands-On Lab
141
Local Internet Address 198.99.39.3
6 packets sent, 6 received, 84 bytes sent, 0 received
Remote Internet Address is 10.0.0.1
Session state is SESSION_UP
Time since event change 65865 secs, interface outside PPP interface id is 1
6 packets sent, 6 received, 84 bytes sent, 0 received
PIX(config)# show xlat
0 in use, 72 most used
PIX(config)# show url-server
url-server (inside) vendor n2h2 host 198.16.12.2 port 4005 timeout 5
➥ protocol TCP
PIX(config)# show filter
filter activex 80 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
PIX(config)# exit
PIX#
142
Chapter 3
ACLs, Filtering, Object Grouping, and AAA
Review Questions
1.
Which line would be an acceptable downloadable PIX ACL line?
A. access-list 100 permit ip any any
B. permit ip host 10.1.2.3 any
C. permit ip object-group network any
D. permit tcp 10.0.0.0 0.0.0.255 any
2.
Which command is used to turn on downloadable PIX ACL support on the PIX Firewall?
A. aaa authentication download TACACS+
B. aaa authentication download RADIUS
C. aaa authorization download RADIUS
D. None of the above
3.
How do you configure the virtual http server at 10.0.0.2 to work with text-based browsers?
A. virtual http 10.0.0.2 text
B. virtual http 10.0.0.2 warn
C. vitruall http text 10.0.0.2
D. It always works with text-based browsers.
4.
What happens when you nest an object group within itself?
A. The PIX Firewall will not allow this configuration.
B. Nothing; this is one of the strengths of the object group.
C. The PIX Firewall will ignore this option.
D. None of the above
5.
What traffic does this ACL allow?
PIX(config)# access-list 100 deny host 10.1.1.15 any
PIX(config)# access-list 100 deny host 10.1.1.16 any
A. All traffic except traffic from 10.1.1.15 and .10.1.1.16
B. All traffic except traffic to 10.1.1.15 and 10.1.1.16
C. All traffic except traffic between 10.1.1.15 and 10.1.1.16
D. No traffic
Review Questions
6.
143
The url-server command identifies which of the following?
A. The IP address of servers that users are allowed to browse
B. The IP address of servers that users are not allowed to browse
C. The domain of servers that users are not allowed to browse
D. The IP address of the Websense server
7.
Which URL do you use to enter to administer a CSNT server from the console?
A. http://127.0.0.1/admin
B. http://127.0.0.1:2020
C. http://127.0.0.1:2002
D. http://127.0.0.1:1645
8.
Which commands must be entered to authorize a user telneting to the PIX Firewall using the
RADIUS protocol? (Choose all that apply.)
A. telnet (inside) 0 0
B. telnet 0.0.0.0 255.255.255.255
C. aaa authentication telnet console RADIUS
D. aaa authorization telnet console RADIUS
9.
Which are types of object groups? (Choose all that apply.)
A. protocol
B. network
C. ICMP
D. TCP
10. Which statements do not correctly identify HTTP traffic? (Choose all that apply.)
A. access-list 101 permit tcp any any eq 80
B. access-list 101 permit tcp any any eq http
C. access-list 101 permit tcp any any eq www
D. access-list 101 permit tcp any any eq web
144
Chapter 3
ACLs, Filtering, Object Grouping, and AAA
Answers to Written Lab
1.
The PIX Firewall supports both Websense and N2H2 URL server types.
2.
There is no such thing as an extended PIX Firewall ACL; they are available only in the Cisco
IOS.
3.
The PPPoE client on the PIX Firewall supports PAP, CHAP, or MS-CHAP PPP password
authentication methods.
4.
There are network, service, ICMP, and protocol object groups on the PIX Firewall.
5.
CSNT supports Axent, CryptCard, SafeWord, and Security Dynamics, Inc. (SDI) token
cards.
6.
CSNT supports Windows NT, Novell Directory Services (NDS), Directory Services (DS),
Microsoft Commercial Internet System Lightweight Directory Access Protocol (MCIS
LDAP), and Open Database Connectivity (ODBC) user databases.
7.
To add a TACACS+ server to the PIX Firewall configuration, the command is aaa-server
TACACS+ (inside) host followed by the IP address of the server and the key value.
8.
HTTP and telnet are the two virtual services available on the PIX Firewall.
9.
TACACS+ is the only protocol that explicitly supports authorization.
10. There is no hard number of lines that can be in a downloadable PIX ACL, but it can contain
up to 4K of data.
Answers to Review Questions
145
Answers to Review Questions
1.
B. Option A is incorrect because it includes the access-list and 100 keywords. Option C is incorrect because you can’t use object groups inside a downloadable PIX ACL. Option D is incorrect
because the PIX Firewall does not use a wildcard mask but uses a regular mask. Option B is the
only correct option.
2.
D. There is no special configuration required for downloadable PIX ACL support besides turning on authorization using the RADIUS protocol.
3.
B. You need to use the warn option to make the virtual HTTP server work with text-based
browser.
4.
A. The PIX Firewall will not allow this to happen and will generate an error message.
5.
D. The implicit deny any any rule at the end prevents all traffic not explicitly permitted.
6.
D. The url-server command tells the PIX Firewall where to send Websense requests.
7.
C. The CSNT Web server runs on port 2002.
8.
A, C. Option B is not the correct syntax for the telnet command. Although the question mentions authorization, the only correct commands are A and C.
9.
A, B, C. The only option that is not an object type is TCP.
10. B, D. The correct keyword is www, and you can also specify the port, which is 80.
Chapter
4
Advanced Protocol
Handling, Attack
Guards, and Intrusion
Detection
THE FOLLOWING TOPICS ARE COVERED IN
THIS CHAPTER:
Configuring advanced protocol support on the PIX Firewall
PIX Firewall support of multimedia applications
Overview of attack guards and how to configure them
Using intrusion detection on the PIX Firewall
When we defined firewalls back in Chapter 1, “PIX Firewall
Basics,” we said that there are three academic distinctions that
define a firewall as an application proxy, a packet-filtering firewall, or a stateful firewall. While most firewalls are primarily one type or another, in actual
implementation, they usually have some features from all three categories. This is certainly the
case for the Cisco Secure PIX Firewall.
We saw in the previous two chapters that the PIX Firewall is primarily a stateful firewall. In
this chapter, we look at some features of the PIX Firewall that are an interesting mix of application proxy and stateful filtering.
In the first part of this chapter, we will discuss some hoops the PIX Firewall needs to jump
through to make several popular, but poorly designed, protocols operate. In the second part, we
will discuss an opposite goal: how to keep undesired features of certain protocols from working.
In the last part, we will discuss how the PIX Firewall uses a scaled-down version of the Cisco
Intrusion Detection System (IDS) and how you can quickly stop an attack in progress by using
the shun command.
Advanced Protocol Handling
Unfortunately, not all protocols are as simple and straightforward as telnet and HTTP. Many
protocol designers feel the need to use multiple ports at the same time, or worse, embed their
protocol in other protocols in an attempt to escape the detection of corporate firewalls. These
and other nonstandard behaviors make a stateful firewall’s job much more difficult because the
firewall must be programmed to understand how such problem protocols operate.
For instance, the firewall needs to know when to expect a new TCP connection to be opened
and which source and destination ports the server and client will use because these nonstandard
or random high ports are blocked by default. The only alternative to programming the firewall
to deal with each specific problem protocol is to change your entire security policy so that you
permit everything by default and deny only specific traffic that you know you do not want.
Obviously, this is not an acceptable solution for most organizations.
The special programming required for each protocol is not the only downside of advanced
protocol handling. For each of these protocols, the PIX Firewall must look deep into the packet,
all the way to the Application layer, to find the information it needs for the ASA to process the
special protocol. But even though there is an obligatory performance loss associated with this
processing, the PIX Firewall does a good job of minimizing it, particularly relative to firewalls
that are primarily application proxies.
Advanced Protocol Handling
149
In this chapter, we explain several protocols in some detail. Although it is
unlikely you will see individual protocols covered on the test at this level, it is
nevertheless critical that you understand these protocols if you intend to pursue a career in network security.
Special Protocol Support Basics
For the PIX Firewall to know which set of rules to apply to a given conversation, you need to
tell the PIX Firewall which protocol is being used. You accomplish this in the PIX Firewall operating system command line by associating a TCP or UDP port number with the name of the protocol, using a keyword. This keyword is different for each type of protocol supported on the PIX
Firewall. We will now look at the rules regarding the advanced protocol support and how to
configure it using the fixup protocol command.
Advanced Protocol Support Rules
It is important to remember these two rules when you are configuring advanced protocol
support:
Advanced protocol support is enabled on a per-protocol basis. It is possible to enable support for one protocol, such as FTP, and disable it for another, such as RTSP.
Advanced protocol support is configured globally. It is not configured on a per-interface
basis. For example, you cannot define port 10000 as FTP only on ethernet3 and port 20000
as FTP only on ethernet2. You can define both ports 10000 and 20000 as FTP, but this assignment will apply to all interfaces on the PIX Firewall. Or you can disable FTP support entirely,
which will disable it for all interfaces on the PIX Firewall.
If you didn’t know already, you might have gathered from this discussion that
there is nothing magical about port numbers. In fact, they are assigned arbitrarily. The port numbers with which you are familiar, such as DNS on port 53
and HTTP on port 80, are assigned by the Internet Assigned Number Authority
(look them up at www.iana.org), but technically, it is possible to use almost any
port between 1 and 65535 for any service. For most operating systems, these
numbers are defined in the /etc/services file, but they can be easily changed.
The fixup protocol Command
You use the fixup protocol command to invoke the special protocol handling. The syntax for
the fixup protocol command is as follows:
PIX(config)# fixup ?
usage: [no] fixup protocol prot [option]
150
Chapter 4
Advanced Protocol Handling, Attack Guards, and Intrusion Detection
port [-port]
PIX(config)# fixup
To see the advanced protocol support enabled by default, you can use the show fixup command or the write terminal command (because the information is also listed in the configuration file). The following is the output of the show fixup command as of version 6.2 of the
PIX Firewall:
PIX# show fixup
fixup protocol ftp 21
fixup protocol http 80
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol ils 389
fixup protocol rsh 514
fixup protocol rstp 554
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol sip 5060
fixup protocol skinny 2000
PIX#
One of the advantages of the fixup protocol syntax is its flexibility. For instance, you can
assign multiple ports to a protocol, as shown here:
PIX# conf t
PIX(config)# fixup protocol ftp 10000
PIX(config)# exit
PIX# show fixup
fixup protocol ftp 21
fixup protocol http 80
fixup protocol h323 h225 1720
fixup protocol h232 ras 1718-1719
fixup protocol ils 389
fixup protocol rsh 514
fixup protocol rstp 554
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol sip 5060
fixup protocol skinny 2000
fixup protocol ftp 10000
PIX#
Advanced Protocol Handling
151
It is common for host administrators to attempt to elude port scans by configuring services
on nonstandard ports. For instance, if you administer a system with a Web interface, you might
set the Web server on that device to use port 40080 instead of port 80. If this is the only inbound
Web connection you are expecting, you need to first delete the default connection by typing no
fixup protocol http 80, then configure the new port with the command fixup protocol
http 40080.
It is also possible to configure a range of ports, as in fixup protocol http 8000-8080.
This might be necessary to connect to some management applications. The Cisco Secure Access
Control Server (ACS) product, for example, will assign a random port after connection.
Note that if you disable support for a protocol, it does not mean the protocol will be denied.
For instance, if you created an ACL that allowed all IP traffic from any source to any destination, then typed no fixup protocol ftp 21, your client’s FTP traffic would be allowed to
flow freely through the PIX Firewall. But if you’re going to have a policy like that, there’s no
real point in having a firewall. Conversely, enabling support does not mean that a protocol will
be accepted. You still must create the appropriate translation and connection slots and accesslist or conduit statements.
The benefit of the fixup protocol command is that you can have a restrictive policy and
a use a problem protocol at the same time. The fixup protocol command configuration provides instructions for the PIX Firewall on how to look inside each packet for information on
ports that might be changing. Without this, the PIX Firewall does not know how to read the
HTTP or FTP instructions saying that the connection should use a different port number. It also
does not know how to allow the new traffic in.
Now that you have a basic grasp of the commands, in the next sections, we will look at a few
of these misbehaving protocols in some detail. We will cover some of the more popular ones:
FTP, RSH, SQL*Net, RTSP, and H.323. If you encounter a protocol that is not on this list,
check Cisco’s Web site to see if it is supported. If not, you might need to use an alternative solution. We will discuss a few of these in the “Alternative Solutions to Problem Protocols” section
later in the chapter.
File Transfer Protocol
File Transfer Protocol (FTP) is certainly one of the most widely used protocols. As its name indicates, its purpose is transporting files from one host to another.
FTP follows the client/server model, where one host (the server) runs a program that listens
for connection requests from other hosts (clients) on port TCP 21, by default. When a client initiates a TCP connection to port TCP 21 on the server, with a high port as the source port (this
typically starts with port 1025 and goes up as additional connections are made), and finishes the
three-way handshake, the listener program (inetd in Unix) starts the FTP server service. In
Unix-land, this is typically a daemon called ftpd. The ftpd daemon and the client can now talk
to each other over the TCP connection. As you use the FTP client to navigate through directories, the traffic, such as lists of files and directories, is sent to and from TCP port 21 on the
server, which is also known as FTP command or FTP control.
So far, FTP is behaving just like any other TCP-based application, and configuring a firewall rule via an ACL would be a walk in the park. However, once your client issues the GET
152
Chapter 4
Advanced Protocol Handling, Attack Guards, and Intrusion Detection
command to download a file, FTP does something unusual. Your client will begin listening on
the next available high port (such as TCP 1026), and send the PORT 1026 command to the
server (this command is still sent over the existing connection to port 21). This command
instructs the server to initiate a TCP connection for the actual file data to port TCP 1026 on
the client, and from port TCP 20 on the server. TCP port 20 is also known as FTP data.
In theory, this architecture allows someone to continue issuing commands to TCP port 21
while simultaneously receiving the data from TCP port 20. However, this poses a huge problem
for firewall administrators: Any inbound connections to clients are frowned upon. From a security point of view, you really do not want any devices on an untrusted network initiating TCP
connections to clients on your internal network. But it gets worse: Because the FTP protocol
allows the destination port for the FTP-data connection to the client to be any random high
port, the firewall administrator would need to open all high ports for FTP to work!
To solve this problem, you can use Active-mode FTP (the PIX Firewall default) or Passivemode FTP. We will look at these two modes, at using ACLs for packet-filtering FTP, and at setting some restrictions to provide a more secure FTP in the next sections
Another method for handing FTP is to write an FTP client program that allows
the user to specify a port for the FTP-data connection. You could then configure
your firewall to allow inbound connections on only this TCP port. Unfortunately, that feature is not included in the common FTP clients in use today. Furthermore, it would leave computers unnecessarily vulnerable because that
port would remain open 24 hours per day on the firewall, even when you were
not currently using the connection.
Using Active-Mode FTP
The solution the PIX Firewall employs is to listen to the entire FTP transfer conversation on the
FTP-control port. This is called Active-mode FTP, which occurs with the default fixup
protocol ftp command:
PIX(config)# fixup protocol ftp 21
PIX(config)#
When the PIX Firewall sees the PORT TCP port number command sent across the network,
it automatically allows the corresponding inbound connection. Of course, the source and destination IP addresses must be the same, and the destination TCP port must be the same port
specified in the PORT command that the PIX Firewall intercepted.
Using Passive-Mode FTP
Since many organizations use firewalls that aren’t quite as intelligent as the PIX Firewall, a
workaround in the protocol was necessary. This is commonly known as Passive-mode FTP.
In Passive-mode FTP, the control session is set up just as it is in Active mode. The client initiates a connection to port 21 (typically) on the server. However, when it’s time to open a data
Advanced Protocol Handling
153
session, instead of sending the PORT command, the client sends a PASV command to the server.
If the server supports Passive mode, it opens a random port of its own and responds with a PORT
command to the client, which includes the number of the TCP port it just opened. Finally, the
client initiates the FTP-data session to the random port on the server, as instructed by the PORT
command.
Since this process is a little bizarre, we’ll illustrate it with an example. Suppose a client,
10.1.1.100, decides to download a file via FTP from a server 10.1.2.200. Here is the sequence
of messages and connections for this transfer:
1.
The server begins listening on port 21.
2.
The client opens port 10.1.1.100:1025 and establishes an FTP-control connection to TCP
port 10.1.2.200:21.
3.
The client sends a PASV command to the FTP server over the existing TCP session.
4.
The server begins listening on port 1025.
5.
The server sends a PORT 1025 message to the client across an existing TCP session.
6.
The client opens port 10.1.1.100:1026 and establishes an FTP-data connection to TCP port
10.1.2.200:1025.
ACLs for Packet-Filtering FTP
Although the fixup protocol command on the PIX Firewall handles Passive-mode and
Active-mode FTP quite nicely, when your firewall consists of packet-filtering ACLs, and is not
stateful, you need to pay attention to the type of FTP your clients are using. This is because the
ACLs must be built differently.
For Active-mode FTP, the safest (most restrictive) policy you can set without breaking the
protocol is to allow outbound traffic to port 21, create another rule for inbound traffic that uses
the established keyword to allow the return traffic back in, then allow inbound traffic to random high ports (TCP 1024 through 65535) and, again, use another rule with the established
keyword for the return traffic.
For Passive-mode FTP, you allow connections to be initiated outbound to ports TCP 21 and
anything in the range of 1025 through 65535. Again, create similar rules for inbound traffic
using the established keyword.
Fortunately, many common FTP servers will allow you to specify the range of
ports used for passive connections. If your server is configurable, set this range
to something other than the default. The range should be as small as possible,
but still adequate for the number of anticipated simultaneous connections.
This allows your corresponding firewall rules to be as restrictive as possible.
Setting FTP Restrictions
The fixup protocol ftp command does more than just allow the session to operate. It also
inspects the FTP commands that are sent across the FTP-control session to ensure they are valid.
154
Chapter 4
Advanced Protocol Handling, Attack Guards, and Intrusion Detection
As an administrator, you have the option of making this more restrictive by using the strict
keyword at the end of the fixup protocol ftp command. The strict keyword adds two
restrictions:
It prevents Web browsers from sending embedded commands in FTP requests.
It limits the server so that it can generate only a 227 command. The client is also restricted
so that it can generate only a PORT command.
Remote Shell
Remote Shell (RSH) is one of a group of Unix programs written long ago by folks at Berkeley
and collectively referred to as the r commands. This group includes programs such as rlogin,
rexec, rwho, rcp (remote copy), and more. The RSH protocol is used to open a shell on a
remote computer. This shell can be used to execute commands and return the output to the
local computer.
When the r commands were written, security was not an issue. Therefore, RSH does not even
require you to log on to execute the commands on the remote host. These commands do include
an authentication method, but it is so easily bypassed that the r commands have been almost
totally replaced by s commands. RSH has been replaced by Secure Shell (SSH). Nevertheless,
the PIX Firewall does include support for this aging command.
The specific support required is much like that of FTP. The RSH command uses what Berkeley
refers to as back-channel connections. Just as your FTP commands travel over one TCP connection and your data travels over another, RSH’s stdin and stdout traffic goes over the primary TCP connection, but the RSH server (which is typically a daemon named rshd) initiates
a separate TCP session to return stderr traffic to the client.
stdin (standard in), stdout (standard out), and stderr (standard error) are
components of the Unix operating system that are related to libraries in the C
programming language. I cover these here for completeness, but you don’t
need to know this for the test.
The primary connection for RSH uses TCP port 514 by default. This default cannot be
changed, but you can add other ports. Support for RSH on the PIX Firewall is enabled with the
fixup protocol rsh command, as follows:
PIX(config)# fixup protocol rsh 514
PIX(config)#
SQL*Net
SQL*Net is a complex protocol used by Oracle to transfer data between database clients and
servers. At a high level, this protocol is responsible for initiating and closing connections and
Advanced Protocol Handling
155
allows both synchronous and asynchronous data transfer. The SQL*Net protocol is based on
Transparent Network Substrate (TNS).
Oracle database servers handle incoming connections in an odd and complicated fashion,
which is described in part below:
1.
The server starts by pre-spawning a lot of server processes in anticipation of the connections. These server processes listen on different wildcard addresses.
2.
The server starts a special listener, which listens on a well-known address.
3.
When a client finally does initiate a connection to the database, the special listener receives
and authenticates the connection.
4.
If the client is accepted, the special listener sends a redirect message to the client, containing
the address of one of the pre-spawned server processes.
5.
The client closes its connection to the special listener.
6.
The client takes the address it received from the special listener in the redirect message and
initiates another connection.
7.
The database server pre-spawns another service to replace the one the client is using. The
Oracle server will keep several services ready to receive connections in case a lot of connection requests come in at the same time. This prevents lag as a result of the time it takes to
create a new process.
As you can see in this sequence, the client begins the conversation on a well-known port and
is quickly redirected to use a different, and for practical purposes, random port. This makes it
quite difficult to create simple packet-filtering rules—not even Cisco routers have psychic abilities to predict the ports you will use.
The PIX Firewall, however, is capable of sifting through the Application layer of the redirect
message and picking out the port that will be used. Based on this information, it can temporarily
allow packets with the specific source and destination sockets seen in the initial request and the
redirect message.
Support for SQL*Net on the PIX Firewall is enabled with the fixup protocol sqlnet
command, as follows:
PIX(config)# fixup protocol sqlnet 1521
PIX(config)#
In addition to being a badly behaved protocol, SQL*Net doesn’t even use the
right port! According to IANA, Oracle’s orasrv protocol belongs on port 1525.
Since Oracle is using port 1521, which rightfully belongs to nCube, the PIX Firewall also uses port 1521 as a default. So if you happen to use nCube, you might
need to disable the default command.
156
Chapter 4
Advanced Protocol Handling, Attack Guards, and Intrusion Detection
Multimedia Support
So far, we have seen how older and relatively simple protocols such as FTP, RSH, and SQL*Net
cause problems for firewalls by opening multiple connections either inbound or outbound.
When it comes to problem multimedia protocols, support becomes a little more challenging. As
you work with many newer protocols, you might notice a disturbing trend in complexity. Hopefully, the recent focus on security in the technical world will result in new protocols that are fullfeatured, but not at the expense of security.
In the following sections, we will look at two of these problem protocols. We will see how
the PIX Firewall supports the RTSP protocol and H.323 multimedia applications.
Real-Time Streaming Protocol
Real-Time Streaming Protocol (RTSP) is similar to the Real-Time Transport Protocol (RTP).
RTP is primarily used for Voice over IP (VoIP). RTSP is designed especially for streaming media
and is used by Cisco’s IP/TV, Apple’s QuickTime, RealPlayer, RealAudio, and RealNetworks.
RTSP is designed for large-scale use, where a few high-speed servers stream a lot of traffic to a
lot of clients at a lot of remote locations. The protocol allows clients to use special features,
including pausing, rewinding, and fast-forwarding the stream. RTSP was defined in 1998 using
RFC 2326.
RTSP is challenging because it has several different modes of operation. RTSP itself is a control
protocol like RTCP. Both RTSP and RTCP are part of the RTP suite. This means the RTSP session
was designed to pass commands, much like the FTP-control session. However, the data can be
passed in several different channels. The following are some of the more common methods:
Interleaving the data with the commands in the actual RTSP session (that is, using the same
TCP connection)
Creating a separate TCP session to carry the data
Creating a separate UDP session to carry the data
Tunneling the data through an HTTP session
Using RTP to carry the data
RTSP can actually use almost any protocol to carry the data. For instance, RealServers use
one of two methods: RTP or their own proprietary protocol, Real Data Transport (RDT).
Needless to say, it is impossible to maintain any semblance of security with a mere packetfiltering router when RTSP is a requirement. Not only would you need to open all the TCP
ports, but you would need to open all the UDP ports as well!
Fortunately, the PIX Firewall’s fixup protocol command allows you to mine the application data from the control session so that you can intelligently open only the necessary ports for
the data-transport session. RTSP support is the first one that we’ve mentioned that is not turned
on by default for older versions of the PIX Firewall operating system. It is now enabled for
newer versions. To enable this support, use the fixup protocol rtsp command:
PIX(config)# fixup protocol rtsp 554
PIX(config)#
Advanced Protocol Handling
157
When working with RTSP, the port used depends entirely on the application.
Unfortunately, this command comes with a lot of caveats. The following is true of the PIX
Firewall’s support of RTSP (according to Cisco’s Command Reference):
The PIX Firewall will not fix any RTSP messages that pass through UDP ports.
The PIX Firewall does not support the RealNetwork’s Multicast mode (x-real-rdt/mcast).
Port Address Translation (PAT) is not supported with RTSP fixup support.
The PIX Firewall cannot recognize RTSP messages hidden in HTTP messages (HTTP cloaking).
In the following sections, we will discuss how to support RTSP while using NAT, how to configure
your RealPlayer to support RTSP, and how to support Cisco’s IP/TV through the PIX Firewall.
The following information regarding how RTSP works with NAT and RealPlayer is based on material in Cisco’s Command Reference.
RTSP and NAT
The PIX Firewall cannot perform NAT on RTSP messages because the embedded IP addresses
are contained in the SDP files as part of HTTP or RTSP messages. Packets could be fragmented,
and PIX Firewall cannot perform NAT on fragmented packets.
You can configure NAT for Apple QuickTime 4 or RealPlayer. Cisco IP/TV works with
NAT only if the Viewer and Content Manager are on the outside network and the server is on
the inside network. With Cisco IP/TV, the number of NATs the PIX Firewall performs on the
SDP part of the message is proportional to the number of program listings in the Content Manager (each program listing can have at least six embedded IP addresses).
RTSP and RealPlayer
To configure PIX Firewall support for RealPlayer, use an access-list statement from the
server to the client, or vice versa. You do not need to use a fixup protocol rtsp command
if you are using TCP mode on RealPlayer. If you’re using UDP mode, you need to use a fixup
protocol rtsp port command.
In RealPlayer, you need to change the Transport mode (by selecting Options Preferences Transport RTSP Settings). For both TCP mode and UDP mode on RealPlayer, select the Use
TCP To Connect To Server option. For TCP mode, check the Attempt To Use TCP For All Content checkbox. For UDP mode, and for live content not available via multicast, select the Attempt
To Use UDP For Static Content checkbox.
RTSP and Cisco’s IP/TV
Cisco’s IP/TV will use the RTSP protocol on port 554 and port 8554. Therefore, it will be necessary to enter two commands to support Cisco’s IP/TV through a PIX Firewall:
PIX(config)# fixup protocol rtsp 554
PIX(config)# fixup protocol rtsp 8554
PIX(config)#
Chapter 4
158
Advanced Protocol Handling, Attack Guards, and Intrusion Detection
H.323
Unlike RTSP, H.323 is a conferencing protocol, designed for a moderate to small number of
multimedia users in a peer-to-peer fashion. It is frequently referred to as an “umbrella protocol”
because a large number of related protocols are included in H.323, and it is convenient to speak
of them collectively as simply “H dot three twenty-three.”
The fixup protocol h323 h225 1720 and fixup protocol h323 ras 1718-1719 commands, which are enabled by default, are used by applications such as CU-SeeMe and
Microsoft’s NetMeeting, as well as by Cisco’s IP phones and telephony servers. However, these
commands provide a different service than the previous examples of fixup protocol commands. According to the PIX Firewall Command Reference, the fixup protocol h323 command allows the PIX Firewall to provide faster call setup (or more correctly, to not inhibit faster
call setup) by supporting Fast Connect or Fast Start Procedure. It also allows H.245 tunneling.
Since version 6.2, the PIX Firewall supports PAT for the H.323 protocol. Prior to version 6.2,
there was only one default fixup command for H.323. If you are viewing a PIX Firewall configuration and the only H.323 command is fixup protocol h323 1720, then you should know
that this is the default command prior to version 6.2.
Alternative Solutions to Problem Protocols
Occasionally, you will implement a bleeding-edge technology that has some unpredictable
effect on your network. After doing your due diligence on Cisco’s Web site and other support
avenues, you might come to the conclusion that your PIX Firewall simply will not support this
new application. In this case, there are a few alternatives or workarounds you can use, although
none of them are particularly elegant.
One example of a workaround is to use a combination of policy routing and encapsulation.
If you have Cisco IOS routers on either side of the PIX Firewall, you can use the following
approach:
1.
Identify the problem traffic as narrowly as possible with ACLs.
2.
Create a VPN tunnel between the two routers, which passes through the PIX Firewall.
IPinIP or GRE encapsulation works well for this situation.
3.
Finally, use policy routing to direct the traffic matching your ACL through the VPN tunnel
to the other router.
You will need to design this setup carefully, to make sure you do not create routing loops,
break your NAT or default routing, or introduce other problems. You also need to allow the
IPinIP or GRE tunnels through the PIX Firewall with an ACL.
This solution is inherently less secure because any traffic that goes through the tunnel will be
allowed through the firewall. Therefore, if someone compromises the router at either end and
changes the ACL, your network is wide open. It’s also worth noting that the logging utility on
your PIX Firewall and any other devices, such as your Intrusion Detection System, are now
blindfolded.
Attack Guards
159
Other alternative solutions are limited only by your imagination, but keep in mind that you
should make every attempt to use the ASA where possible and to keep your solutions scalable
and manageable.
Attack Guards
Not only does the PIX Firewall solve several bona fide application issues with its fixup
protocol command, but it also has a few features designed to keep attackers from exploiting
applications, commonly called attack guards.
The PIX Firewall attack guards are quite diverse. Some operate at the Application layer, filtering undesirable commands and requests. Others operate at the lower layers of the OSI model
to make sure packets are correctly formed. Some even work to protect the PIX Firewall’s own
subsystems. In any case, they all change the PIX Firewall’s behavior. Sometimes you will want
these features enabled, and other times you will want them disabled, so the PIX Firewall operating system allows you to toggle them on and off.
The following sections describe the AAA Flood Guard, SYN Flood Guard, Mail Guard, IP
Fragmentation Guard, and DNS Guard features.
AAA Flood Guard
The AAA Flood Guard feature is one of the simpler guards. Its goal is to watch the PIX Firewall’s uauth subsystem, which handles user authentication and helps optimize AAA system
resource utilization. You should remember the uauth subsystem from the previous chapter,
when we discussed AAA services on the PIX Firewall. Under normal circumstances, users establish a TCP connection from their node to the PIX Firewall to pass authentication information,
such as usernames and passwords, to the PIX Firewall. Of course, this TCP connection starts
with the famous three-way handshake.
The vulnerability here is that all hosts can support only a finite number of TCP connections
and an even smaller number of connections that are in an embryonic state. A connection made
in the embryonic state is made between the first and third part of the TCP handshake. This limitation is a function of the TCP/IP protocol stack, which is usually part of the operating system
or a driver. It does not depend on hardware. In other words, a fast computer with loads of memory is just as vulnerable as a slow computer.
To exploit this weakness, attackers will often flood a service with requests. Attackers can
generate thousands of bogus authentication requests per second, but the trick is not getting
caught. After all, it’s not hard to read a log and find the source IP address and trace it to the
owner. As a result, most floods use bogus or spoofed source IP addresses, which cannot be easily
tracked. But that gives the target another problem. When the PIX Firewall receives the SYN
packet, which is the first part of the TCP three-way handshake, it responds immediately with
the second part, which is the SYN ACK. However, it sends the SYN ACK packet to the bogus
IP address. For this reason, the attacker never receives a response and never finishes the third
Chapter 4
160
Advanced Protocol Handling, Attack Guards, and Intrusion Detection
part of the handshake, the final ACK. This means the PIX Firewall never receives the ACK, and
this connection never leaves the embryonic state.
The easily recognizable symptom of an AAA flood attack, commonly called a SYN flood, is
a large number of TCP connections in an embryonic state. This is why the AAA Flood Guard
process watches the uauth subsystem. When it detects this condition, the AAA Flood Guard
immediately sets about freeing up the system resources. It closes TCP connections in the following order:
Timewait
Finwait
Embryonic
Idle
AAA Flood Guard is enabled by default, but you can turn it off and on with the floodguard
command, which has the following syntax:
floodguard enable | disable
For troubleshooting and management, the show and clear commands are also useful:
show floodguard
clear floodguard
It’s important to note that the floodguard command protects only the PIX Firewall itself.
The PIX Firewall can provide protection for other hosts against SYN floods. In the next section,
we will discuss the SYN Flood Guard that is used to protect other hosts from a SYN flood
attack.
SYN Flood Guard
To protect hosts on the internal networks against a SYN DoS attack, the PIX Firewall can be
configured to limit the number of embryonic connections allowed to the internal host using the
SYN Flood Guard. Setting the maximum embryonic connections in the nat and static commands controls this type of protection, which is also called TCP Intercept. Let us review the syntax of these commands.
PIX(config)# static ?
Usage: [no] static [(internal_if_name, external_if_name)]
➥ {global_ip|interface} local_ip [dns] [netmask mask]
➥ [max_conns [emb_limit [norandomseq]]]
[no] static [(internal_if_name, external_if_name)] {tcp|udp}
➥ {global_ip|interface} global_port local_ip local_port
➥ [dns] [netmask mask] [max_conns [emb_limit [norandomseq]]]
PIX(config)# static
Attack Guards
161
and
PIX(config)# nat ?
Usage: [no] nat [(if_name)] nat_id local_ip [mask [dns]
➥ [outside] [max_conns [emb_limit [norandomseq]]]]
[no] nat [(if_name)] 0 [access-list acl-name [outside]]
PIX(config)# nat
As you can see, each of these commands has an emb_limit parameter that can be set. Once
this embryonic connection limit is reached, and until the number of connections falls below this
threshold, every SYN packet bound for the internal host is intercepted. While it is intercepting
these packets, the PIX Firewall will respond on behalf of the internal host by sending an empty
SYN/ACK packet back to the sender. The PIX Firewall will then keep some state information
about the connection attempt, drop the packet, and wait for the sender’s acknowledgment.
If the ACK is received from the sender, the PIX Firewall will use the retained state information to send a SYN packet to the internal host. The three-way handshake will happen between
the PIX Firewall and the internal host. Once the handshake completes, the PIX Firewall will
allow the normal connection to resume between the sender and internal host.
This feature was enhanced in version 5.2 of the PIX Firewall operating system. Before this
version, the PIX Firewall would just drop any new connections once the embryonic connection
limit was reached. This could allow even a modest attack to stop traffic to a company’s Web
server and make it unavailable to the outside world.
Mail Guard
Mail Guard is an example of a guard that inspects Application layer traffic. Not only does it
make decisions about whether or not to allow a packet through based on this application data,
but it also has the ability to rewrite certain data.
Mail Guard is an excellent feature, but it does have its drawbacks. In 1982, Jon Postel wrote
RFC 821: Simple Mail Transfer Protocol (SMTP). This protocol defined several four-letter commands that form the basis of today’s e-mail. However, we’ve made a lot of progress since then.
In the name of security, Mail Guard ignores two decades of enhancements and takes us all the
way back to RFC 821, and even then, allows only a subset of the commands originally specified.
The commands allowed by Mail Guard are listed in Table 4.1.
TABLE 4.1
Commands Allowed by Mail Guard
Command
Function
EHLO, HELO
Identifies the sender
MAIL
Initiates the mail transaction
RCPT
Identifies the recipient
162
Chapter 4
TABLE 4.1
Advanced Protocol Handling, Attack Guards, and Intrusion Detection
Commands Allowed by Mail Guard (continued)
Command
Function
DATA
Contains the text of the mail message
RSET
Aborts the current mail message
NOOP
Instructs the receiver to send an OK reply
QUIT
Instructs the receiver to send an OK reply and terminate the session
Noticeably missing from the list in Table 4.1 are the VRFY, EXPN, and HELP commands. VRFY
is used to identify a username. While definitely useful, this command is often used by attackers
to gather data. E-mail addresses and account names are often the same, so it’s a trivial matter
to do an nslookup for an organization’s MX record in DNS to find the IP address of their mail
server, then telnet to port 25 (SMTP) and use VRFY to find usernames. Once a match is found,
the attacker can start guessing passwords. Because administrative accounts on many old systems automatically were associated with e-mail addresses of the same name, it used to be fairly
simple to determine a great deal of information about a system.
The EXPN command works like VRFY, except it returns distribution lists.
HELP sends brief information and instructions about use of the system. There’s nothing quite
like giving your attacker instructions for using your systems.
Even though the commands are limited by the PIX Firewall, it’s still possible to get information about the mail server because the mail server has a number of banners and error messages.
Mail Guard puts a stop to this as well. It simply changes all the characters in SMTP banners,
except for 2.0.0, to asterisks. One of the nice features of Mail Guard is that if a command isn’t
allowed, the firewall still responds with OK, making someone think that it has been accepted.
Earlier versions of the PIX Firewall operating system have had problems with
parts of Enhanced SMTP (ESMTP). It is always a good idea to test and make
sure an implementation will work before placing it into production. Don’t
assume a PIX Firewall running 4.x code with Mail Guard will work with ESMTP.
Mail Guard on the PIX Firewall is enabled by default on TCP port 25, which is the standard
SMTP port. However, you might want to use the full-featured mail servers, harden your host,
and then use the fixup protocol command to turn Mail Guard on and off, as follows:
PIX(config)# fixup protocol smtp 25
PIX(config)# no fixup protocol smtp 25
PIX(config)#
Attack Guards
163
It is also possible to change the port simply by entering the command with a different port
number and to enable multiple ports by entering the command multiple times with different
port numbers.
Gathering Information from SMTP Servers
Let’s look at some examples of the way different mail servers behave and how the PIX Firewall’s Mail Guard feature protects you. We will telnet to a few real-world mail servers and show
the output. We won’t do anything illegal or immoral. We’ll just use a manual way of doing what
Outlook Express does every time you check your mail. The manual way allows us to view the
program’s output.
First, let’s take a look at the ever popular and often abused www.msn.com. We begin by using
nslookup, setting TYPE=MX, and then finding www.msn.com. Once we have the IP address, we
issue the command telnet xxx.xxx.xxx.xxx 25, which establishes a TCP session between our
telnet program and the SMTP service on one of MSN’s mail servers.
C:\> telnet xxx.xxx.xxx.xxx 25
220 cpimssmtpa29.msn.com Microsoft ESMTP MAIL Service,
Version: 5.0.2195.3972 r
ady at
Mon, 5 Nov 2001 19:42:25 -0800
NOOP
250 2.0.0 OK
VRFY joe
252 2.1.5 Cannot VRFY user, but will accept message
for [email protected]
HELP
214-This server supports the following commands:
214 HELO EHLO STARTTLS RCPT DATA RSET MAIL QUIT HELP BDAT
QUIT
221 2.0.0 cpimssmtpa29.msn.com Service closing transmission
channel
Connection to host lost.
C:\>
164
Chapter 4
Advanced Protocol Handling, Attack Guards, and Intrusion Detection
We see that we are immediately greeted with a lot of information, including the hostname,
which verifies we are where we think we are, the name of the service, the version (which makes
it easy to look up its vulnerabilities), and the date and time. The -0800 time zone information
also gives us a good idea where the server is physically, assuming we know where the company has data centers.
Next, we issue the NOOP command and receive the 2.0.0 OK. Then we attempt to verify that user
joe exists. Fortunately, MSN’s server doesn’t give this information away, but many mail servers still do. The HELP command tells us quite a bit about what we can and cannot do here.
Finally, we terminate the session with the QUIT command.
Next, let’s look at another server from a popular ISP:
C:\> telnet xxx.xxx.xxx.xxx 25
220 xxxx.com ESMTP *** FOR AUTHORIZED USE ONLY! ***
NOOP
250 2.0.0 OK
VRFY joe
252 2.5.2 Cannot VRFY user; try RCPT to attempt delivery
(or try finger)
HELP
214-2.0.0 This is sendmail version 8.11.6
214-2.0.0 Topics:
214-2.0.0
HELO
EHLO
MAIL
RCPT
DATA
214-2.0.0
RSET
NOOP
QUIT
HELP
VRFY
214-2.0.0
EXPN
VERB
ETRN
DSN
AUTH
214-2.0.0
STARTTLS
214-2.0.0 For more info use "HELP topic".
214-2.0.0 To report bugs in the implementation send email to
214-2.0.0
[email protected]
214-2.0.0 For local information send email to Postmaster
at your site.
214 2.0.0 End of HELP info
QUIT
221 2.0.0 xxxx.com closing connection
Connection to host lost.
C:\>
Attack Guards
165
This server starts out much better. The only thing we know from the greeting is that it is
enhanced (ESMTP) and that these administrators know how to replace the default greeting
with one of their own. Next, our attempt to verify a user is met with a message similar to the
MSN server. However, they blow it on HELP. Here, we get the server name and version again,
along with all the commands they support. Because this particular mail server comes standard
on Unix and Linux, we have also narrowed down the operating system. All of this information
can help us choose specific exploits. From an administrator’s point of view, you should be able
to understand how limiting this mail-server information is critical to your security.
Finally, let’s look at a mail server that is protected by the PIX Firewall’s Mail Guard:
C:\> telnet xxx.xxx.xxx.xxx 25
220 *************************************************
***********************************
NOOP
200 zzzz.com: Ok
VRFY joe
500 zzzz.com: unknown command.
HELP
500 zzzz.com: unknown command.
QUIT
221 zzzz.com closing connection. Goodbye!
Connection to host lost.
C:\>
Even a cursory glance tells you there is a huge difference here. It doesn’t matter how much
information their mail server returns in the banner because it’s all replaced with asterisks as it
passes through the PIX Firewall. The NOOP command returns the name of the host (which I have
replaced with z’s) and the Ok. The VERIFY and HELP commands both return unknown command.
Given this information, attackers would need to try a lot of different attacks before they got
lucky. Hopefully, your IDS will detect and notify you about these attempts before the attackers
find a method that works.
IP Fragmentation Guard
IP Fragmentation Guard is used to protect hosts against certain attacks that take advantage of
the fragmentation feature in TCP/IP. The TCP/IP stacks on many older hosts were vulnerable
to many different methods of abusing the fragmentation feature of IP. This feature is used most
often for packets that traverse networks that have different MTU sizes. For instance, if a host
on a Token Ring segment wants to send a large amount of data, it may choose to create the largest frame it can, which is 4,096 bytes. When a router or translational bridge moves this packet
from the Token Ring segment to an Ethernet segment, it will need to split it into several smaller
166
Chapter 4
Advanced Protocol Handling, Attack Guards, and Intrusion Detection
fragments because the maximum size of a frame in Ethernet is 1,518 bytes (including headers)
or 1,522 bytes with support for VLAN tags.
Fragments are a problem for firewalls because only the first fragment in a series of fragments
contains the header information of the higher layers, such as TCP and UDP ports. Thus, a lot
of simple packet-filtering firewalls might accidentally permit or deny fragments.
Two of the 20 bytes in the IP header are devoted to fragmenting packets. This is separated
into two parts: a 3-bit flags section and a 13-bit Fragment Offset field, as shown in Figure 4.1.
The first bit of the flags section is reserved and not currently used. The second bit is called
the Don’t Fragment bit. If the value of this bit is zero, any device in the path from the source to
destination, such as a router or firewall, is allowed to fragment this packet. However, if the
value is set to 1, devices are not allowed to fragment this packet. This typically means that the
device will be unable to forward the packet because it exceeds the MTU of the next segment in
the path. Therefore, the device will discard the packet and usually return an ICMP message to
the source to let it know that it dropped the packet because it could not fragment it.
The last bit of the flags section tells the receiver whether this is the last packet in the chain
or if the receiver should expect another fragment to follow. If the value of this field is 0, it means
the packet is either not fragmented or it is the last fragment in the chain. If the value is 1, the
receiver should expect more fragments to follow.
FIGURE 4.1
Byte
0
Fields in the IP header
8
0
Protocol
Version
Header
Length
4
8
16
24
Type of
Service
Total Length
D M
F F
Packet ID
Time to Live
Fragment Offset
Header Checksum
Protocol
12
Source Address
16
Destination Address
20
Fragment Offset
Packet ID
24
Sequence Number
28
Acknowledgment Number
32
36
40
u a p r s i
r c s s y
g k h l n n
Protocol
Version
Checksum
Data Byte 1
31
Data Byte 1
Window
Urgent Pointer
Data Byte 1
…
Attack Guards
167
The Fragment Offset field tells the receiver how to put the fragments back together to form
a packet. This is important because the fragments might arrive out of order if there were multiple transmission paths. It’s also important to note that only the destination host reassembles
fragmented packets. For instance, if a packet is generated on an FDDI segment, then fragmented
into three pieces on an Ethernet segment, then passed through another FDDI segment to get to
its final destination, the fragments will not be reassembled into a single packet when they
traverse the final FDDI segment. When the destination host receives the first fragment of a
packet, it sets up a little buffer to collect all the fragments and reassemble them before passing
them up.
After this little fragmentation refresher, you should be able to see why fragments are such a
security problem. In fact, there were probably all kinds of alarms going off in your mind: What
if someone sent a fragment with the wrong offset? What if someone kept sending fragments
without ever sending the last fragment? And the list goes on. Unfortunately, the answer to most
of these questions is the host crashes or stops communicating with the network. And because
of that, these attacks are quite popular. The most common examples are the teardrop, bonk,
and NT fragmentation attacks.
To combat the attacks that take advantage of fragmentation, there are a number of recommendations laid out in RFC 1858, and the ASA implements these suggestions. But often, even
more protection is required. The PIX Firewall implements this in the IP Fragmentation Guard
feature. This feature provides protection in two ways:
It requires that each fragment in a chain after the first fragment be associated with a valid
initial fragment. This takes advantage of stateful information to prevent attackers from
manipulating the flags.
It limits the number of fragmented packets to less than 100 per second per host. This attempts
to prevent hosts from being overwhelmed with the task of reassembling fragments.
Unfortunately, both of these controls can cause all kinds of problems for legitimate traffic,
so the IP Fragmentation Guard feature is disabled by default. To enable the IP Fragmentation
Guard feature, use the sysopt security fragguard command. The syntax for the sysopt
command is as follows:
PIX(config)# sysopt ?
usage:
[no] sysopt connection { permit-ipsec | permit-l2tp |
permit-pptp | timewait | {tcpmss [minimum] bytes} }
[no] sysopt ipsec pl-compatible
[no] sysopt noproxyarp if-name
[no] sysopt nodnsalias { inbound | outbound }
[no] sysopt security fragguard
[no] sysopt radius ignore-secret
[no] sysopt uauth allow-http-cache
[no] sysopt route dnat
PIX(config)# sysopt
168
Chapter 4
Advanced Protocol Handling, Attack Guards, and Intrusion Detection
Once enabled, the IP Fragmentation Guard feature applies to all interfaces on
the PIX Firewall. You cannot selectively enable and disable per interface.
Separate from the IP Fragmentation Guard feature, the PIX Firewall also controls fragments
with the fragment commands, which are described in Table 4.2.
TABLE 4.2
PIX Firewall fragment Commands
Command
Description
fragment size database-limit [interface] Without the IP Fragmentation Guard feature,
the PIX Firewall still keeps a table of fragments.
This command allows you to allocate more or
less memory as appropriate for your network.
fragment chain chain-limit [interface]
This command limits the number of fragments
that can be created from a single packet.
fragment timeout seconds [interface]
This command limits the time that the PIX Firewall will wait for fragment stragglers.
clear fragment
This command clears the table of fragments.
show fragment [interface]
This command shows fragment statistics.
DNS Guard
The DNS Guard feature is relatively simple compared with the other attack guards. In the course
of DNS operations, it is common for a request to be sent to many DNS servers. The DNS Guard
feature monitors this request and allows only the first response inbound from any DNS server. All
subsequent responses are dropped because the PIX Firewall tears down the UDP conduit created
after the first response has passed through.
A host might need to query several different DNS servers, but each of these queries is handled
separately. If a host sends four identical queries to four different DNS servers, the PIX Firewall
will create four separate connections. As the queries are returned, the PIX Firewall will tear
down those connections individually.
What does this feature do to prevent an attack? By default, the PIX Firewall would normally
need to wait for the outbound UDP connection to time out, but this could lead to the UDP session being hijacked. By closing this connection immediately following the first returning DNS
reply packet and not waiting the timeout period, the PIX Firewall can prevent a DoS attack.
Because there isn’t really a reason to turn this feature off, there is no syntax to turn it on or
off, so it is always enabled.
Intrusion Detection
169
Intrusion Detection
The PIX Firewall uses a scaled-down version of the Cisco Intrusion Detection System (Cisco
IDS), which can identify a number of common IP-based attacks using signatures to detect patterns of misuse in network traffic. In the following sections, we will talk about how to turn on
intrusion detection using IP auditing and how to stop an attack using the shunning feature.
IP Audit
There are two signature classes: informational and attack. Both signature classes are tracked
separately and have a default action. These default actions can be configured using the ip
audit attack action and ip audit info action commands.
There are three actions that can be taken for each of these signatures:
alarm The alarm option indicates that when a signature match is detected in a packet, the PIX
Firewall will report the event to all configured syslog servers.
drop
The drop option drops the offending packet.
reset The reset option drops the offending packet and closes the connection if it is part of
an active connection.
The default is alarm for both informational and attack signatures. You can also specify multiple actions to occur. For example, you can specify the default action to take for attack signatures to be alarm and reset with the following command:
PIX(config)# ip audit attack action alarm reset
PIX(config)#
Before any traffic auditing can occur, you must create an audit policy with the ip audit
name command. This audit policy can be either an attack or informational policy determined by
the attack or info parameter after the policy name. You can also specify an action to take for
this audit policy, with the action keyword followed by one or more of the three actions. If an
action is not specified, the default action will be used.
For example, since we have changed the default attack signature action to alarm reset,
when we create an attack audit policy without specifying an action, the action will be to alarm
and reset. Here is the output to demonstrate this, with the irrelevant portions omitted:
PIX(config)# ip audit name attack-pol attack
PIX(config)# wr t
Building configuration...
: Saved
:
PIX Version 6.2(2)
hostname PIX
170
Chapter 4
Advanced Protocol Handling, Attack Guards, and Intrusion Detection
ip audit name attack-pol attack action alarm reset
ip audit info action alarm
ip audit attack action alarm reset
PIX(config)#
IP auditing is performed by inspecting the IP packets as they arrive at an inbound interface.
If a packet triggers a signature, and the configured action is not to drop the packet, then the
same packet could trigger other signatures.
You might be wondering how the PIX Firewall knows which policy to apply to which interface.
To apply an audit policy to an interface, you need to use the ip audit interface command followed by the interface name and the audit policy name. For example, if you wanted to apply the
attack audit policy just created to the outside interface, you would use the following commands:
PIX(config)# ip audit interface outside attack-pol
PIX(config)#
Cisco has provided a way to turn off or disable certain signatures from being checked globally on the PIX Firewall. The command to disable a signature is as follows:
ip audit signature signature_number diable
You can enable a previously disabled signature using the following command:
no ip audit signature signature_number
Why would you want to disable a signature in the first place? There might be times when you
get false positives for legitimate traffic and you don’t want to keep getting syslog messages
about this signature.
How do you find out what the number is for the signature you need to disable? You can look
at the syslog messages produced by the PIX Firewall to determine the number, which will be
right after the IDS: keyword. You can also list the signatures on the system using the show ip
audit count command, which is discussed below.
The following is an example of some syslog messages produced by the PIX Firewall IDS feature and syntax on how you can disable a signature globally:
%PIX-4-40013
interface
%PIX-4-40032
interface
PIX(config)#
PIX(config)#
IDS:2003 ICMP redirect from 10.4.1.2 to 10.2.1.1 on
dmz
IDS:4051 UDP Snork attack from 10.1.1.1 to 192.168.1.1 on
outside
ip audit signature 6102 disable
To show how many attack and informational signatures have been triggered, you can enter the
show ip audit count, which shows the IDS protected interface and the count for that particular
signature. You can also use the interface parameter, then the specific interface name to show the
count for only that signature, which must be configured for IDS protection. Finally you can use
the global keyword to show the counts for each signature regardless of the interface.
Intrusion Detection
171
Below are some examples of using the show ip audit count command with the various
parameters. You can see that this particular PIX is Internet-facing by the high number of signatures being triggered:
PIX# show ip audit count
Signature
1000 I Bad IP Options List
1001 I Record Packet Route
1002 I Timestamp
1003 I Provide s,c,h,tcc
1004 I Loose Source Route
1005 I SATNET ID
1006 I Strict Source Route
1100 A IP Fragment Attack
1102 A Impossible IP Packet
1103 A IP Teardrop
2000 I ICMP Echo Reply
2001 I ICMP Unreachable
2002 I ICMP Source Quench
2003 I ICMP Redirect
2004 I ICMP Echo Request
2005 I ICMP Time Exceed
2006 I ICMP Parameter Problem
2007 I ICMP Time Request
2008 I ICMP Time Reply
2009 I ICMP Info Request
2010 I ICMP Info Reply
2011 I ICMP Address Mask Request
2012 I ICMP Address Mask Reply
2150 A Fragmented ICMP
2151 A Large ICMP
2154 A Ping of Death
3040 A TCP No Flags
3041 A TCP SYN & FIN Flags Only
3042 A TCP FIN Flag Only
3153 A FTP Improper Address
3154 A FTP Improper Port
4050 A Bomb
4051 A Snork
4052 A Chargen
6050 A DNS Host Info
6051 A DNS Zone Xfer
outside
0
0
0
0
0
0
0
0
0
0
217610
644046
7344
17665
5830259
153713
173
1506
231
1
43
501
0
6880
30415
245
278
63866
762
5
2
43
0
0
0
0
DMZ
0
0
0
0
0
0
0
0
0
0
96919
0
0
0
50330
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Global
0
0
0
0
0
0
0
0
0
0
120691
644046
7344
17665
5779929
153713
173
1506
231
1
43
501
0
6880
30415
245
278
63866
762
5
2
43
0
0
0
0
172
Chapter 4
Advanced Protocol Handling, Attack Guards, and Intrusion Detection
6052 A DNS Zone Xfer High Port
0
6053 A DNS All Records
11
6100 I RPC Port Registration
0
6101 I RPC Port Unregistration
0
6102 I RPC Dump
0
6103 A Proxied RPC
0
6150 I ypserv Portmap Request
0
6151 I ypbind Portmap Request
0
6152 I yppasswdd Portmap Request
0
6153 I ypupdated Portmap Request
0
6154 I ypxfrd Portmap Request
0
6155 I mountd Portmap Request
0
6175 I rexd Portmap Request
0
6180 I rexd Attempt
0
6190 A statd Buffer Overflow
0
PIX# show ip audit count interface outside
Signature
outside
1000 I Bad IP Options List
0
1001 I Record Packet Route
0
1002 I Timestamp
0
1003 I Provide s,c,h,tcc
0
1004 I Loose Source Route
0
1005 I SATNET ID
0
1006 I Strict Source Route
0
1100 A IP Fragment Attack
0
1102 A Impossible IP Packet
0
1103 A IP Teardrop
0
2000 I ICMP Echo Reply
120691
2001 I ICMP Unreachable
644047
2002 I ICMP Source Quench
7344
2003 I ICMP Redirect
17665
2004 I ICMP Echo Request
5779940
2005 I ICMP Time Exceed
153713
2006 I ICMP Parameter Problem
173
2007 I ICMP Time Request
1506
2008 I ICMP Time Reply
231
2009 I ICMP Info Request
1
2010 I ICMP Info Reply
43
2011 I ICMP Address Mask Request 501
2012 I ICMP Address Mask Reply
0
2150 A Fragmented ICMP
6880
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
11
0
0
0
0
0
0
0
0
0
0
0
0
0
Intrusion Detection
2151
2154
3040
3041
3042
3153
3154
4050
4051
4052
6050
6051
6052
6053
6100
6101
6102
6103
6150
6151
6152
6153
6154
6155
6175
6180
6190
A
A
A
A
A
A
A
A
A
A
A
A
A
A
I
I
I
A
I
I
I
I
I
I
I
I
A
Large ICMP
Ping of Death
TCP No Flags
TCP SYN & FIN Flags Only
TCP FIN Flag Only
FTP Improper Address
FTP Improper Port
Bomb
Snork
Chargen
DNS Host Info
DNS Zone Xfer
DNS Zone Xfer High Port
DNS All Records
RPC Port Registration
RPC Port Unregistration
RPC Dump
Proxied RPC
ypserv Portmap Request
ypbind Portmap Request
yppasswdd Portmap Request
ypupdated Portmap Request
ypxfrd Portmap Request
mountd Portmap Request
rexd Portmap Request
rexd Attempt
statd Buffer Overflow
PIX# show ip audit count global
Signature
1000 I Bad IP Options List
1001 I Record Packet Route
1002 I Timestamp
1003 I Provide s,c,h,tcc
1004 I Loose Source Route
1005 I SATNET ID
1006 I Strict Source Route
1100 A IP Fragment Attack
1102 A Impossible IP Packet
1103 A IP Teardrop
2000 I ICMP Echo Reply
30415
245
278
63866
762
5
2
43
0
0
0
0
0
11
0
0
0
0
0
0
0
0
0
0
0
0
0
Global
0
0
0
0
0
0
0
0
0
0
217610
173
Chapter 4
174
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2150
2151
2154
3040
3041
3042
3153
3154
4050
4051
4052
6050
6051
6052
6053
6100
6101
6102
6103
6150
6151
6152
6153
6154
6155
6175
6180
6190
PIX#
I
I
I
I
I
I
I
I
I
I
I
I
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
I
I
I
A
I
I
I
I
I
I
I
I
A
Advanced Protocol Handling, Attack Guards, and Intrusion Detection
ICMP Unreachable
ICMP Source Quench
ICMP Redirect
ICMP Echo Request
ICMP Time Exceed
ICMP Parameter Problem
ICMP Time Request
ICMP Time Reply
ICMP Info Request
ICMP Info Reply
ICMP Address Mask Request
ICMP Address Mask Reply
Fragmented ICMP
Large ICMP
Ping of Death
TCP No Flags
TCP SYN & FIN Flags Only
TCP FIN Flag Only
FTP Improper Address
FTP Improper Port
Bomb
Snork
Chargen
DNS Host Info
DNS Zone Xfer
DNS Zone Xfer High Port
DNS All Records
RPC Port Registration
RPC Port Unregistration
RPC Dump
Proxied RPC
ypserv Portmap Request
ypbind Portmap Request
yppasswdd Portmap Request
ypupdated Portmap Request
ypxfrd Portmap Request
mountd Portmap Request
rexd Portmap Request
rexd Attempt
statd Buffer Overflow
644047
7344
17665
5830278
153713
173
1506
231
1
43
501
0
6880
30415
245
278
63866
762
5
2
43
0
0
0
0
0
11
0
0
0
0
0
0
0
0
0
0
0
0
0
Intrusion Detection
175
Shunning
What happens when you start getting a lot of attack syslog messages or users are complaining
about traffic coming from one or more IP addresses from the outside? If you determine that you
are under attack, what do you do to stop the attack? You could always create an access list or
modify the existing outside access list and stop all traffic from those IP addresses. Well, you
could do that, but later on, when the attack is no longer happening and the user has cleaned up
the Trojan horse that started that attack, you would need to go back in and delete those accesslist lines you created. This is a big hassle and you might get the access-list wrong and mess things
up worse than before the attack started. Wouldn’t it be nice if you could just temporarily restrict
access from an IP address? Well, there is such a command, and it is shun.
The shun command applies a blocking or shunning function to the interface receiving the
attack. Packets containing the IP source address of the attacking host will be dropped and logged
until the blocking function is removed manually. No traffic from the IP source address will be
allowed to traverse the PIX Firewall unit and any remaining connections will time out as part of
the normal architecture. The blocking function of the shun command is applied whether or not
a connection with the specified host address is currently active.
The shun command can take a single source IP address, or you can specify a destination IP
address, which must also be accompanied by a source port and destination port with 0, meaning
all ports. One more option is to specify what protocol to block, either TCP or UDP. If the protocol is not specified, then the PIX Firewall will block traffic on both TCP and UDP ports specified. If the shun command is used only with the source IP address of the host, then no further
traffic from the offending host will be allowed.
Because the shun command is used to block attacks dynamically and temporarily, it is not
displayed in your PIX Firewall configuration. You can see the current shun commands by using
the show shun command. To delete a shun entry, use the no shun command with the specific
source IP address to delete. Optionally, you can use the clear shun command, which will prevent all IP addresses from being shunned. Here is an example of using the shun command:
PIX(config)#
Shun 1.1.1.1
PIX(config)#
Shun 2.2.2.2
PIX(config)#
Shun 1.1.1.1
Shun 2.2.2.2
PIX(config)#
PIX(config)#
Shun 1.1.1.1
PIX(config)#
PIX(config)#
PIX(config)#
shun 1.1.1.1
successful
shun 2.2.2.2 3.3.3.3 23 0
successful
show shun
0.0.0.0 0 0
3.3.3.3 23 0
no shun 2.2.2.2
show shun
0.0.0.0 0 0
clear shun
show shun
176
Chapter 4
Advanced Protocol Handling, Attack Guards, and Intrusion Detection
Summary
In this chapter, we discussed advanced protocol handling and the PIX Firewall attack guard features. First, we explained why some protocols pose challenges to packet-filtering and even stateful
firewalls. Problematic protocols include FTP, RSH, SQL*Net, RTSP, and H.323. Then you
learned how the PIX Firewall could be configured to make special allowances for these protocols.
Next, we looked at the PIX Firewall attack guards, which can protect against low-level
attacks, such as SYN floods, illegal fragmentation, and application-level attacks against SMTP
and DNS. The attack guards include the AAA Flood Guard, SYN Flood Guard, Mail Guard, IP
Fragmentation Guard, and DNS Guard features.
Finally, we looked at the intrusion detection services available on the PIX Firewall and how
these are configured using the ip audit commands. We also discussed the shun command, a
quick and easy way to temporarily stop traffic from a host that might be attempting to probe
or attack your network.
Exam Essentials
Know how and when protocols create multiple TCP sessions. Understand when TCP sessions are created and why. Understand how the source and destination port numbers are
selected. Given an ACL, be able to predict the outcome of attempts to connect protocols such
as FTP across packet-filtering firewalls.
Remember how to configure advanced protocol support. Know how to enable and disable
support for a given protocol. Know the default port numbers for the problem protocols and be
able to change the default port number to another number.
Know when to configure advanced protocol support. Understand when advanced protocol
configuration is necessary and when it is not. Be able to troubleshoot problems by predicting the
outcome of enabling and disabling support.
Know what SMTP and DNS information is passed in and out of the PIX Firewall. Know
how to enable and disable the Mail Guard feature and understand the advantages and
disadvantages of doing so.
Know how malformed packets can affect firewalls and the hosts they protect. Understand
how session-based attacks at the TCP layer (such as the SYN flood) and lower-layer attacks (for
example, fragmentation) can consume resources on hosts and allow some packets to sneak by
a lesser firewall. Know what the Flood Guard and Fragmentation Guard features do and how
they can be enabled and disabled.
Understand the PIX Firewalls intrusion detection and shunning capabilities Know how to
turn on intrusion detection services and customize the PIX Firewall’s response to traffic matching attack and informational signatures. Know the syntax of the shun command and that it does
not show up in the configuration.
Written Lab
Key Terms
Before you take the exam, be certain you are familiar with the following terms:
AAA Flood Guard
IP Fragmentation Guard
Active-mode FTP
Mail Guard
attack guards
Passive-mode FTP
audit policy
shunning
back-channel connections
signatures
DNS Guard
SYN flood
fragmentation
SYN Flood Guard
Intrusion Detection System
TCP Intercept
Written Lab
1.
What command(s) are used to move the FTP fixup protocol from the default port to
port 10000?
2.
What are the default H.323 command(s) for version 6.2 or higher?
3.
How can you disable the Mail Guard feature on the PIX Firewall?
4.
When using active FTP, which side of the connection issues the PORT command?
5.
What are the two signature classes on the PIX Firewall?
6.
What are the default actions for each of the two signature classes?
7.
What command would you use to see if the Intrusion Detection System is working
properly?
8.
How do you stop an attack from IP address 10.12.1.2?
9.
Which ports does the FTP protocol use for its operation?
10. When using passive FTP, which side issues the PORT command?
177
178
Chapter 4
Advanced Protocol Handling, Attack Guards, and Intrusion Detection
Hands-On Lab
In this section, we will implement what we learned in this chapter to configure a PIX Firewall
to protect a network. We will configure the PIX Firewall to protect an SMTP server on the
inside of the network using the Mail Guard feature. We will turn off FTP support on the default
port and instead use port 2500 for FTP access. We will configure the PIX Firewall to (1) protect
the inside network from attacks using the built-in Cisco IDS and (2) stop an active attack. We
will assume that NAT, routing, and IP addressing has already been accomplished.
The following graphic displays the physical layout of the network and PIX Firewall.
.2
FTP
server on
TCP port
2500
Inside
134.19.154.0/24
.1
ISP
PIX
.3
200.200.200.1
SMTP
Server
Attacker
This section includes the following labs:
Lab 4.1: Enable the Mail Guard feature on the PIX Firewall to protect the internal SMTP
server.
Lab 4.2: Disable the FTP fixup protocol on port 21 and enable it on port 2500.
Lab 4.3: Configure the PIX Firewall to check all inbound traffic for attack signatures.
Hands-On Lab
179
Lab 4.4: Configure the PIX Firewall to stop an attack in progress, which is coming from a
host on the Internet.
Lab 4.5: Verifying proper operation of the configuration.
LAB 4.1
Enable the Mail Guard feature on the PIX Firewall to protect the internal
SMTP server.
1.
Since Mail Guard is enabled by default, configure an object for the SMTP server at IP
address 134.19.154.3.
2.
Create an access list to allow traffic on TCP port 25 to access the internal SNMP server
using the object.
3.
Apply the access list to the outside interface.
LAB 4.2
Disable the FTP fixup protocol on port 21 and enable it on port 2500.
1.
Disable the FTP fixup protocol on port 21.
2.
Enable the FTP fixup protocol on port 2500.
3.
Create an object for the FTP server at IP address 134.19.154.2.
4.
Create an object for the FTP service on port 2500.
5.
Add an entry to the access list previously configured to allow TCP port 2500 to the FTP
server using the FTP server and service objects.
LAB 4.3
Configure the PIX Firewall to check all inbound traffic for attack signatures.
1.
Create an audit policy for attack signatures using the actions of alarm and reset.
2.
Apply the configured audit policy to the outside interface.
180
Chapter 4
Advanced Protocol Handling, Attack Guards, and Intrusion Detection
LAB 4.4
Configure the PIX Firewall to stop an attack in progress, which is coming
from a host on the Internet.
You have identified a host in the Internet that is sending malicious traffic from IP address
200.200.200.1 (please note that this is just an IP address that we came up with and does not represent an actual attacker).
1.
Enter the command to stop that attack from happening.
2.
Enter the command to enable traffic from the previously attacking host.
LAB 4.5
Verifying proper operation of the configuration.
1.
Enter the command to view the signature counts for all IDS configured interfaces on the
PIX Firewall.
2.
Enter the command to make sure you have the FTP fixup protocol enabled for port 2500.
3.
Enter the command to view the access list created for outside traffic allowed inside.
Answer to Lab 4.1
PIX# conf t
PIX(config)# object-group network smtp-server
PIX(config-network)# network-object host 134.19.154.3
PIX(config-network)# exit
PIX(config)# access-list outside-in permit tcp any object-group
➥ smtp-server eq smtp
PIX(config)# access-group outside-in in interface outside
PIX(config)# exit
PIX#
Answer to Lab 4.2
PIX# conf t
PIX(config)# no fixup protocol ftp 21
PIX(config)# fixup protocol ftp 2500
PIX(config)# object-group network ftp-server
PIX(config-network)# network-object host 134.19.154.2
Hands-On Lab
PIX(config-network)# exit
PIX(config)# object-group service ftp-special tcp
PIX(config-service)# port-object eq 2500
PIX(config-service)# exit
PIX(config)# access-list outside-in permit tcp any object-group
➥
ftp-server object-group ftp-special
PIX(config)# exit
PIX#
Answer to Lab 4.3
PIX# conf t
PIX(config)# ip audit name attack-policy attack action alarm reset
PIX(config)# ip audit interface outside attack-policy
PIX(config)# exit
PIX#
Answer to Lab 4.4
PIX# conf t
PIX(config)# shun 200.200.200.1
Shun 200.200.200.1 successful
PIX(config)# clear shun
PIX(config)# exit
PIX#
Answer to Lab 4.5
PIX# show ip audit count
Signature
1000 I Bad IP Options List
1001 I Record Packet Route
1002 I Timestamp
1003 I Provide s,c,h,tcc
1004 I Loose Source Route
1005 I SATNET ID
1006 I Strict Source Route
1100 A IP Fragment Attack
outside
0
0
0
0
0
0
0
0
181
Chapter 4
182
1102
1103
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2150
2151
2154
3040
3041
3042
3153
3154
4050
4051
4052
6050
6051
6052
6053
6100
6101
6102
6103
6150
6151
6152
6153
6154
6155
A
A
I
I
I
I
I
I
I
I
I
I
I
I
I
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
I
I
I
A
I
I
I
I
I
I
Advanced Protocol Handling, Attack Guards, and Intrusion Detection
Impossible IP Packet
IP Teardrop
ICMP Echo Reply
ICMP Unreachable
ICMP Source Quench
ICMP Redirect
ICMP Echo Request
ICMP Time Exceed
ICMP Parameter Problem
ICMP Time Request
ICMP Time Reply
ICMP Info Request
ICMP Info Reply
ICMP Address Mask Request
ICMP Address Mask Reply
Fragmented ICMP
Large ICMP
Ping of Death
TCP No Flags
TCP SYN & FIN Flags Only
TCP FIN Flag Only
FTP Improper Address
FTP Improper Port
Bomb
Snork
Chargen
DNS Host Info
DNS Zone Xfer
DNS Zone Xfer High Port
DNS All Records
RPC Port Registration
RPC Port Unregistration
RPC Dump
Proxied RPC
ypserv Portmap Request
ypbind Portmap Request
yppasswdd Portmap Request
ypupdated Portmap Request
ypxfrd Portmap Request
mountd Portmap Request
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Hands-On Lab
6175 I rexd Portmap Request
6180 I rexd Attempt
6190 A statd Buffer Overflow
PIX(config)# show fixup
fixup protocol http 80
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol ils 389
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol sip 5060
fixup protocol skinny 2000
no fixup protocol ftp 21
fixup protocol ftp 2500
PIX# show access-list
access-list outside-in; 2 elements
access-list outside-in permit tcp any
access-list outside-in permit tcp any
access-list outside-in permit tcp any
➥
object-group ftp-special
access-list outside-in permit tcp any
PIX#
0
0
0
object-group smtp-server eq smtp
host 134.19.154.3 eq smtp (hitcnt=0)
object-group ftp-server
host 134.19.154.2 eq 2500 (hitcnt=0)
183
184
Chapter 4
Advanced Protocol Handling, Attack Guards, and Intrusion Detection
Review Questions
1.
If the FTP server is on the outside, for Active-mode FTP to work, which ports should be opened
on a packet-filtering firewall?
A. Outbound port 21 and inbound port 20
B. Inbound port 21 and outbound port 20
C. Outbound port 21 and outbound port 20
D. Inbound port 21 and inbound port 20
2.
Which technology do multimedia streams have a problem with?
A. PAT
B. Adaptive NAT
C. Multicast OSPF
D. Core-based trees
3.
Which of the following statements about advanced protocol support is correct?
A. Advanced protocol support is enabled and disabled for all interfaces on the PIX Fire-
wall at the same time.
B. Advanced protocol support is enabled or disabled on individual interfaces.
C. Advanced protocol support is enabled on individual traffic flows using ACL numbers
after the fixup command.
D. Advanced protocol support cannot be disabled.
4.
Which of the following is the correct syntax to enable the Fragmentation Guard feature?
A. fixup fragguard
B. sysopt security fragguard
C. fixup protocol fragguard
D. fragguard enable
5.
On a new PIX Firewall, with the default configuration, how will the fixup protocol ftp 3000
command cause the PIX Firewall to behave?
A. The PIX Firewall will look for FTP traffic on port 3000 instead of port 21.
B. The PIX Firewall will look for FTP traffic on port 3000 and port 21.
C. The PIX Firewall will modify the PORT and PASV commands so that FTP-data sessions
always use port 3000.
D. This is an invalid command because FTP uses only ports 21 and 20.
Review Questions
6.
185
Which of the following are not performed by the Mail Guard feature on the PIX Firewall?
Choose all that apply.
A. Converts informational responses from the server to all asterisks
B. Blocks unnecessary commands to the server
C. Blocks e-mail worms/viruses such as Code Red
D. Allows traffic inbound to the port specified in the protocol fixup smtp command
7.
What is the default port for H.323?
A. 1780
B. 1740
C. 1760
D. 1720
8.
What can the fragment command be used to do?
A. Limit the time the PIX Firewall waits for more fragments
B. Block fragments larger than 512 bytes
C. Resend lost fragments, preventing long waits for retransmission of the whole packet
D. Clear the fragments of the xlate table
9.
Which of the following commands is used to apply the audit policy TRACK to inbound traffic on
the outside interface?
A. ip audit TRACK interface outside
B. audit inbound outside TRACK
C. ip audit interface outside TRACK
D. audit TRACK inbound outside
10. Which of the following commands would you use to delete the IP address 10.2.3.4 from being
shunned which is the only one active? Choose all that apply.
A. clear shun
B. no ip shun 10.2.3.4
C. clear ip shun
D. no shun 10.2.3.4
186
Chapter 4
Advanced Protocol Handling, Attack Guards, and Intrusion Detection
Answers to the Written Lab
1.
You need to turn off the FTP fixup protocol with the no fixup protocol ftp 21 command followed by turning on the FTP fixup protocol on port 10000 with the fixup
protocol ftp 1000 command.
2.
After version 6.2, there are two default commands to handle H.323 traffic. These are fixup
protocol h323 h225 1720 and fixup protocol h323 ras 1718-1719.
3.
Using the no fixup protocol smtp 25 command.
4.
The client side of the connection issues the PORT command when using active FTP.
5.
The two signature classes on the PIX Firewall are attack and informational.
6.
The default action for both signature classes is alert.
7.
The show ip audit count command is used to view the number of times a signature has
been triggered.
8.
To stop all traffic from an IP address, and subsequently an attack, use the shun 10.12.1.2
command.
9.
FTP uses TCP port 21 for commands and TCP port 20 for data.
10. The server side of the connection issues the PORT command when using passive FTP.
Answers to Review Questions
187
Answers to Review Questions
1.
A. In Active-mode FTP, the server establishes a connection to the client over port 20.
2.
A. Multimedia applications have a problem with Port Address Translation (PAT). There is no
such thing as adaptive NAT. Multicast OSPF and core-based trees are methods of getting multimedia traffic to its destination.
3.
A. Advanced protocol support is enabled with the fixup command, but applies to all interfaces.
4.
B. The Fragmentation Guard is enabled with the sysopt command. The other options are invalid.
5.
B. This command will add port 3000 to the default port of 21 for FTP. The PIX Firewall inspects
this traffic so that it knows when to allow inbound connections.
6.
C, D. An ACL is still required for inbound traffic to the mail server. The Mail Guard feature
does not permit traffic to flow without an ACL. It also cannot view attachments and cannot
identify malicious code.
7.
D. The default port for H.323 is 1720.
8.
A. The fragment timeout command limits the time the PIX Firewall waits for fragments in a chain.
9.
C. Option C is the only correct answer because the syntax is ip audit interface
interface policy.
10. A, D. You can either clear all shunned IP address from the firewall using the clear shun command
or you can clear only one using the no shun command, so A and D are the only correct answers.
Chapter
5
Firewall Failover
and PDM
THE FOLLOWING TOPICS ARE COVERED
IN THIS CHAPTER:
Understanding serial and LAN-based failover
Configurating the PIX Firewall for failover
Overview of the PIX Firewall PDM
Preparing the PIX Firewall for the PDM
Using the PDM to configure the PIX Firewall
In the previous chapters, you’ve seen how the Cisco Secure PIX
Firewall deals with security issues, including stateful traffic filtering, special protocol handling, and more. In this chapter, we will
take a step away from security and focus on some advanced networking concepts. Specifically, we
will look at how the PIX Firewall compensates for system and network faults and how you can
configure it for high-availability service. We will also talk about the PIX Device Manager (PDM)
and what is required to install and operate the PDM from the PIX Firewall perspective. We will
also go over the PDM Graphical User Interface (GUI) and point out features and keys to using it.
We will also identify the differences in using the PDM with the Firewall Service Module (FWSM).
We will begin with an introduction to fault-tolerance concepts, defining the terms point of
failure and single point of failure and looking at some typical fault-tolerant strategies. Then, for
the rest of the chapter, we will concentrate on the PIX Firewall failover feature—how it works
and how to configure it.
Fault-Tolerance Concepts
Simply put, a fault is an event that occurs when a component of a system fails and causes a degradation or disruption of service. Faults are bad.
Fault tolerance refers to the ability of a system to experience a fault without a significant degradation or disruption of service. Fault tolerance is good, but often expensive and complicated.
In this section, we will look at what causes these faults, how to evaluate them, and some common strategies to mitigate them.
Recall that firewalls reside at the border of two or more networks, and for them
to be effective from a security point of view, all network traffic must pass through
them. Thus, users generally view the failure of a firewall as a failure of the entire
network. As a result, Cisco feels fault tolerance is extremely important.
Points of Failure
Today’s enterprise networks are incredibly complex. Even a simple peer-to-peer network
requires hundreds of components to work together. Unfortunately, almost any one of these
points could fail. We call each of them a potential point of failure.
Fault-Tolerance Concepts
191
Some points of failure are more important than others. When some components fail, they
might cause the system to become slow or behave erratically, or the failure might be a little more
subtle. For example, when a cooling fan wears out, it won’t immediately cause a PC to fail.
Instead, the rise in temperature in the CPU and motherboard might cause the system to “blue
screen” intermittently. Often, it will cut in half the life expectancy of the rest of the parts, even
though you might never notice that the fan failed.
When the failure of a single component causes a disruption in service for the entire system,
we call this a single point of failure. For instance, if a backhoe cuts the fiber-optic cable that carries your WAN circuit into your building, all traffic across this circuit will immediately cease,
even though the routers, switches, and PCs are all still functioning perfectly. This type of fault
is particularly annoying.
Our goal is to identify possible or likely points of failure and eliminate single points of failure. When we eliminate all single points of failure in the entire system, we call that system highly
reliable.
Identifying Points of Failure
When identifying points of failure in a network, the phrase “throw a rock” comes to mind,
because anything it hit would be a point of failure. Because there are so many points of failure,
sometimes it’s helpful to use a layered approach to identify them by following an application
across the network as it interacts with another application. To demonstrate this approach, let’s
consider the case of a Web server. We start at the application and go down (this list is by no
means exhaustive, but it might help you understand how much is involved):
Web server application The Web server application itself could fail, such as httpd on Unix or
Microsoft’s IIS. If this service crashes or stops for any reason, service will be totally disrupted.
Some common culprits are application bugs, dependencies on other applications such as database backends, and misconfigurations.
Web server’s operating system The server’s operating system, such as Linux or Windows 2000,
might crash. Bugs in the operating system (or even another application fighting for resources)
could disrupt service completely. Again, misconfiguration is all too common a reason for this type
of failure.
Device drivers Failures in the device drivers that control hardware—such as the network
interface card, the video card, the controllers for hard drives or RAID arrays, and so on—are
so common that the first words out of any hardware vendor’s support department are invariably, “Have you downloaded the latest drivers from our Web site?”
Hardware Hardware components themselves fail, too. It would take forever to list these, but
a few of the most prone to failure are power supplies, memory modules (SIMMs, DRAMs,
DIMMs, and so on), hard disks, cooling fans, motherboards, and wiring (particularly cables
that are moved frequently or cables that are near users).
192
Chapter 5
Firewall Failover and PDM
With a list like this, it’s a wonder networks function at all. Even so, these applications and
hardware components are all fairly obvious things you’ve probably considered before. However, many people don’t realize that the protocols themselves can fail. Let’s continue with our
Web server points of failure and look at the various protocols that can fail:
TCP/IP TCP/IP itself can be a point of failure. In IP, each network is a broadcast domain. This
means that a broadcast storm could disrupt service to every device in the subnet even if there are
redundant routers and switches. This example illustrates another important point: Even if your
application doesn’t require a piece of hardware or software to function, if that other component
misbehaves, it could affect your system, too. In this example, processing hardware interrupts
caused by all the broadcasts on the network might use so much CPU time that your application
is starved and an outage is perceived.
Routing protocols Routing protocols often fail. Even a slight difference between two vendors’
implementations of a standard protocol can cause disastrous results. Of course, simple misconfiguration is usually responsible for creating routing loops or “black holes” (places where
traffic goes in but doesn’t come out). In this way, an error in some remote part of the network
could affect your system, even though your system doesn’t ordinarily use those resources.
Support protocols Peripheral and support protocols are vulnerable, too. DHCP, DNS, WINS,
ARP, and a host of other support protocols can fail. Higher layer protocols—such as FTP,
HTTP, and others—can experience compatibility issues. Although these problems are not common, they happen enough to justify an entire industry of companies that manufacture protocol
analyzers, such as Wandel and Goltermann and Sniffer Technologies (formerly Data General).
The keys to detecting points of failure in a network are to keep an open mind and exhaustive
documentation. After identifying the points of failure, you must understand what effect they will
have on your network and then evaluate this impact. Evaluating the impact of each point of failure
relative to other points of failure is important because eliminating every single point of failure in
the network is simply not practical. The complexity, effort, and cost would be prohibitive. After
assessing the potential damage, you can address the points of failure in order of importance to the
extent your resources allow.
PIX Firewall Points of Failure
Now that we have an idea of generic points of failure, let’s look at some problems specific to
the PIX Firewall. The PIX Firewall, of course, has most of the components listed in the previous
section. It has software and hardware points of failure.
Although the PIX Firewall operating system is mature and highly stable, it is technically a
potential point of failure. Cisco diligently addresses issues, particularly security vulnerabilities,
and lists both bug fixes and outstanding issues in the release notes of each version.
When it comes to hardware, the PIX Firewall has all the usual suspects: power supplies,
memory, flash, network ports, motherboard, and Pentium processor. In most models, each of
these represents a single point of failure that would disable the entire system.
Fault-Tolerance Concepts
193
A Real-Life TCP/IP Subnet Failure
Although a TCP/IP type of failure is rare relative to physical failures such as power supplies and
hard drives, I happened to experience just such an outage the very same day I wrote this chapter.
The incident began in the early afternoon, with users from all over the campus reporting that
the network was down. After a half hour or so, we had narrowed the problem to a single subnet.
All affected users were on this subnet, which spanned multiple buildings via VLAN trunking,
and none of the users on other subnets were affected. Furthermore, devices on the affected
subnet could communicate with each other and could ping the default gateway, but they
couldn’t reach anything beyond that router. Many other subnets were also using this same
router, but they were not experiencing any problems.
Because this router is actually a pair of large, non-Cisco routers in a complex Virtual Router
Redundancy Protocol (VRRP) arrangement, with a very detailed set of filtering rules that
change often, we immediately suspected there was a problem with these filters or possibly a
routing loop. After a few more hours of troubleshooting, we finally decided to shut off both of
the routers’ interfaces on this network at the same time. Shortly afterwards, we noticed that a
continuous ping we had set up hadn’t dropped a single packet, even though both of the interfaces we were pinging were down!
We checked the ARP cache on the desktop we had used for the ping test, and sure enough, the
organizational unique identifier (OUI) in the MAC address didn’t belong to the router’s manufacturer. We looked it up, then followed this address through the forwarding database tables in
our switches, and eventually found that a server administrator had accidentally configured a
new server with the IP address of our default gateway! This device was responding to ARPs and
causing all traffic destined for other networks to be sent to it. Of course, it didn’t have a route
off the network, so it was simply discarding these packets. We unplugged the offending device,
and connectivity was immediately restored. Elapsed time: more than four hours.
While this incident was an accident, it could easily have been malicious. After all, any user with
a laptop can give the machine a static IP and destroy an entire subnet. Even worse, how would
you trace it if this laptop were hidden in some desk and connected to your network via an
802.11 wireless link?
It is common knowledge that the interface on the default gateway is a single point of failure, so
we mitigate this issue by using protocols such as VRRP and Hot Standby Router Protocol
(HSRP). The point of this story is that points of failure are not restricted to just hardware and
software programs—even the IP address itself is a point of failure.
194
Chapter 5
Firewall Failover and PDM
Fault-Tolerant Strategies
There are a number of different approaches to hardening a system, but the most common method
by far is simply duplicating equipment. So, for one connection, you would buy two routers, two
switches, two firewalls, and so on. Although it’s expensive, this approach does give you a number
of options. In this section, we’ll discuss two of those fault-tolerant options: redundancy and load
balancing plus we will cover how overengineering can make a network more complex.
Redundancy
The simplest method of connecting all of this equipment is to make it redundant. In this arrangement, one component does all the work and the other sits idly, waiting for the first to fail. In the
event of a failure, the second component takes over the job of the failed component with as little
ado as possible.
An example might be a pair of WAN circuits between two remote offices. In your routing
protocol, you might assign a lower cost to the first circuit so that all the traffic uses this link. If
it fails, the routers will begin using the circuit with the higher cost. You could also use Hot
Standby Router Protocol (HSRP) to provide redundancy for routers.
Redundancy generally requires the backup component to be in a fully operational but idle
state. The system must have some method of detecting a failure in the primary component and
switching to the backup component.
Load Balancing
A more complex method of building a fault-tolerant system is by load balancing. If you configured the pair of WAN circuits with equal costs, a routing protocol such as OSPF or EIGRP
would route some traffic across one link and other traffic across the other link.
The advantage of load balancing is that you use the capacity you actually have. Having a pair
of WAN circuits is expensive but you can essentially double the users’ available bandwidth by
using both circuits at the same time. During a failure of one of the links, the users might not
notice the degradation of service.
Overengineering
It’s also important to realize that fault-tolerant strategies can go too far. The more complex systems become, the less reliable they are. Like exotic cars, they run great sometimes, but they
spend more time in the shop than on the road. Also, more complex systems usually require
higher-skilled engineers to maintain, adding to their costs.
Failover systems often suffer from a bad case of overengineering. As more devices are added
to the network for redundancy or load balancing, it becomes exponentially more difficult for
administrators to create an exhaustive list of how the network will behave given a particular
outage. Now when things go wrong, not only do you still have an outage, but it takes four times
as long to solve because your environment is so complicated.
Many systems are also too sensitive and initiate a failover prematurely, causing an outage in
an otherwise stable system. It is always a good idea to ensure failover will work in the way
intended by testing it. (Of course, tests usually need to be done outside normal business hours.)
PIX Firewall Failover
195
PIX Firewall Failover
The PIX Firewall failover feature is consistent with other features of the PIX Firewall in that it
is as simple as possible. For the PIX Firewall to maintain simplicity, it imposes many restrictions
on possible configurations, but when it’s configured correctly, it’s very reliable.
In the following sections we will discuss the features of failover, requirements for failover,
how failover works, and configuring the PIX Firewall for failover operation.
PIX Firewall Failover Features
At a high level, the PIX failover feature consists of two identical PIX Firewalls in a redundant
configuration. Only one firewall is operating at a time, and the other monitors the first, waiting
to take over in an emergency. The inside interfaces of both units are on the same IP subnet, and
the outside interfaces of both units are on the same subnet. The units must also be physically
close enough to be connected with the failover cable.
When a failover occurs, the units simply swap both IP and MAC addresses. Although this
redundant configuration doesn’t offer the benefits of doubling your throughput, as does a loadbalancing strategy, the simplicity of the PIX Firewall’s failover has several advantages:
Transparency to users The failover is totally transparent to the users. While many loadbalancing strategies require cooperation from the users, the PIX Firewall users continue sending
their traffic to the same, single IP address. In fact, they do not even need to know that an IP
address for the second PIX Firewall exists.
Unchanging addresses Not only does the IP address not change, but the MAC address does
not change either. This means ARP tables are still valid and saves the downtime associated with
waiting for entries in the hosts’ ARP tables to expire and be repopulated.
Unchanging routes Because both IP addresses are on the same subnet, no routing changes
need to occur either. For instance, the next hop of a default route advertised by the Routing
Information Protocol (RIP) would remain unchanged.
In fact, this strategy for failover is so simple that the only thing that must change is the
forwarding database in the switches. However, for the PIX Firewall to implement this simple
strategy, your failover configuration must meet specific requirements, as described in the next
section.
PIX Firewall Failover Requirements
The requirements for using the PIX Firewall failover feature are as follows:
Two firewalls You must have exactly two PIX Firewalls to do failover. Unlike many more
complicated systems, you cannot have three or four boxes load-balanced. If you need more
speed, you will need to buy a bigger PIX or the Firewall Service Module for the 6500 Series
Switch and 7600 Series Router.
196
Chapter 5
Firewall Failover and PDM
Identical firewall configuration The two PIX Firewall units must be identical in every respect.
They must be the same model with the same version of software and the same number and type
of interfaces in the same slots. This last restriction might seem particularly inefficient because
you might have some critical networks that require redundancy and other less-important networks that favor a least-cost strategy. In these cases, you might be tempted to add an interface
to a single unit, but the result would be disastrous. These qualifications are nonnegotiable.
Failover cable You need a failover cable that connects the two PIX Firewalls. This cable is
fairly short, so in most circumstances, the PIX Firewalls should be within a few feet of each
other. Using the PIX failover feature on geographically distributed firewalls will not work.
Licensing Recent versions of the PIX operating system are separated into Restricted and
Unrestricted licenses. The failover feature is not supported in the Restricted license. The active
(primary) unit must have the Unrestricted license. For the sake of cost, Cisco does make some
concessions on the backup (secondary) unit. For that unit, you can use the special version of the
license, appropriately called the Failover license, which is much cheaper than the Unrestricted
license. This code is for use on the backup box only. Note that the version number should still
be identical to the primary unit’s version number.
If the PIX licensed only for failover doesn’t hear from a PIX with a real license
for 24 hours, it will begin rebooting at least once every 24 hours. If you cannot
get the fully licensed PIX up within the time limit, consider calling TAC to get a
real license.
Now that we’ve covered what you need to use the PIX Firewall’s failover feature, let’s look
at a typical PIX failover configuration.
How PIX Firewall Failover Works
As an example of how the PIX failover feature works, we will use a typical small-business network. Our network will have one IP network (the 10.1.1.0/24 subnet) and one router connecting us to the Internet. Figure 5.1 shows the physical connectivity.
In these examples, we are providing failover only for the PIX. We do not
attempt to address fault-tolerance for the switches, routers, or WAN links,
although you certainly would not want to overlook these important components in your own network.
In this diagram, we see the Ethernet interface of the router and both PIX Firewalls’ outside
Ethernet interfaces connected to a single switch, presumably with regular Category 5 cabling.
It is possible to connect our firewalls to the router directly by means of a crossover cable, but
this would require a router with two Ethernet interfaces. It would also require us to bridge those
PIX Firewall Failover
197
two interfaces together—for example, with Cisco’s Integrated Routing and Bridging (IRB),
using a Bridge Virtual Interface (BVI)—since both firewalls’ outside interfaces must be on the
same subnet.
Adding a switch or hub between the router and firewalls has the extra benefit
of providing a place to plug in an intrusion detection system (IDS) or protocol
analyzers.
The inside interface of each PIX Firewall is connected to a second switch, to which the users’
PCs and servers will also be connected.
So logically, our network would look like the one shown in Figure 5.2. Here, we see that each
PIX Firewall has an interface on both the 208.101.53.0 and 10.1.1.0 networks.
To make this example work, the clients would need to point to one of the PIX Firewalls’
inside interfaces as their default gateway. Both PIX Firewalls, in turn, would need to point to
the router’s 208.101.53.1 interface as their default gateways. As discussed in previous chapters,
this could be accomplished via static routes or using passive RIP, assuming the router is advertising a default RIP route. Finally, the PIX Firewalls would be responsible for NAT from the
208.101.53.0 network to the 10.1.1.0 network and back.
FIGURE 5.1
Physical diagram of a typical PIX failover configuration
Internet
Router
Switch
Outside
Outside
PIX
PIX
Inside
Inside
Failover
serial cable
Switch
Private net
198
Chapter 5
FIGURE 5.2
Firewall Failover and PDM
Logical diagram of a typical PIX failover configuration
Internet
Router
.1
208.101.53.0 /24
Outside
.2
.3
PIX
PIX
Inside
Outside
.2
.3
Inside
Failover serial cable
10.1.1.0 /24
Private net
When describing the PIX Firewall and its configuration, Cisco refers to the various units with
several different labels:
Primary The primary unit is the one you have configured to be preferred. This unit will
attempt to assume the primary IP addresses and receive and forward user traffic. It will also
handle routing updates and everything else.
Secondary The secondary unit is the one that isn’t preferred. This unit will bring all of its interfaces up, but will not transmit or receive traffic (except for keepalive messages). It will attempt
to assume the backup IP addresses and will monitor the other unit, waiting to take over if it fails.
Active Regardless of how it is configured, the active unit is the unit that is currently assuming
the primary IP addresses and the responsibility for receiving and forwarding user traffic.
Standby Again, regardless of how it is configured, the standby unit is the unit that is currently
not sending and receiving user traffic. Under normal circumstances, the standby PIX Firewall is
responsible for monitoring the active PIX Firewall. However, if a failover has occurred, it usually means that what was the standby unit is now the active unit. What was the active unit is
now the standby unit, but since it has failed, it might or might not be monitoring the currently
active unit. The exception to this is when an administrator initiates a failover in the absence of
an actual failure (as described later in this chapter in the “Role Configuration” section).
PIX Firewall Failover
199
So, at any given time, in a pair of PIX Firewalls configured for failover, one will be primary
and the other will be secondary. At the same time, one will be active and the other will be
standby. Under normal circumstances, the primary unit is also the active unit, which necessarily
means that the secondary unit is the standby unit. When a failover occurs, the secondary unit
becomes the active unit and the primary unit becomes the standby unit.
If it helps to distinguish between these roles, think about what would happen
if you powered off both PIX Firewalls: One would still be the primary and the
other would still be the secondary, but neither would be the active or standby
firewalls.
Because the two PIX Firewalls are identical, aside from hostnames and licenses, there is
rarely a reason to prefer one to another from a network design standpoint. Nevertheless, you
must identify one of the units as the primary unit. Surprisingly, this is not done from the command line, but rather, it is a function of hardware. The failover cable has two ends that are
labeled. This cable controls which box is primary and secondary. To identify a box as the primary unit, connect the end of the failover cable labeled “primary” to the desired unit. The
device on the other end will be the secondary unit.
At this point, you might have begun to wonder about the logistical details of the PIX Firewall’s failover feature: How do the active and standby firewalls monitor each other for a failure? What do they monitor and how often? How do you keep changes to the configuration
synchronized? In the following sections, we will answer all of these questions and more.
Failover Monitoring
The standby unit monitors the active unit in three ways:
By listening for hello packets via the LAN interfaces
By listening for hello packets via the failover cable
By testing the power status via the failover cable
All three of these activities happen on a periodic basis, which is every 15 seconds by default.
Thus, a failure can be declared one of several different ways, including when an interface is
down, when hello packets are missing, when a unit is powered off, or when the failover cable
is unplugged.
A Down Interface
When a network interface is down, the PIX Firewall will consider itself failed. This status is part
of the operation of Ethernet. It is a report from the Data-Link layer that tells you whether the
interface is administratively down, down, or up. An administratively down interface will not
cause a failover. This monitoring protects against low-level problems, such as an unplugged network cable, a damaged or “out-of-spec” cable, or a powered-off or otherwise inoperable hub
or switch.
200
Chapter 5
Firewall Failover and PDM
The status of the interface can be seen in the output of the show interface command. For
example, if we unplug the cable connected to ethernet0 and shut down ethernet2, the show
interface command might show the following output:
PIX(config)# interface ethernet2 shutdown
PIX(config)# exit
PIX# show interface
interface ethernet0 "outside" is up, line protocol is down
Hardware is i82559 ethernet, address is 0050.54ff.076d
IP address 37.20.5.2, subnet mask 255.255.255.240
MTU 1500 bytes, BW 10000 Kbit half duplex
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored,
0 abort
1 packets output, 64 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collisions, 0 deferred
1 lost carrier, 0 no carrier
input queue (curr/max blocks): hardware (128/128)
software(0/0)
output queue (curr/max blocks): hardware (0/2)
software (0/1)
interface ethernet1 "inside" is up, line protocol is up
Hardware is i82559 ethernet, address is 0050.54ff.076e
IP address 10.1.0.1, subnet mask 255.255.255.0
MTU 1500 bytes, BW 100000 Kbit full duplex
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored,
0 abort
1 packets output, 64 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collisions, 0 deferred
1 lost carrier, 0 no carrier
input queue (curr/max blocks): hardware (128/128)
software(0/0)
output queue (curr/max blocks): hardware (0/2)
software (0/1)
interface ethernet2 "dmz" is administratively down, line protocol is up
Hardware is i82559 ethernet, address is 00d0.b79d.8856
PIX Firewall Failover
201
IP address 192.168.1.1, subnet mask 255.255.255.0
MTU 1500 bytes, BW 100000 Kbit full duplex
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored,
0 abort
1 packets output, 64 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collisions, 0 deferred
1 lost carrier, 0 no carrier
input queue (curr/max blocks): hardware (128/128)
software(0/0)
output queue (curr/max blocks): hardware (0/2)
software (0/1)
PIX#
Note that on Cisco IOS routers, when an interface is shut down, it is in an “administratively
down/down” state, but on the PIX Firewall, we see that the line protocol is up, even though
ethernet2 is administratively down. This condition occurs because the interface is getting link
status but has been shut down by the administrator. If link status were not present, the interface
would be in “administratively down/down” state. As far as failover is concerned, the line protocol status does not matter if the interface is administratively down.
Missing Hello Packets
Another way the PIX Firewall detects a failure is by missing hello packets. After three consecutive poll intervals (by default, 15 seconds each, for a total of 45 seconds) without receiving a
hello packet on a network interface, the PIX Firewall will put that interface into a testing mode.
If the interface fails this test, the PIX Firewall will consider itself failed. This test is nonintrusive,
which means the firewall will continue forwarding traffic during the testing, if possible.
The interface test has four parts:
Test 1 The PIX Firewall begins by checking to see if the interface is up or down. This is the
same as the previous check. If the interface passes this test, it continues to the next. If it is down,
the unit is declared failed.
Test 2 If the interface is up, the PIX Firewall will check for activity on the interface. The PIX
Firewall listens for a frame for 5 seconds. If a frame is received, the interface passes the test. If
a frame is not received for 5 consecutive seconds, it is still possible that the interface is okay, but
not very busy.
Test 3 The next test is more active. The PIX Firewall takes the last ten IP addresses in its ARP
cache and sends an ARP request for them, one at a time. If at any time the firewall receives a
response to a request, the interface is declared okay and further testing is halted. In the unlikely
event that the PIX Firewall goes through all 10 ARP requests without receiving a response (for
202
Chapter 5
Firewall Failover and PDM
instance, if the last 10 users had turned their PCs on, sent some traffic to the Internet, then powered their PCs back off almost simultaneously), it continues to the next test.
Test 4 The last test is certainly a desperation move to generate some traffic. The PIX Firewall
sends a ping to the broadcast address of its subnet. If any device responds, the interface attempts
the ARP test again. If no packets are received, the interface is declared down and the PIX Firewall considers itself failed.
These last three tests are important because the active and standby units are often plugged
into different physical switches for redundancy. After all, there is not much point in paying for
two firewall units if a single failure in a switch can render them both useless.
When the active and standby units are plugged into different switches, it is possible for some
component upstream to fail, such as another port on the switch. Such a failure would prevent
the PIX Firewall from communicating with the rest of the network without dropping the Ethernet circuit. If the PIX Firewall relied only on the interface status, many common upstream failures could occur, and the PIX Firewall would never switch over to the standby unit.
This higher layer testing is particularly important because the last three tests are not performed individually. One unit initiates the test, but after each test, that unit consults the other
unit. If it sees traffic and the other unit has not, it fails the other unit. If it has not seen traffic
and the other unit has, it fails itself.
Power Loss or Unplugged Failover Cable
In addition to determining which unit is primary and secondary, the failover cable’s internal
wiring is also wired in such a way that both units can tell if one or both ends of the cable are
plugged in. This is accomplished by looping wires back inside the cable. Each unit can also tell
if the other firewall is powered on.
When a unit detects that its partner is powered off, it will assume the active role. However,
when the units detect that the failover cable is unplugged, they maintain their current status.
This makes sense when you consider the alternatives. If both assumed the active role or both
assumed the standby role, network connectivity would be disrupted.
Configuration Replication
Just as the physical configuration of the PIX Firewalls must be identical, the command-line configuration of the units also must be identical. Keeping these units identical could be a daunting,
if not impossible task, in a volatile environment. Fortunately, the PIX Firewall makes this part
easy by replicating the configuration from the active to the standby units in a few different ways:
Replication at startup When the primary unit finishes booting up and becomes the active unit,
it will copy its entire configuration to the standby unit over the failover cable. This ensures both
units begin service in sync.
Replication when commands are entered As you type configuration commands on the active
unit (and you should type them only into the active unit), each instruction is also sent from the
memory of the active unit across the failover cable to the memory of the standby unit. This
PIX Firewall Failover
203
ensures that the units stay in sync while they are in service. However, remember that you need
to save the configuration changes to flash by using the write memory command.
Replication on demand You also have the ability to force a complete configuration replication using the write standby command. This sends the entire configuration across the failover
cable to memory in the standby unit.
Stateful Failover
After reading about how the PIX Firewall handles failover, you might still be wondering about
what happens to the xlate table and how this affects existing sessions.
Prior to version 5.1 of the PIX operating system, very little information was passed over the
failover cable. In fact, little more than the configuration information and hello packets were sent
to the standby firewall. This was a problem because when a switchover occurred, the standby
unit was correctly configured, but its xlate table was empty. Thus, the users of the network
would be forced to reestablish their sessions, even though they did not need to reconfigure their
machines. When a switchover occurred, the new active PIX Firewall would need to reassign all
of the NATs and rebuild all of its connection tables because all knowledge of the translation
slots and connection slots was lost.
Stateful failover provides the solution to the problem above. It communicates information
about current connections to the backup node. Some of the more notable information passed
to the secondary node includes the global address pools and their status, the TCP connection
table, and the xlate table. Other information helps perform some miscellaneous failover tasks,
such as keeping the clocks synchronized. This allows a switchover from the active to the passive
node to be transparent to users of most applications.
Notably missing in this list of applications are HTTP and most UDP applications. Support
for HTTP connections appeared in version 6.0. So in version 6.0 and later, you have the option
of including or not including stateful failover information for HTTP traffic. This is important
because a significant amount, if not the majority, of traffic flowing through firewalls is Web
browsing. Turning this feature on could have a performance impact. And, to some extent, many
users are conditioned by the typically unreliable Internet weather, and they are acquainted with
the Refresh and Reload buttons.
In version 5.2, Cisco increased the speed of the failover serial cable from very, very slow
(9,600bps), to just very slow (115Kbps). However, this still isn’t enough bandwidth to support
the potentially massive state information since practically every packet that passes through the
PIX Firewall changes the state of some connection. Remember that the PIX not only keeps track
of the source and destination addresses and ports, but also tracks the TCP sequence and
acknowledgment numbers, which change in every packet.
Cisco’s solution to the bandwidth problem is that stateful failover requires a dedicated
100Mbps Ethernet connection in addition to the serial failover cable. This means you need a
spare Ethernet interface on both the primary and standby PIX Firewalls, configured with IP
addresses and dedicated to failover. This is pictured physically in Figure 5.3 and logically in
Figure 5.4.
204
Chapter 5
FIGURE 5.3
Firewall Failover and PDM
Physical stateful failover
Internet
Router
Switch
Failover
Ethernet cable
Outside
Outside
PIX
PIX
Inside
Inside
Failover
serial cable
Switch
Private net
Basic Failover Configuration
Fortunately, configuring failover is very simple. It takes only a few commands, and these are all
a subset of the aptly named failover command. The syntax for this command is as follows:
PIX(config)# failover ?
usage: [no] failover [active]
failover ip address if_name ip_address
failover reset
failover link if_name
failover poll seconds
failover replication http
PIX(config)#
PIX Firewall Failover
FIGURE 5.4
205
Logical stateful failover
Internet
Router
.1
208.101.53.0 /24
Failover Ethernet segment
Outside
.2
.1
10.254.254.0
.2
.3
PIX
Inside
Outside
PIX
.2
.3
Inside
Failover serial cable
10.1.1.0 /24
Private net
The defaults for these commands are as follows:
no failover
failover timeout 0:00:00
failover poll 15
failover ip address outside 0.0.0.0
failover ip address inside 0.0.0.0
failover ip address dmz 0.0.0.0
Note that it is possible to use stateful or nonstateful failover. Nonstateful failover might be
appropriate in the following circumstances:
You do not have a spare Ethernet interface because of cost or because you are using the
maximum number of interfaces the PIX Firewall’s chassis supports.
You are primarily using UDP or other applications that do not require stateful information.
In rare cases, performance might justify a decision to forego stateful failover.
Let’s now discuss the difference between stateful and nonstateful failover configuration. We
will also discuss how and why to change both the polling interval and a PIX Firewall’s role.
206
Chapter 5
Firewall Failover and PDM
Nonstateful Failover Configuration
The failover and failover ip address commands are all that are required to configure nonstateful failover. Specifically, since the default is no failover, you need to issue the command
failover to enable failover. And since you enter configuration commands only on the active
node and not the secondary node, you need a way to tell the secondary node what its IP
addresses are. This is accomplished by the failover ip address command.
For example, let’s suppose you have inside, outside, and DMZ interfaces, with the IP addresses
10.1.1.1, 10.1.2.1, and 10.1.3.1, respectively, on the active PIX Firewall. To configure the
standby PIX Firewall, you would issue the following:
PIX(config)# failover ip address inside 10.1.1.2
PIX(config)# failover ip address outside 10.1.2.2
PIX(config)# failover ip address dmz 10.1.3.2
PIX(config)#
Notice that the standby’s interfaces can be any address on the same subnet. Because these
interfaces will be used as part of the failover testing to determine whether an interface is up or
down, each interface must have an IP address.
Stateful Failover Configuration
For stateful failover, you need to also specify the link you want to use for the failover link. For
example, if you wanted to use ethernet3 as the failover link, you could name it faileth3 with
the nameif command, and then use the failover link command, as follows:
PIX(config)# failover link faileth3
PIX(config)#
Once you enter the failover link command, stateful failover is enabled.
The state information is passed across this Ethernet (FastEthernet, actually) link via IP—specifically, IP protocol 105. Although it is recommended that you use a crossover cable and
directly connect the two firewall units, you could run this connection through a hub or switch.
Finally, if you want to include Web traffic in your stateful failover (available in version 6.0
and higher), you will need to issue the following command:
PIX(config)# failover replication http
PIX(config)#
Poll Interval Configuration
Another common configuration is adjusting the polling interval. With most timers in IOS routers and switches, the default settings are typically the best, and it’s recommended that you do
not change them unless you really have a compelling reason to do so. The polling interval for
the PIX Firewall failover feature is different. In most cases, you should change this number to
better suit the characteristics of your network.
PIX Firewall Failover
207
The polling interval itself is fairly simple. When two PIX Firewalls are configured for
failover, the standby firewall will send messages to the active firewall on each interface every x
number of seconds, where x is the polling interval. If the standby PIX Firewall does not hear a
response from the active PIX Firewall for three polling intervals, it begins its failover sequence
to become the active unit.
The default polling interval is 15 seconds. The minimum value is 3 seconds. So by default, the
standby PIX Firewall will wait between 31 and 45 seconds (two polling intervals, plus part of a
third, since we do not expect the active unit to fail precisely at the beginning of a polling interval)
before initiating the failover sequence. If the polling interval were set to 3 seconds, the standby
PIX Firewall would wait between 7 and 9 seconds before initiating the failover sequence.
As you can see, there is quite a difference between 9 and 45 seconds. So you might think,
“Why not always set it to 3 seconds?” The problem is that in a busy network, it’s not unusual
to see a link congested for 6 to 9 seconds. This could result in an accidental failover because the
standby thinks the active is down, when in fact, it is just busy. Of course, you might still have
this problem with the default setting of 15 seconds, but it is much less likely to occur.
Finding the best setting for your network is a matter of trial and error. If your network is not
busy, go ahead and use the lower settings. If you experience unwarranted failovers, raise the poll
interval until they stop.
For stateful failover, you need to consider the primary type of traffic you have. Some applications will time out after 30 seconds and force you to reestablish them. If your PIX Firewall
failovers always take 31 or more seconds, there isn’t much point in exchanging all that stateful
information because the bulk of that information includes things such as TCP sequence numbers, which will be reset when your application session is reestablished anyway. So, for stateful
failover, you will want to use the lowest poll interval possible.
To set the polling interval, use the failover poll command. For instance, if you wanted
to change the polling interval to 4 seconds, you would issue this command:
PIX(config)# failover poll 4
PIX(config)#
You should also note that this timer is set for the entire system. Although it might be very useful, you cannot set different interfaces to have different poll intervals.
Role Configuration
As explained earlier in the chapter, by default, the active unit will be the primary unit. However,
for maintenance and other purposes, you can force a failover to occur so that the secondary unit
is the active unit. The command to force a failover is simple:
[no] failover active
To force the secondary unit to become active, you would enter the following command from
the primary unit:
failover active
208
Chapter 5
Firewall Failover and PDM
To switch service back to the primary unit, you would enter the following command from
the secondary unit:
no failover active
Cisco PIX Device Manager (PDM)
PDM is used to create security rules on a single PIX Firewall or FWSM from a Web browser.
We will have an overview of the PDM and what it does, its operating requirements, how to prepare for PDM, and using the PDM to configure the PIX Firewall.
PDM Overview
The PDM is a very powerful graphical user interface (GUI) that assists you in setting up and configuring a PIX Firewall without requiring an extensive knowledge of the PIX Firewall commandline interface (CLI). It also offers a wide range of informative, real-time, and historical reports
that provide a view into usage trends, performance baselines, and security events. Many security
vulnerabilities are caused by poor configuration. Consequently, implementing security policy
must be as straightforward as possible. PDM includes wizards, point-and-click configuration,
and online help to simplify administration.
PDM offers helpful wizards for setting up a new PIX deployment. With just a few steps, the
PDM Setup Wizard enables you to efficiently create a basic configuration that allows packets
to flow through the PIX Firewall from the inside network to the outside network securely. You
can also perform optional tasks such as configuring rules to allow outside access to a Web or
mail server. After you complete initial setup, intuitive pull-down menus and icons enable you
to easily add and delete services and rules as well as access other feature settings. The PDM will
send the correct CLI commands to the PIX Firewall unit for the configuration you choose.
Using the PDM, you can easily configure, manage, and monitor security policies across your
network. PDM's GUI provides a familiar tabbed layout using task-oriented menu choices, dropdown menus, and browse options with one-click access to common tasks. The point-and-click
design is simple for even novice users, reducing orientation time. The result is cost savings
through significant reductions in management time and maximum efficiency in network security management.
PDM is implemented in Java to provide robust reporting and monitoring tools that provide
you with real-time and historical insights. At a glance, administrators can view graphical
reports summarizing network activity, resource utilization, and event logs, allowing performance and trend analysis. Data from each graph can be displayed in increments you select (10second snapshot, last 10 minutes, last 60 minutes, last 12 hours, last 5 days) and refreshed at
user-defined intervals. The ability to view multiple graphs simultaneously allows you to do sideby-side analysis.
The PDM applet uploads to your workstation when you access the PIX Firewall from your
browser. PDM works with the Secure Sockets Layer (SSL) protocol to ensure that communication
Cisco PIX Device Manager (PDM)
209
with the PIX Firewall unit is secure. Cisco PDM has an integrated syslog viewer, which allows you
to view specific syslog message types by selecting the desired logging level.
Similar to Telnet and SSH usage, PDM enables you to protect access with a valid username
and password. This can either be on the PIX Firewall or through an authentication server.
If you remember from Chapter 1, the FWSM has some differences from the standalone PIX
Firewall. These differences also affect how the PDM interacts with the FWSM. Specifically, any
OSPF or VPN configuration commands are ignored but not changed by PDM. Everything else
in the PDM is compatible with the FWSM.
In the following sections, we will look at the operating requirements and how to prepare the
firewall for the PDM. Finally, we will go over how to configure the PIX Firewall via the PDM
and we highlight some of its key features.
Operating Requirements
The firewall requirements for running PDM is to have a Cisco PIX Firewall 501, 506E, 515E,
520, 525, 535, or FWSM with at least 32MB of RAM and 16MB of Flash (PIX Firewall 501,
506, and 506E require 8MB). The firewall must be running version 6.0 or higher or the PIX
operating system with either DES or 3DES enabled.
The requirement for running PDM on the user machine is a Pentium or Pentium-compatible
processor running 300MHz, but 500MHz is recommended. It must have at least 128MB of
RAM with 192MB recommended, a display resolution of 800 × 600 pixels using 256 colors
with 1024 768 pixels using 16-bit color is recommended. The minimum network connection
speed is 56Kbps, with 128Kbps recommended.
Table 5.1 lists the operating systems and browser combinations and their respective versions.
TABLE 5.1
Operating Systems and Browsers Supported by PDM
Operating Systems
Browsers
Windows 2000 (Service Pack 1)
MS Internet Explorer 5.01 (Service Pack 1) or
higher (5.5 recommended)
Windows NT 4.0 (Service Pack 6a)
Netscape Communicator 4.51 or higher
(4.76 recommended)
Windows 98 (original or 2nd edition)
Sun Solaris 2.6 or 2.8 running CDE or Open
Windows window manager
Redhat Linux 6.2 or 7.0 running GNOME or
KDE 2.0 desktop environment
Netscape Communicator 4.76
210
Chapter 5
Firewall Failover and PDM
PDM is not supported on computers running Macintosh, Windows 3.1, or Window 95 operating systems, including Solaris on IBM PCs.
Preparing for PDM
If the PIX Firewall does not have the PDM loaded or if you need to upgrade to a later version,
then you need to TFTP the software image from the TFTP server to the PIX Firewall. If you are
familiar with upgrading the PIX Firewall software image, this is very similar. The command
used to download a software image to the PIX Firewall is copy tftp flash and the command
to download the PDM software image to the PIX Firewall is copy tftp flash:pdm. Here is
an example of using this command to install the PDM onto a PIX Firewall:
PIX# copy tftp flash:pdm
Address or name of remote host [127.0.0.1]? 172.17.141.20
Source file name [cdisk]? pdm-211.bin
copying tftp://172.17.141.20/pdm-211.bin to flash:pdm
[yes|no|again]? yes
Erasing current PDM file
Writing new PDM file
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!
PDM file installed.
PIX#
Now that you have the PDM installed, to prepare for running PDM you need either to run
the setup command to configure the PIX Firewall to be accessible from one IP address or to
manually enter the commands via the CLI for PDM operation. Below you can see an example
of using the setup command on a PIX Firewall, which has an existing configuration (the irrelevant portions have been omitted):
PIX(config)# setup
Cisco PIX Device Manager (PDM)
Pre-configure PIX Firewall now through interactive prompts [yes]?
Enable password [use current password]:
Clock (UTC):
Year [2003]:
Month [Mar]:
Day [20]:
Time [11:52:43]:
Inside IP address [192.168.21.1]:
Inside network mask [255.255.255.0]:
Host name [PIX]:
Domain name [sybex.com]:
IP address of host running PIX Device Manager: 172.17.141.200
The following configuration will be used:
Enable password: current passwordClock (UTC): 11:52:43 Mar 20 2003
Inside IP address: 192.168.21.1
Inside network mask: 255.255.255.0
Host name: PIX
Domain name: sybex.com
IP address of host running PIX Device Manager: 172.17.141.200
Use this configuration and write to flash? y
Building configuration...
Cryptochecksum: d8ab4e71 a1881144 b7db3938 0a3f8bfa
[OK]
PIX(config)# wr t
Building configuration...
: Saved
:
PIX Version 6.2(2)
hostname PIX
pdm history enable
http server enable
http 172.17.141.200 255.255.255.255 inside
: end
[OK]
PIX(config)#
211
212
Chapter 5
Firewall Failover and PDM
As you can see from the above example, the PIX Firewall has turned on the HTTP server with
the http server enable command and made it so my workstation at 172.17.141.200 has to
access the PDM with the http 172.17.141.200 255.255.255.255 inside command. The
pdm history enable command is a default command.
You can also manually place these commands in the PIX Firewall configuration if you are not
too keen on using the setup command. To reiterate, you need to turn on the HTTP server with
the http server enable command and then make sure you allow HTTP connections to the
PIX Firewall using the http command followed by the IP address and mask of the allowed hosts
and the interface they will be using.
Because the PIX Firewall uses the SSL protocol to provide a secure transport
for the PDM traffic, you are able to configure HTTP access to the outside interface.
Using PDM to Configure the PIX Firewall
Once you have set up the PIX Firewall to run PDM, you need to open up a browser of your
choice from the ones supported. If your PIX Firewall was set up with the inside IP address of
172.17.140.23, then you need to type in the following URL: https://172.17.140.23. At this
point, you might see a couple of security alerts that you need to choose Yes for, which will open
a login window like the one in Figure 5.5.
FIGURE 5.5
Login Authentication
If you have set up AAA authentication, then this is where you would enter the username and
password. If there is no AAA, then the username will be left blank and the enable password
should be used. If there is no enable password, then also leave the password field blank. This
will spawn two more windows, with an example in Figure 5.6.
This window shows the PIX Firewall model, software version, PDM version, and information about your workstation. The second window is a Java window with the titled Cisco PIX
Device Manager followed by the version, as seen in Figure 5.7.
Cisco PIX Device Manager (PDM)
FIGURE 5.6
213
Cisco PIX Device Manager Information Window
This is the window that will be used to configure your PIX Firewall. If you look under the
row of icons, you will see tabs for Access Rules, Transition Rules, VPN, Hosts/Networks, System Properties, and Monitoring. We will go over each of these so you are at least familiar with
the user interface and what is configurable from each tab.
We will not go over the VPN tab in this chapter, but we will discuss this in further detail in the next chapter when talking about VPNs using the PIX Firewall.
Figure 5.7 shows the Access Rules tab, which shows the configured access rules, AAA rules,
and filter rules. You can see the implicit outbound rule for each none outside interface. The two
rules represent the two none outside interfaces, which in this case are the inside and dmz interfaces. Click on the radio button next to the set of rules you would like to see and configure. To
add a rule, click the Rules drop-down menu on the top of the window and choose add.
Figure 5.8 shows an example of adding a rule, in this case, an access rule, and the options
available.
214
Chapter 5
Firewall Failover and PDM
FIGURE 5.7
Cisco PIX Device Manager 2.1
FIGURE 5.8
Adding an access rule
Cisco PIX Device Manager (PDM)
215
The Translations Rule tab shows the transition rules defined on the PIX Firewall. As you can
see from Figure 5.9, there are currently no transition rules defined.
As on the Access Rules tab, by clicking the Rules drop-down menu on the top of the window
and choosing add, you can add a static or dynamic transition rule to the PIX Firewall configuration. Figure 5.10 is an example of the screen you would see when adding a transition rule to
the firewall.
Figure 5.11 shows the contents of the Hosts/Network tab.
If you remember back in Chapter 3, “ACLs, Filtering, Object Grouping, and AAA,” when
talking about object groups, we said that they would be more apparent when talking about the
PDM. The Hosts/Networks tab is where you would set up network object groups and also be
able to nest one group inside another. You add a network or host by clicking on the Add button
in the Hosts/Networks section, and similarly, you can add a group of Hosts or networks by
clicking on the Add button in the Hosts/Networks Group section.
FIGURE 5.9
The Transition Rules tab
216
Chapter 5
Firewall Failover and PDM
FIGURE 5.10
Adding a transition rule
FIGURE 5.11
Hosts/Networks
Cisco PIX Device Manager (PDM)
217
You can add individual hosts or whole networks to the PIX Firewall configuration and later
use those in access rules to make your configuration more readable and scalable. You can also
configure the NAT properties of the host or network at the time you create the object. As you
can see from Figure 5.11, we have added two hosts called WebServer1, with IP address
192.168.21.200, and WebServer2, with IP address 192.168.21.100. We have also added a
group called WebServers containing both WebServer1 and WebServer2. Now we can add an
access rule to allow access to these Web Servers by using the WebServer group and not having
to use their respective IP addresses.
The System Properties tab is used to view and configure the PIX Firewall system properties.
You can see from Figure 5.12 the options available for configuration. We will not be going into
each of these, but you should explore them when you have a chance.
The Monitoring tab is used to check on the health of the PIX Firewall. As you can see from
Figure 5.13, there are many options available to be monitored.
You can choose many different items to monitor in real time. You choose which category to
view and then select the available graphs within that category. You then add that graph to your
selected graphs and click Graph It! when you are done. In Figure 5.14, we have selected the CPU
Utilization graph, and in Figure 5.15, we have selected the Memory Utilization graph.
FIGURE 5.12
The System Properties tab
218
Chapter 5
Firewall Failover and PDM
FIGURE 5.13
The Monitoring tab
FIGURE 5.14
Selecting the CPU Utilization graph
Cisco PIX Device Manager (PDM)
FIGURE 5.15
219
Selecting the Memory Utilization graph
You can select up to four graphs to view at a time, but you can have multiple graph windows
open at a time. Figure 5.16 shows what it looks like when you click on the Graph It! button.
There are two icon buttons that you need to be aware of that you might use quite often when
using the PDM. They are together in the middle of the icon button bar below the drop-down
menus (you can see these in Figure 5.7).
The first icon button looks like a circular arrow and when you move the mouse over it the
text reads “Refresh PDM with the Running Configuration on the Firewall”. This button will
update the PDM with the configuration of the firewall. This is used to make sure the PDM
has the latest configuration from the firewall. There is no way for the PDM to know that
someone has modified the configuration of the PIX Firewall from the console and not from
the PDM.
The second icon button looks like a diskette and when you move the mouse over it the text
reads “Save Running Configuration to Flash”. This is used to save the current running configuration in the PIX Firewall to flash. Changes are saved to the running configuration as you
change from one tab to another, but this configuration is not saved to flash until you explicitly
do so.
220
Chapter 5
FIGURE 5.16
Firewall Failover and PDM
Graphing CPU and memory utilization
Summary
In this chapter, we discussed the basic failover concepts of points of failure, single points of failure, and fault tolerance. We then explained how the PIX Firewall’s hardware and software are
points of failure, and how Cisco has mitigated the risk of failure using the failover feature.
We next discussed the PIX Firewall failover feature. You learned how PIX failover operates,
what stateful failover is, and how to configure the PIX Firewall for failover.
The remainder of the chapter covered how to install and configure the PIX Firewall for configuration by the PDM (PIX Device Manager). We talked about the firewall and user requirements in addition to how the GUI operates and some of its useful features.
Key Terms
221
Exam Essentials
Know what a point of failure is. Understand the concept of points of failure and single points
of failure. Be able to identify them and describe what to expect when they occur.
Understand the difference between redundancy and load balancing. Be able to distinguish
between these strategies. Understand the traffic patterns and special challenges associated with
each one.
Understand the hardware requirements for configuring failover. Remember what hardware
you need. Know which cables must be connected where and what licenses you need to purchase.
Be able to describe the special hardware requirements for stateful failover.
Know the configuration syntax used to configure failover. Be able to identify the command
lines required to configure failover and stateful failover. Know which unit to configure.
Understand the process used to failover. Know how the active and standby units communicate. Know what information is transmitted over the serial and Ethernet cables. Understand
how polling works. Know what information is shared in stateful failover.
Understand what circumstances will trigger a failover. Given a set of conditions, be able to
determine whether the primary or secondary PIX Firewall will be active.
Know the PIX Firewall and user operating requirements to use PDM. You should know which
version of the PIX operating system must be installed to use the PDM. You need to know which
user operating systems and browser versions will work with PDM.
Understand how to enable PDM on the PIX Firewall. Know the methods used to enable
PDM on the PIX Firewall using the setup command and manually configuring the http commands.
Key Terms
Before you take the exam, be certain you are familiar with the following terms:
active unit
primary unit
Cisco PIX Device Manager
secondary unit
fault tolerance
Secure Sockets Layer
highly reliable
single point of failure
load balancing
standby unit
point of failure
stateful failover
222
Chapter 5
Firewall Failover and PDM
Written Lab
1.
Which license must be purchased for the failover feature to be available?
2.
How many standby firewalls can be associated with an active PIX Firewall?
3.
Which failover communications interface must be used for stateful failover to occur?
4.
As long as both PIX Firewalls have the same number and types of interfaces and they are
running the same version of the software, they can be paired in a failover configuration.
True or false?
5.
Which configuration options will be replicated from the standby to the active firewall when
modifying the standby’s configuration?
6.
To simulate a failover scenario, just unplug the failover serial cable. True or false?
7.
Where is the PDM stored on the PIX Firewall?
8.
When running the PDM from a Macintosh, Windows 3.1, Windows 95, or Solaris on a PC,
what must also be installed?
9.
Which command is used to download a new PDM image to the PIX Firewall?
10. Which section of the PDM interface do you find graphing capabilities?
Review Questions
223
Review Questions
1.
In a network with two routers configured redundantly, each router could be which of the
following?
A. Point of failure
B. Single point of failure
C. Fault domain
D. Redundant point of failure
2.
In a network with no single points of failure, how many failures must occur to disrupt connectivity?
A. None
B. One
C. Two or more
D. No disruption can occur
3.
The active and standby PIX Firewalls communicate over which interface?
A. Failover serial port
B. Failover link interface
C. Inside interface
D. Interface with the highest IP address
E. All interfaces
4.
How do you configure a unit to be the primary unit?
A. With the failover primary command
B. With the no failover secondary command
C. With the failover primary active command
D. It depends on the orientation of the failover serial cable.
E. It depends on the orientation of the failover link cable.
5.
You have two PIX Firewalls configured for failover. Each is connected to the inside, outside,
dmz1, and dmz2 networks. How many interfaces must fail before the standby becomes the
active firewall?
A. One interface
B. Two interfaces
C. Three interfaces
D. All four interfaces
224
6.
Chapter 5
Firewall Failover and PDM
Which of the following does the PIX Firewall failover feature not do?
A. Automatically replicate configuration
B. Load-balance traffic
C. Replicate state information
D. Swap IP and MAC addresses during a failover
7.
Which of the following is not detected by the standby PIX Firewall about the active firewall
through the serial failover cable?
A. Whether it is powered on or off
B. Whether it is connected to the serial cable
C. Whether it is the primary or secondary unit
D. Whether it is congested
8.
The failover serial cable determines which of the following?
A. Whether a unit is active or standby
B. Whether a unit is primary or secondary
C. Whether a unit will preempt the other
D. None of the above
9.
How many graphs can be displayed in one window?
A. 2
B. 4
C. 8
D. Unlimited
10. Which rule type can be created on the Access Rules tab?
A. Access rules
B. AAA rules
C. Filter rules
D. All of the above
Answers to Written Lab
225
Answers to Written Lab
1.
You must have the unrestricted license for failover to be an option.
2.
There can be only one standby PIX Firewall.
3.
Stateful failover requires a LAN based failover interface.
4.
False: Both must be the same model of PIX Firewall.
5.
None: They will be over written by the active PIX Firewall.
6.
False: The PIX Firewall will know that the failover cable has been pulled and will not fail
over to the standby firewall.
7.
The PDM image is stored in flash memory.
8.
PDM is not supported on these platforms, so there is nothing to install.
9.
The copy tftp flash:pdm command is used to download a file and place it in the PDM
section of flash memory.
10. The monitoring section is where the graphing capability is found.
226
Chapter 5
Firewall Failover and PDM
Answers to Review Questions
1.
A. Answers C and D are fictitious. Since connectivity will not be disrupted when one router fails,
it’s just a point of failure, not a single point of failure.
2.
C. By definition, more than one failure must occur, which means at least two or more failures
must occur to disrupt connectivity.
3.
E. The standby unit polls every interface on the active unit and expects responses. Stateful information is transmitted only over the failover link. Configuration information is transmitted over
the serial link, and table information is sent via the failover link interface.
4.
D. The ends of the failover serial cable are labeled, indicating which side will be the primary unit
and which side will be the secondary unit.
5.
A. It takes only one failure to fail the entire primary firewall. The secondary will take over all
interfaces.
6.
B. The PIX Firewall uses a redundant configuration, not a load-balancing one. One unit is
always passive.
7.
D. The wiring of the failover cable allows each unit to know that another unit is connected, powered on, and primary or secondary.
8.
B. Whether a unit is active or standby is determined by the failure state of the units. Both units
will always take over when their partner fails.
9.
B. There can be up to four graphs displayed in a single window, but you can have multiple graph
windows open.
10. D. You can create all of the above rules within the Access Rules tab.
Chapter
6
VPNs and the
PIX Firewall
THE FOLLOWING TOPICS ARE COVERED IN
THIS CHAPTER:
How a PIX Firewall enables a secure VPN
Configuring the PIX Firewall for VPN support
Configuring IKE and IPSec parameters on the PIX Firewall
Testing and verifying the VPN configuration on the
PIX Firewall
How the Cisco VPN client operates
How the PIX Firewall can scale for multiple VPNs
Using the PDM to create site-to-site and remote access VPNs
Using the PDM to configure access and translation rules
Overview of PDM reporting, tools, and administration
Overview of the auto-update server
Setting the PIX Firewall and AUS communication settings
Creating devices, images, and assignments in the PIX MC
Using the PIX MC reports and administration
This chapter will describe how to configure the PIX Firewall to support IPSec tunnels using both preshared keys and digital certificates
through certificate authorities. We will discuss how to configure
the IKE/ISAKMP parameters and learn the commands to test and verify your VPN configuration
on the PIX Firewall. Next we will talk about the Cisco VPN client and how to scale PIX Firewall
VPNs. We will show you how to use the PIX Device Manager to create both site-to-site and
remote access VPNs.
Finally, we will talk about how to do enterprise management and maintenance using the Cisco
Secure Policy Manager and CiscoWorks2000. The PIX Firewall can be integrated into CiscoWorks2000 using two components of the VPN/Security Management Solution: the Management
Console for PIX Firewalls and the Auto Update Server.
Preparing to Configure VPN support
The PIX Firewall enables a secure VPN by using IPSec tunnels, which can encrypt the tunnel
using DES or 3DES encryption algorithms. When preparing for IPSec VPN configuration on a
PIX Firewall, you need to decide what the tunnel will be used for, if this is the only tunnel, and
what kind of security is required.
There is not as much flexibility regarding tunnel termination when the tunnel ends at a PIX
Firewall. Older versions of the PIX Firewall software required that a VPN terminate only on the
outside interface. Newer versions (5.1 and later) allow tunnels to terminate on any interface.
To prepare for IPSec configuration, you will need to perform the following tasks:
Gather information. Determine how the devices will refer to the peers—as either IP address or
hostname—and what type of configuration will be used to build the IKE tunnel.
Decide which IKE policy (or policies) will be used for the tunnel. Are the IKE policy parameter values using RSA signatures or a preshared secret for authentication? How is the information going to be encrypted between IKE peers? Which Diffie-Hellman group is going to be used?
What is the tunnel’s lifetime?
Decide how IPSec will be configured. Consider how IPSec Security Associations (SAs) will be
formed, which transforms you will use, and what type of traffic will be protected.
Make sure that network connectivity exists. The simplest way of doing this is with a Ping.
Note that firewalls usually need to explicitly permit ICMP traffic in using the icmp permit
command for this test to work properly.
Configuring IKE on a Firewall
229
Examine any existing ACLs to ensure that necessary traffic will not be blocked. Traffic
from IKE/ISAKMP (UDP port 500), AH (protocol 51), and ESP (protocol 50) should be permitted. While the Adaptive Security Algorithm (ASA) on the PIX Firewall will allow traffic to
return if it started on the local firewall, if the client starts the session, the packets will not be
allowed in unless the firewall is configured to allow the traffic through.
Cisco’s ASA is the basis for the PIX Firewall’s security. The ASA uses assigned
security levels to allow interfaces to be configured securely. See Chapter 1,
“PIX Firewall Basics,” for more information about the ASA.
Configuring IKE on a Firewall
Configuring IKE is a simple task on the PIX Firewall primarily because each firewall comes with
a default protection suite that can be used to build the IKE communication. The Internet Security Association and Key Management Protocol (ISAKMP) is a framework that defines the procedures used for authenticating communication between two peers. Internet Key Exchange
(IKE) implements the Oakley and Skeme key exchange protocols within the ISAKMP framework, which automatically negotiates IPSec security associations and enables IPSec secure communications without manual preconfiguration.
In the following section, we will show you how to enable IKE on a firewall interface, configure
an IKE policy, and configure both preshared keys and digital certificates for IKE authentication.
Enabling IKE
IKE is enabled globally by default, and any changes that need to be made will be configured on
an interface-by-interface basis. This is different from the configuration on a Cisco IOS router,
where ISAKMP is enabled or disabled globally.
Use the isakmp enable interface-name to enable ISAKMP on the PIX Firewall for an
interface. To disable IKE on an interface, place a no before the command, for instance, no
isakmp enable. Leaving ISAKMP enabled on an interface that is not acting as a VPN tunnel
endpoint can be a security risk and should be avoided. The following is an example of the commands used to enable and disable IKE on an interface:
PIX(config)# isakmp enable outside
PIX(config)# no isakmp enable outside
PIX(config)#
230
Chapter 6
VPNs and the PIX Firewall
Configuring the IKE Policy
When IKE is enabled on an interface, the next step is to configure the IKE policy or what the PIX
Firewall calls a protection suite. To prepare for the configuration, examine the default policy template and deciding how much of it may be used for the tunnel being created. For example, if you
want to use preshared keys, you will need to change the default authentication method from RSA
signatures to preshared keys. Figure 6.1 shows an example of an IKE policy using preshared keys.
FIGURE 6.1
IKE tunnel details
Site 1
Site 2
PIX1
PIX2
Internet
e0
10.0.1.3
e0
192.168.1.2
IKE policy example
Parameter
Encryption algorithm
Hash algorithm
Authentication method
Key exchange
IKE SA lifetime
Peer IP address
Site 1
DES
MD5
Pre-shared keys
768-bit D-H
86,400 seconds
192.168.2.2
192.168.2.2
10.0.2.3
Site 2
DES
MD5
Pre-shared keys
768-bit D-H
86,400 seconds
192.168.1.2
Since the PIX Firewall has only one configuration mode, you will issue all of the configuration commands from Global Configuration mode. Each command used to modify a policy
property begins with isakmp policy number. Just as on the router, there are not an overwhelming number of options, but each one is important. The following are the policy configuration commands:
isakmp policy number encryption des | 3des
isakmp policy number hash md5 | sha
isakmp policy number authentication pre-share | rsa-sig
isakmp policy number group 1 | 2
isakmp policy number lifetime seconds
Remember that the number is the priority number, which links each of the separate lines together, and that the lower the priority number is, the higher the
preference for that policy.
Configuring IKE on a Firewall
231
Once each device has a policy configured, and interesting traffic triggers the process, both
devices can bring up an IKE tunnel. To allow the tunnel traffic to continue into the PIX Firewall,
use the command sysopt connection permit-ipsec.
Configuring Preshared Keys
Using preshared keys is the simplest way of setting up authentication in preparation for building
an IPSec tunnel. The disadvantages to using preshared keys are that they are inefficient for organizations that use many tunnels and they are the least scalable method.
The preconfigured keys must match between two devices for them to form an IKE tunnel. A firewall may be configured with a key that is used to communicate with two other firewalls and a software client. The same key string may be used to communicate with many different end devices, or
a firewall can be configured with a different key for each IKE tunnel that is to be created.
To configure a firewall to authenticate via a preshared key, specify the following:
ISAKMP peer Use the isakmp identity {address | hostname} command to tell the PIX
Firewall how it can expect peers to be defined. The identity of an ISAKMP peer will be defined
either by its IP address or by a hostname. This is a global command and applies to every peer
that this PIX Firewall will be talking to.
Hostname resolution You can use the name ip_address hostname command to create a
local name-to-address resolution table. If the first command was configured with the hostname
option, the firewall needs some way of resolving hostnames to IP addresses. One way of doing
this is with a DNS reference. Another is by creating a local translation table. This command is
not needed if the identity command specifies to reference with IP addresses.
ISAKMP key Use the isakmp key key_string {address | hostname} ip_address |
hostname command to establish what key will be used for what peer. This command establishes the key used, specifies if the peer will be referenced via IP address or via hostname, and
then lists the address or hostname used. The key may be up to 128 characters in length.
There is nothing preventing a PIX Firewall from using the same key to every one
of the peer devices it talks to, although this would not be a good security practice.
The following is an example of IKE configuration on a PIX Firewall:
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
sysopt
isakmp
isakmp
isakmp
isakmp
isakmp
isakmp
isakmp
connection permit-ipsec
enable outside
key sybex address 192.168.244.33
policy 80 authentication pre-share
policy 80 encryption des
policy 80 hash sha
policy 80 group 1
policy 80 lifetime 86400
232
Chapter 6
VPNs and the PIX Firewall
Configuring the Use of Certificate Authorities (CAs) on
a Firewall
Using a CA for authentication on a PIX Firewall is the preferred method when you need to scale
your VPN to a large number of devices. The information you will need to collect before enrolling a firewall with a CA and the procedure for enrolling are basically the same as they are for
enrolling a Cisco IOS router, if you are familiar with that platform.
Terminating several VPNs on a PIX Firewall is usually a bad idea. This can create a resource overload on your firewall if adequate evaluation is not performed. There is a hardware accelerator card that can be used to allow the PIX
Firewall to terminate many VPNs, but in general, if dozens or hundreds of tunnels are needed, it is best to consider using a VPN concentrator instead.
In the following section, we will discuss how to configure the PIX Firewall to use digital certificates for authentication. We will show how to prepare the PIX Firewall to communicate with
a CA and enrolling with the CA.
Preparing the Firewall for CAs
On a PIX Firewall, certificates will be stored in flash memory. Several certificates may be generated when you enroll with a CA: an ID certificate for the device, the CA’s ID certificate, and
a registration authority (RA) ID certificate. Before enrolling with the CA, you should examine
the flash to make sure that there is space available for storing the certificates and the keys.
Another preparatory step is to check the firewall clock setting to avoid problems with a certificate’s validity time range. We strongly suggest using a timeserver in the network and configuring the firewall to talk to that server via Network Time Protocol (NTP). To set the PIX
Firewall clock, use the clock set command. These commands were discussed in Chapter 2,
“PIX Firewall Configuration.”
In addition to setting the correct time, it is extremely important that a proper hostname and
domain name be established. It is possible to create the necessary keys without the domain being
set up, but if a domain name is not configured, the PIX Firewall uses a default domain of
ciscopix.com. If the default name has not been changed, the administrator will be told to
change it. To establish the domain name, use the command domain-name domain, which was
also discussed in Chapter 2. You should use a unique hostname because the host and domain
names are used in the keys, and using identical names is a small security risk. To change the
hostname, use the command hostname name.
Enrolling a Firewall with a CA
Before you enroll a firewall with a CA, you need to generate the keys, identify the CA, and authenticate the CA. After these steps, you need to save the keys and configuration. The PIX Firewall has
a separate command for configuring additional properties of the CA communication.
Configuring IKE on a Firewall
233
Generating the Keys
To generate the public and private keys that will be used with the certificates, use the ca generate
rsa key key_size command. If you remember from the last chapter, this command is also
needed to run the PIX Device Manager (PDM) GUI. PDM uses the Secure Sockets Layer (SSL)
protocol for secure communication, which uses the generated RSA key. The RSA key modulus
default size is 768 bits, as opposed to the Cisco IOS router’s default of 512 bits.
Here is an example of a general-purpose key configured on a PIX Firewall:
PIX(config)# ca generate rsa key 512
PIX(config)#
Identifying the CA
Use the following command to identify the name of a CA: ca identity name ip_address with
an optional parameter for the script location. For example, the location might be :/certsrv/
mscep/mscep.dll. Other commands will reference the name that is specified here, and this command says that the named device is a CA.
In addition to specifying the IP address, the Common Gateway Interface (CGI) script location and LDAP IP address may be added at the end of the command. Once a CA is defined, the
name cannot be changed without deleting the entire CA configuration. Here is an example:
PIX(config)# ca identity MyCA 10.31.12.250 :/certserv/mscep/mscep.dll
PIX(config)#
Configuring Additional CA Communication Properties
You may use the ca configure name type retry_period retry_count command to configure additional properties of the CA communication. The PIX Firewall can optionally contact
an RA instead of the usual CA. The name is the name of the CA identified with the ca identity
command and the type is either ca or ra. Optionally you can use the crloptional parameter.
For example, you might decide that the PIX Firewall will get certificates only from a CA or
if it can also get certificates from an RA. The retry period is used to determine how often the PIX
Firewall will retry if the CA does not respond, and the retry count specifies how many times it
retries before giving up. Here is an example of setting five retries 10 seconds apart:
PIX(config)# ca configure TestCA ca 10 5 crloptional
PIX(config)#
The crloptional parameter makes the Certificate Revocation List (CRL) optional. Each
time a new connection begins, the PIX Firewall attempts to download a new CRL. Ordinarily,
if the CRL is unavailable, the tunnel setup is denied. Using crloptional says to allow the connection even if the CRL is unavailable. This is a security risk because it is possible for someone
to use a hijacked certificate while a CA is experiencing a DoS attack, and the attempted connection would be allowed.
234
Chapter 6
VPNs and the PIX Firewall
Authenticating the CA
The ca authenticate name fingerprint command authenticates the CA based on the
method of authentication chosen by the CA administrator, either by an alphanumeric fingerprint or by a preshared password. The name used here is the same one used in the identity
command. Including the expected fingerprint allows the PIX Firewall to compare what is
received with what is expected. If the two do not match, the certificate is discarded. The fingerprint is something you obtain from the CA administrator. Here is an example:
PIX(config)# ca authenticate MyCA Sybex123
PIX(config)#
Enrolling the Firewall
Once you have authenticated to the CA, you have to actually request the certificate from the
CA using the ca enroll name password [serial] [ipaddress] command. The optional
parameters return the PIX Firewall serial number and IP address, respectively, in the certificate.
This sends a request with the Public Key Cryptography System (PKCS) 10. If everything is
okay, the PIX Firewall will get a PKCS 7 back with the appropriate certificates.
The CA name is straightforward, and the password is used for the challenge from the CA, if
it is required. A certificate on the PIX Firewall can include the serial number of the device and
the IP address of the terminating interface. These are just additional security measures to help
prevent someone from hijacking a certificate. The following is an example of enrolling the PIX
Firewall with a CA and using the additional parameters for higher security:
PIX(config)# ca enroll MyCA Sybex serial ipaddress
PIX(config)#
The ca enroll command is not entered into the configuration. If the PIX Firewall reboots after this command is issued but before certificates are received
and saved, you will need to reissue the request.
Downloading the CRL
The PIX Firewall will automatically download a CRL whenever it receives a certificate. If the
PIX Firewall is unable to download the latest CRL when it receives a certificate, it will reject the
certificate, just as if the certificate were found on the CRL. To prevent this from happening, use
the crloptional option with the ca configure command, as described earlier in this chapter
in the “Configuring Additional CA Communication Properties” section.
Saving the Configuration
Saving your configuration provides a backup in case the firewall needs to be reconfigured. Use
the write mem command to save everything that has been configured, with the exception of the
CA enrollment command. Any RSA keys that have been generated will be saved at the same
time, but in a different area of the flash.
Configuring IKE on a Firewall
235
Another command you can use is ca save all, which saves configuration details regarding
certificates. This command saves the RSA keys that were generated as well as the certificates
received from the CA.
Showing Certificate Information
You can view the firewall’s public key, certificates, and the CA’s identity and configuration. To
see the local PIX Firewall’s public key, use the show ca mypubkey rsa command, as follows:
PIX(config)# show ca mypubkey rsa
% Key pair was generated at: 11:00:21 Nov 25 2001
Key name: PIX.sybex.com
Usage: General Purpose Key
Key Data:
305c300d 06092a86 4886f70d
009956df 93f32f45 25d31b9d
162d77e2 b6eaba9e bad7684c
5f0beb99 69ec35ef 8acc5136
PIX(config)#
01010105
1961754b
6d1533ac
8ce3d5ac
00034b00
03d01f91
a7f13f7e
af020301
30480241
0b365a96
757dd91d
0001
To view the local PIX Firewall’s certificates, use the show ca certificate command:
PIX(config)# show ca certificate
CA Certificate
Status: Available
Certificate Serial Number:
6246f2a3a959a6ab47df0ec86729079b
Key Usage: Signature
CN = CA Server
OU = CASERVER
C = US
Validity Date:
start date: 11:40:56 Nov 24 2001
end
date: 11:49:17 Nov 24 2003
RA Signature Certificate
Status: Available
Certificate Serial Number: 6103a5c6000000000002
Key Usage: Signature
Chapter 6
236
VPNs and the PIX Firewall
CN = Sybex
O = Illustrated
C = US
Validity Date:
start date: 11:51:13 Nov 24 2001
end
date: 12:01:13 Nov 24 2002
RA KeyEncipher Certificate
Status: Available
Certificate Serial Number: 6103a6e0000000000003
Key Usage: Encryption
CN = Sybex
O = Illustrated
C = US
Validity Date:
start date: 11:51:13 Nov 24 2001
end
date: 12:01:13 Nov 24 2002
PIX(config)#
To see the CA identity, use the command show ca identity. To see the CA configuration,
use show ca configure. Here is an example of using both these commands:
PIX(config)# show ca identity
ca identity vpnca 172.31.1.50:/certsrv/mscep/mscep.dll
PIX(config)# show ca configure
ca configure vpnca ra 1 20 crloptional
PIX(config)#
Deleting CA-Related Items
You can use the following three commands to delete a firewall’s keys and certificates:
The no ca save all command This command erases the keys and certificates from flash.
The ca zeroize rsa command This command eliminates the RSA keys that have been created, but it does not remove the certificates that are based on those keys.
The no ca identity command This command, followed by the optional CA nickname,
eliminates everything associated with the CA, including the firewall’s ID certificate.
Configuring IPSec on a Firewall
237
Configuring IPSec on a Firewall
After configuring IKE and your authentication method, you are ready to build your IPSec tunnel
for the PIX Firewall. IPSec provides security for transmission of sensitive traffic over networks
such as the Internet. IPSec provides the following network security services:
Data confidentiality The IPSec sender can encrypt packets before transmitting them across a
network.
Data integrity The IPSec receiver can authenticate packets sent by the IPSec sender to ensure
that the data has not been altered during transmission.
Data origin authentication The IPSec receiver can authenticate the source of the IPSec packets
sent. This service depends on the data integrity service.
Anti-replay The IPSec receiver can detect and reject replayed packets.
IPSec tunnels are sets of SAs that are established between two IPSec peers. The security associations define which protocols and algorithms should be applied to sensitive packets and also
specify the keying material to be used by the two peers. Security associations are unidirectional
and are established per security protocol (AH or ESP).
On the PIX Firewall, the components for configuring IPSec are
Crypto ACLs
Transform sets
Tunnel lifetime
Crypto maps
Creating Crypto ACLs
Crypto ACLs are regular ACLs, but they are tied to a crypto map on the PIX Firewall. They are
attached to the tunnel to determine which traffic may cross the tunnel. Consider the example of
two firewalls connecting a tunnel across the Internet, shown in Figure 6.2. Both firewalls have
a symmetric ACL configuration. Source and destination information are flipped from one PIX
Firewall to the other. This is because when PIX1 sends a packet across the tunnel, it expects the
reply to come in via the tunnel. If the reply does not come through the tunnel, there is obviously
something wrong, and the packet should be dropped.
Remember that Network Address Translation (NAT) takes place before the PIX Firewall
compares the outgoing packet with the ACL. This means that the NAT address is the one that
needs to be used in the ACL. Also, remember that PIX Firewall ACLs are slightly different from
IOS ACLs. To specify a single IP address on the PIX Firewall, use a net mask value of
255.255.255.255 instead of 0.0.0.0.
238
Chapter 6
FIGURE 6.2
VPNs and the PIX Firewall
Symmetric ACLs
Site 1
Site 2
PIX1
Internet
PIX2
10.0.1.3
10.0.2.3
ethernet0
192.168.1.2
ethernet0
192.168.2.2
PIX1
PIX1# show static
static (inside,outside) 192.168.1.10 10.0.1.3 netmask
255.255.255.255 0 0
PIX1# show access-list
access-list 101 permit ip host 192.168.1.10 host 192.168.2.10
PIX2
PIX2# show static
static (inside,outside) 192.168.2.10 10.2.2.3 netmask
255.255.255.255 0 0
PIX2# show access-list
access-list 101 permit ip host 192.168.2.10 host 192.168.1.10
Creating and Configuring Transform Sets
To create the transform set for the PIX Firewall, use the crypto ipsec transform-set name
transform_1 transform_2 transform_3 command. Each transform set must have a name
and at least one transform associated with it. Table 6.1 lists the transforms available.
TABLE 6.1
Transforms for a PIX Firewall
AH Authentication
ESP Authentication
ESP Encryption
ah-md5-hmac
esp-md5-hmac
esp-3des
ah-sha-hmac
esp-sha-hmac
esp-des
esp-null
Configuring IPSec on a Firewall
239
An example of a configuring a transform set is as follows:
PIX(config)# crypto ipsec transform-set testset esp-des esp-md5-hmac
PIX(config)#
The transforms may be mentioned in any order when entering the command, but you can
have only one transform from each column. You should also know that esp-3des is available
only if you the 3DES license installed. With version 6.3 of the PIX Firewall operating system,
additional ESP encryption options include Advanced Encryption Standard (AES) with 128-,
192-, and 256-bit keys. AES will not be discussed in this book because it is not currently covered
on the exam, but we mention it for completeness.
Remember that transform sets between the peers must match for a tunnel to
become established.
A Transport mode tunnel will protect the data portion of the packet. A tunnel mode tunnel
will protect the entire packet. You might be asking yourself, why would you want a Transport
mode over Tunnel mode? When using Tunnel mode, the original IP address of the host is encapsulated and the traffic looks as if it’s coming from the PIX Firewall. When using Transport
mode, only the data portion of the packet is encrypted and the IP header is used from the original host so the traffic looks as if it’s coming from the original host and not the PIX Firewall.
If you are using RFC 1918 address space, then the default of Tunnel mode is the best method
to use. Figure 6.3 illustrates this concept.
FIGURE 6.3
Tunnel mode versus Transport mode
Internet
102.12.1.2
101.12.2.1
101.12.3.1
102.12.5.2
Tunnel Mode
Original Packet
Source Destination
102.12.1.2 102.12.5.2
Protected Packet
ESP/AH
Source Destination Header
Protected
101.12.2.1 101.12.3.1 Data 102.12.1.2 102.12.5.2
Original Packet
Protected Packet
Data
Transport Mode
Source Destination
102.12.1.2 102.12.5.2
Data
ESP/AH
Source Destination Header Protected
102.12.1.2 102.12.5.2 Data
Data
Data
240
Chapter 6
VPNs and the PIX Firewall
A Transport mode transform set can be used only with a dynamic crypto map; the PIX Firewall CLI will display an error if you attempt to tie a Transport mode transform set to a static
crypto map. To create a Transport mode tunnel, use the crypto ipsec transform-set name
mode transport command.
The Windows 2000–native L2TP/IPSec client uses Transport mode, so Transport mode must be selected on the transform set. For PIX Firewall 6.0, L2TP is
the only protocol that can use the Transport mode. All other types of packets
using Transport mode will be discarded by the PIX Firewall.
Setting the Tunnel Lifetime
The tunnel lifetime is a value that can be expressed in seconds or in blocks of data or both. PIX
Firewall software versions of at least 6.0 support using both of these methods to determine
when the tunnel drops. When one of these values is reached, the tunnel is deactivated.
Remember that tunnels will be renegotiated 30 seconds before they are scheduled to expire. However, this renegotiation does not apply if PFS is being used.
To configure the tunnel lifetime, use the crypto ipsec security-association lifetime
[seconds seconds | kilobytes kilobytes] command. The following is an example of setting the tunnel lifetime:
PIX(config)# crypto ipsec security-association lifetime seconds 1600
PIX(config)# crypto ipsec security-association lifetime kilobytes 50000
PIX(config)#
You can specify both values, which will expire the security association with whatever value
is reached first. You can also configure both values on the same command line as seen by the
following example:
PIX(config)# crypto ipsec security-association lifetime seconds 1600
➥kilobytes 50000
PIX(config)#
The default in time is 28,800 seconds; the default in data is 4,608,000KB. This method will
set the timeouts on a global basis. You can configure individual tunnels differently by modifying
the appropriate crypto map.
Configuring IPSec on a Firewall
241
Creating Crypto Maps
A crypto map ties all of the IPSec configuration information together. The command to create a crypto map is crypto map name sequence_number sa_type, with sa_type being
ipsec-manual or ipsec-isakmp. However, a crypto map is configured on the PIX Firewall
in a line-by-line format, as opposed to being placed into a Crypto Map Configuration mode
as with a Cisco IOS router. Remember that only one crypto map statement per interface is
allowed.
The following are the parameters that can be configured for each tunnel:
crypto map map-name seq-num ipsec-isakmp
crypto map map-name seq-num match address access-list-name
crypto map map-name seq-num set peer hostname | ip-address
crypto map map-name seq-num set transform-set transform➥name1 [transform-name2] [transform-name3]
crypto map map-name seq-num set pfs [group1 | group2]
crypto map map-name seq-num set security-association
➥lifetime seconds seconds | kilobytes kilobytes
To apply the crypto map to the appropriate interface, use the crypto map name interface
interface_name command.
A PIX Firewall must be using at least software version 5.1 to be able to terminate a VPN on any interface. With version 5.0 and earlier, a VPN may be terminated only on the outside interface.
If a tunnel arrives from the outside and it terminates at the PIX Firewall, it needs to terminate
at the outside interface. Likewise, a tunnel coming from a DMZ network will terminate at the
DMZ interface. A VPN tunnel may pass through the PIX Firewall, but if it terminates at the PIX
Firewall, it must do so at the first interface it hits. The following is an example of a crypto map
configuration:
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
crypto
crypto
crypto
crypto
map
map
map
map
TestVPN
TestVPN
TestVPN
TestVPN
10
10
10
10
ipsec-isakmp
set peer 172.16.114.1
set transform-set secureset
match address 101
242
Chapter 6
VPNs and the PIX Firewall
Using VPNs to Replace Expensive WAN Links
A company with an international frame-relay network is looking to cut costs. The frame-relay
network costs $8,000 per month for the four-node network. We will look at how they can use
their Internet connections at each location to implement a VPN so they can disconnect their
expensive frame-relay network. They already have PIX Firewalls installed at each site, and we
will leverage them for the VPN network.
The following shows the internal IP addresses and outside PIX Firewall IP addresses at each
location:
Headquarters
216.10.200.0/22
205.13.25.67
London
216.10.199.0/24
167.5.132.12
Munich
216.10.198.0/24
43.159.13.56
Tokyo
216.10.197.0/24
221.72.18.14
Management has dictated that the traffic must be encrypted using 3DES, but authentication
headers do not need to be used. We will use the 3DES encryption, SHA for the hash, preshared
key for authentication, and Diffie-Hellman Group 2 for the IKE tunnel negotiation.
We will configure only the headquarters and London PIX Firewalls in this scenario. The others
will look similar to the London router. The following are the steps used to set up the headquarters PIX Firewall:
HQ# config t
HQ(config)# access-list HQ_to_London permit 216.10.200.0 255.255.252.0
➥216.10.199.0 255.255.255.0
HQ(config)# access-list HQ_to_Munich permit 216.10.200.0 255.255.252.0
➥216.10.198.0 255.255.255.0
HQ(config)# access-list HQ_to_Tokyo permit 216.10.200.0 255.255.252.0
➥216.10.197.0 255.255.255.0
HQ(config)# isakmp enable outside
HQ(config)# isakmp policy 12 encryption 3des
HQ(config)# isakmp policy 12 hash sha
HQ(config)# isakmp policy 12 authentication pre-share
HQ(config)# isakmp policy 12 group 2
HQ(config)# sysopt connection permit-ipsec
HQ(config)# isakmp identity address
HQ(config)# isakmp key $yB3xc1$C0c3Rt1F1cAt10N$ address 167.5.132.12
Configuring IPSec on a Firewall
HQ(config)# isakmp key $yB3xc1$C0c3Rt1F1cAt10N$ address 43.159.13.56
HQ(config)# isakmp key $yB3xc1$C0c3Rt1F1cAt10N$ address 221.72.18.14
HQ(config)# crypto ipsec transform-set strong_enc esp-3des esp-sha-hmac
HQ(config)# crypto map Corp_VPN 10 ipsec-isakmp
HQ(config)# crypto map Corp_VPN 10 match address HQ_to_London
HQ(config)# crypto map Corp_VPN 10 set peer 167.5.132.12
HQ(config)# crypto map Corp_VPN 10 set transform-set strong_enc
HQ(config)# crypto map Corp_VPN 20 ipsec-isakmp
HQ(config)# crypto map Corp_VPN 20 match address HQ_to_Munich
HQ(config)# crypto map Corp_VPN 20 set peer 43.159.13.56
HQ(config)# crypto map Corp_VPN 20 set transform-set strong_enc
HQ(config)# crypto map Corp_VPN 30 ipsec-isakmp
HQ(config)# crypto map Corp_VPN 30 match address HQ_to_Tokyo
HQ(config)# crypto map Corp_VPN 30 set peer 221.72.18.14
HQ(config)# crypto map Corp_VPN 30 set transform-set strong_enc
HQ(config)# crypto map Corp_VPN interface outside
HQ(config)# exit
HQ#
London# config t
London(config)# access-list London_to_HQ permit 216.10.199.0 255.255.255.0
➥216.10.200.0 255.255.252.0
London(config)# access-list London_to_Munich permit 216.10.199.0 255.255.255.0
➥216.10.198.0 255.255.255.0
London(config)# access-list London_to_Tokyo permit 216.10.199.0 255.255.255.0
➥216.10.197.0 255.255.255.0
London(config)# isakmp enable outside
London(config)# isakmp policy 12 encryption 3des
London(config)# isakmp policy 12 hash sha
London(config)# isakmp policy 12 authentication pre-share
London(config)# isakmp policy 12 group 2
London(config)# sysopt connection permit-ipsec
London(config)# isakmp identity address
London(config)# isakmp key $yB3xc1$C0c3Rt1F1cAt10N$ address 205.13.25.67
London(config)# isakmp key $yB3xc1$C0c3Rt1F1cAt10N$ address 43.159.13.56
London(config)# isakmp key $yB3xc1$C0c3Rt1F1cAt10N$ address 221.72.18.14
London(config)# crypto ipsec transform-set strong_enc esp-3des esp-sha-hmac
London(config)# crypto map Corp_VPN 10 ipsec-isakmp
London(config)# crypto map Corp_VPN 10 match address London_to_HQ
London(config)# crypto map Corp_VPN 10 set peer 205.13.25.67
243
244
Chapter 6
VPNs and the PIX Firewall
London(config)# crypto map Corp_VPN 10 set transform-set strong_enc
London(config)# crypto map Corp_VPN 10 ipsec-isakmp
London(config)# crypto map Corp_VPN 10 match address London_to_Munich
London(config)# crypto map Corp_VPN 10 set peer 43.159.13.56
London(config)# crypto map Corp_VPN 10 set transform-set strong_enc
London(config)# crypto map Corp_VPN 10 ipsec-isakmp
London(config)# crypto map Corp_VPN 10 match address London_to_Tokyo
London(config)# crypto map Corp_VPN 10 set peer 221.72.18.14
London(config)# crypto map Corp_VPN 10 set transform-set strong_enc
London(config)# crypto map Corp_VPN interface outside
London(config)# exit
London#
Verifying and Troubleshooting
IPSec Configuration on a Firewall
There are a number of commands that can be used to verify that the PIX Firewall VPN tunnels
are working properly, check the configuration, and troubleshoot it if necessary. In the following
sections, we look at these in depth.
Viewing Configuration Information
You can view information about IKE policies, crypto ACLs, transform sets, crypto maps, tunnel
lifetimes, and SAs. Being able to verify the configuration information is very important when
troubleshooting problems. You will be able to ensure the configuration is correct and all values
are those that are expected. We will look at how to do this for each in the following sections.
Viewing IKE Policies
The show isakmp policy command shows which IKE policies are configured on the PIX Firewall. The following shows the output from this command:
PIX# show isakmp policy
Protection suite of priority 10
encryption algorithm:
DES - Data Encryption
Standard (56 bit keys).
hash algorithm:
Message Digest 5
authentication method: Pre-Shared Key
Diffie-Hellman group:
#1 (768 bit)
Verifying and Troubleshooting IPSec Configuration on a Firewall
245
lifetime:
86400 seconds, no volume limit
Default protection suite
encryption algorithm:
DES - Data Encryption
Standard (56 bit keys).
hash algorithm:
Secure Hash Standard
authentication method: Rivest-Shamir-Adleman Signature
Diffie-Hellman group:
#1 (768 bit)
lifetime:
86400 seconds, no volume limit
PIX#
Viewing ACLs, Transforms, and Tunnel Lifetimes
To view the contents of an ACL, use the command show access-list [name]. If you specify
an ACL name, you will see the requested list. If you enter just show access-list, you will see
all access lists.
The show crypto ipsec transform-set [name] command displays the configured transform sets. As with the show access-list command, you can specify a particular transform set
to view by entering its name, or view all transform sets like this:
PIX(config)# show crypto ipsec transform-set
Transform set mine: { esp-des
will negotiate = { Tunnel,
}
},
PIX(config)#
To view a summary of the tunnel configuration, issue the show crypto map [interface
interface_name | tag map_name] command. If you reference an interface with this command, it displays only the tunnels that terminate at the specified interface. Using the name of the
crypto map will display only the requested map. If you do not specify an interface or crypto
name, the command displays all crypto maps. Here is an example:
PIX(config)# show crypto map
Crypto Map: "peer3" interfaces: { outside }
Crypto Map "peer3" 10 ipsec-isakmp
access-list 101 permit ip host 192.168.6.10 host
192.168.3.10 (hitcnt=0)
Current peer: 0.0.0.0
Security association lifetime: 4608000
kilobytes/28800 seconds
246
Chapter 6
VPNs and the PIX Firewall
PFS (Y/N): N
Transform sets={ mine, }
PIX(config)#
If you would like to see the current settings for the global tunnel lifetimes, use the show
crypto ipsec security-association lifetime command. It is important to remember
that individual tunnels can have these values overridden by setting the tunnel lifetime in the
crypto map. The following is an example of using this command:
PIX(config)# show crypto ipsec security-association lifetime
Security-association lifetime: 4608000 kilobytes/28800 seconds
PIX(config)#
Viewing SAs
The show crypto ipsec sa command shows the status of the individual SAs that make up a
VPN tunnel. This is a useful command if packets are not making it across the tunnel but the tunnel is up. It easily detects when a packet should be encrypted but is being dropped because it is
not encrypted. Examining the pkts information displays quite a bit. Here is an example of the
output from this command:
PIX(config)# show crypto ipsec sa
interface: outside
Crypto map tag: peer1, local addr. outside
local ident (addr/mask/prot/port):
(192.168.2.10/255.255.255.255/0/0)
remote ident (addr/mask/prot/port):
(192.168.1.10/255.255.255.255/0/0)
current_peer: 192.168.1.2
PERMIT, flags={origin_is_acl,}
#pkts encaps: 91, #pkts encrypt: 91, #pkts digest 0
#pkts decaps: 77, #pkts decrypt: 77, #pkts verify 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0, #pkts
decompress failed: 0
#send errors 55, #recv errors 0
local crypto endpt.: outside, remote crypto endpt.:
192.168.1.2
path mtu 1514, ipsec overhead 44, media mtu 1514
current outbound spi: 2efc960f
Verifying and Troubleshooting IPSec Configuration on a Firewall
247
inbound esp sas:
spi: 0xe51b943c(3843789884)
transform: esp-des ,
in use settings ={Tunnel, }
slot: 0, conn id: 4, crypto map: peer1
sa timing: remaining key lifetime (k/sec):
(4607998/4514)
IV size: 8 bytes
replay detection support: N
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x2efc960f(788305423)
transform: esp-des ,
in use settings ={Tunnel, }
slot: 0, conn id: 3, crypto map: peer1
sa timing: remaining key lifetime (k/sec):
(4607995/4505)
IV size: 8 bytes
replay detection support: N
outbound ah sas:
outbound pcp sas:
PIX(config)#
This example shows the crypto map information applied to the SA and what device this PIX
Firewall is peering with to create the tunnel. Further examination shows that the tunnel is made
up of ESP, and that AH is not in use. It also shows the reason why this tunnel is up: It was activated by interesting traffic matching an ACL entry.
Understanding Error Messages
There are a number of status messages that IKE and IPSec can generate. Cisco does not provide
a PIX Firewall–specific list of the messages, as it does for the IOS router, but the messages are
usually self-explanatory.
One status message that it is always nice to see and you might need to know for the test is
return status is IKMP_NO_ERROR. This means that ISAKMP managed to complete everything it needed to and the tunnel has come up.
248
Chapter 6
VPNs and the PIX Firewall
Debugging
The commands used to troubleshoot a PIX Firewall tunnel are the debug crypto commands,
beginning with debug crypto isakmp, then debug crypto ipsec.
For information about all of the debug commands available in PIX Firewall 6.2,
refer to URLhttp://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/
pix_62/cmdref/df.htm#1059143.
Understanding Remote Access VPN
For a remote computer to connect to the corporate network over the Internet, you must configure the PIX Firewall to accept these remote access VPN connections. This procedure involves
more steps than setting up just a site-to-site VPN. You need to worry about authenticating the
remote user and configuring the remote VPN client to appear as a client inside your network.
We will talk about how to configure the PIX Firewall for a remote access VPN. Then we will
use that information in the section, “Installing and Configuring the Cisco VPN Client,” to discuss how to configure the VPN clients to access the inside network.
There are additional steps for a remote access VPN, but the concept is still the same as a siteto-site VPN. We will step through the procedure to set up the PIX Firewall, but let’s first go over
what makes the remote access VPN different.
Extended Authentication (Xauth)
The optional Xauth feature allows the PIX Firewall to authenticate a VPN user using a TACACS+
or RADIUS server. Xauth is negotiated between IKE phases 1 and 2. IKE phase 1 is used for device
authentication, and phase 2 is used for IPSec SA negotiation. If the Xauth fails, the IPSec security
association will not be established, and the PIX Firewall will delete the IKE SA.
To enable the optional Xauth feature, use the command
crypto map map-name client authentication aaa-group
The aaa-group must be previously configured using the aaa-server command.
Remember, the PIX Firewall can support only one crypto map command per interface. What
happens if you are also terminating a site-to-site VPN on that same interface? You don’t want to
add users to your TACACS+ or RADIUS server for the site-to-site VPNs. So how do you configure
the PIX Firewall not to authenticate those connections? If you are using a preshared key on your
site-to-site VPN, then you need to add the no-xauth parameter to the isakmp key command. If
you are using RSA signatures, then you need to add the no-xauth parameter to the isakmp peer
fqdn fully_qualified_domain_name command. For example, the following would be the
Understanding Remote Access VPN
249
command to not authenticate the site-to-site VPN peer at IP address 10.19.1.5 and one using the
RSA signature at address vpn1.Sybex.com:
PIX(config)# isakmp key Sybex address 10.12.1.5 no-xauth
PIX(config)# isakmp peer fqdn vpn1.Sybex.com no-xauth
PIX(config)#
IKE Mode Config for Dynamic Addressing
The IKE Mode Config feature can be used to assign IP addresses dynamically to VPN clients. This
feature allows the PIX Firewall to download an IP address, and optionally, other network level
configuration parameters to a VPN client as part of the IKE negotiation process. This IP address
is used as an “inner” IP address encapsulated under IPSec, which provides a known IP address for
a VPN client that can be matched against the IPSec security policy.
There are two ways that the IKE Mode Config can be initiated. The first is where the PIX
Firewall initiates the Configuration mode with the client. The client then responds and the IKE
modifies the sender’s identity, the message is processed, and the client receives a response. The
second method is where the client initiates the Configuration mode with the PIX Firewall. The
PIX Firewall responds with an IP address it has allocated to the client.
So how does the PIX Firewall know which IP address to assign to which VPN client? You must
first configure a pool of addresses using the ip local pool name start_pool_ip-end_pool_ip
command. Next you need to link the pool you created to the IKE configuration. This is done with
the isakmp client configuration address-pool local name [interface] command. The
name is the name of the pool you created, and the interface is, optionally, the name of the interface
on which to enable ISAKMP negotiation. Finally you need to make sure that the crypto map you
have assigned to the interface will give out these addresses to the VPN users. This is done using the
crypto map sequence-number client-configuration address [initiate | respond]
command. The initiate parameter indicates that the PIX Firewall will attempt to set IP addresses
for each peer. The respond parameter indicates that the PIX Firewall will accept requests for IP
addresses from any requesting peer.
The following is an example of using these commands to set up IKE Mode Config to assign
dynamic addresses:
PIX(config)# ip local pool vpn-pool 10.192.12.100-10.192.12.199
PIX(config)# isakmp client configuration address-pool local vpn-pool outside
PIX(config)# crypto map vpnmap client configuration address initiate
PIX(config)#
Again, if you are using the same interface for site-to-site and remote access VPN connections,
you need to let the PIX Firewall know that you don’t want to assign an IP address to the siteto-site remote peer. As with the Xauth exception command, you can do this with the noconfig-mode parameter added to either the isakmp key or isakmp peer fqdn fully_
qualified_domain_name commands. This parameter can be combined with the no-xauth
250
Chapter 6
VPNs and the PIX Firewall
parameter to configure the PIX Firewall to not authenticate the site-to-site VPN peer or assign
an IP address to the peer.
The following is an example of using both commands for a site-to-site VPN peer using a preshared key at IP address 10.19.1.5:
PIX(config)# isakmp key Sybex address 10.19.1.5 no-xauth no-config-mode
PIX(config)#
Pushing Additional Attributes to the VPN Client
With the Cisco VPN 3000 Client version 2.5 and higher and the Cisco unified VPN Client, they
have been extended so you can accept additional attributes for the client. The additional attributes
are DNS, WINS, default domain, and Split Tunnel mode. To configure the PIX Firewall to support these extended attributes, you need to create a VPN group. This is done using the vpngroup
command. This command has many parameters that are used to configure the Cisco VPN 3000
Client policy:
address-pool
dns-server
wins-server
default-domain
split-tunnel settings
idle-time
The address-pool is the only required parameter and is used to tie a local address pool to
the VPN group. The dns-server and wins-server parameters are used to assign either one or
two servers to their respective services. The default-domain command configures the default
domain name used by the Cisco VPN 3000 Client. The split-tunnel parameter uses an access
list to configure which IP addresses will be IPSec-protected from the client and which will be
passed through unprotected. The idle-time parameter controls how long a client can be idle
before disconnection.
The following is an example of using the vpngroup command with its parameters to set up
a VPN group named Sybex:
PIX(config)# access-list 100 ip 10.192.12.0 255.255.255.0 10.192.13.0
➥255.255.255.0
PIX(config)# ip pool local pool1 10.192.12.100-10.192.12.199
PIX(config)# vpngroup Sybex address-pool pool1
PIX(config)# vpngroup Sybex dns-server 10.192.12.250
PIX(config)# vpngroup Sybex wins-server 10.192.12.251 10.192.12.252
PIX(config)# vpngroup Sybex default-domain sybex.com
PIX(config)# vpngroup Sybex split-tunnel 100
PIX(cofnig)# vpngroup Sybex idle-time 3600
PIX(config)#
Understanding Remote Access VPN
251
Common Commands
Now let’s discuss what other commands are needed to get a remote access VPN up and running.
As with a site-to-site VPN, we need to configure the IKE policy, peer IP address, and IPSec transform sets. You use the same commands to do this—with some changes. Let’s talk about each
of these steps.
To create an IKE policy for a remote access VPN, you use the isakmp policy command. Use
the encr, hash, and authentication parameters to set the correct policy. If you are using the
Cisco VPN 3000 Client 3.0 or above, make sure you include the command isakmp policy
number group 2 because 3.0 and higher use Diffie-Hellman group 2.
The following is an example of an IKE policy that will work with a Cisco VPN 3000 client
3.0 or higher:
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
isakmp
isakmp
isakmp
isakmp
policy
policy
policy
policy
13
13
13
13
encr des
hash md5
authentication pre-share
group 2
If you are using digital certificates and not a preshared key, there are additional commands
you need to use. Make sure you have a correct domain name and hostname defined before creating a digital certificate. You need to use the ca generate rsa key key_size command. The
key size is the size the key needs to be to generate the needed RSA key. Then you need to identify
the CA and the communication parameters. Next you authenticate and enroll to the CA before
continuing. After you have verified your CA configuration, you need to change the IKE authentication policy to use the RSA signature.
The following is an example of the IKE policy when using a CA for peer authentication:
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
PIX(config)#
domain-name Sybex.com
ca generate rsa key 512
ca identity TestCA 10.192.12.254 10.192.12.254
ca configure TestCA ca 1 20 crloptional
ca authenticate TestCA
ca enroll TestCA Sybex
isakmp policy 14 encr des
isakmp policy 14 hash sha
isakmp policy 14 authentication rsa-sig
Now you need to specify the password and IP address of the VPN peer. The password is easy,
but you don’t always know what the IP address is going to be for each remote access VPN client.
It seems that remote users are never in the same place twice, so they are always going to use a
different IP address. We do this with a wild card as the IP address in the peer command.
252
Chapter 6
VPNs and the PIX Firewall
The following is an example of the command to use for remote access VPN clients using the
preshared key Sybex:
PIX(config)# isakmp key Sybex address 0.0.0.0 netmask 0.0.0.0
PIX(config)#
You need to configure the PIX Firewall to use an encryption and authentication scheme for
these VPN clients. You do this as you did with the site-to-site VPN: by using the crypto ipsec
transform-set command.
The following is an example of using this command to configure a good, strong encryption
and authentication transform set:
PIX(config)# ipsec transform-set strong-scheme esp-3des esp-sha-hmac
PIX(config)#
Finally, you need to tie these all together and add them to an interface. Because we don’t
know what the peer IP address is going to be beforehand, we need to create a dynamic crypto
map to associate the transform set. This will act as a template when a VPN client connects to
the PIX Firewall. The crypto dynamic-map command is used to set up this dynamic template.
Next you need to tie this dynamic map to a regular crypto map, which can be linked to the
inbound VPN interface. This is done with the dynamic parameter of the crypto map command.
The following is an example of using these commands:
PIX(config)# crypto dynamic-map RemClients 3 set transform-set strong-scheme
PIX(config)# crypto map VPN-Map 20 ipsec-isakmp dynamic RemClients
PIX(config)# crypto map VPN-Map interface outside
PIX(config)#
Let’s see what the PIX Firewall configuration might look like when it supports remote access
VPN clients. The following is an example of a PIX Firewall configuration (the irrelevant portions have been removed)
PIX# wr t
Building configuration...
: Saved
:
PIX Version 6.2(2)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
hostname PIX
access-list 100 permit ip 10.192.12.0 255.255.255.0 10.192.13.0 255.255.255.0
interface ethernet0 auto
interface ethernet1 auto
ip address outside 175.13.12.1 255.255.255.248
Installing and Configuring the Cisco VPN Client
253
ip address inside 10.192.12.1 255.255.255.0
ip local pool pool1 10.192.12.100-10.192.12.199
nat (inside) 0 access-list 100
aaa-server RADIUS protocol radius
aaa-server RADIUS (inside) host 10.192.12.250 abcdef timeout 10
sysopt connection permit-ipsec
crypto ipsec transform-set good-scheme esp-des esp-sha-hmac
crypto dynamic-map RemClients 3 set transform-set good-scheme
crypto map VPN-Map 20 ipsec-isakmp dynamic RemClients
crypto map VPN-Map interface outside
isakmp enable outside
isakmp key ******** address 0.0.0.0 netmask 0.0.0.0
isakmp policy 13 authentication pre-share
isakmp policy 13 encryption des
isakmp policy 13 hash md5
isakmp policy 13 group 2
isakmp policy 13 lifetime 86400
vpngroup sybex address-pool pool1
vpngroup sybex dns-server 10.192.12.240 10.192.12.245
vpngroup sybex wins-server 10.192.12.241 10.192.12.246
vpngroup sybex default-domain sybex.com
vpngroup sybex split-tunnel 100
vpngroup sybex idle-time 3600
: end
[OK]
PIX#
In the next section, we will talk about how to set up the VPN client to connect to the PIX
Firewall we just configured.
Installing and Configuring the Cisco
VPN Client
The VPN client is simple to install and operate and enables a user to establish secure end-to-end
encrypted tunnels to a VPN server. The Cisco VPN client provides support for the following
operating systems:
Windows 95 (OSR2+)
Windows 98
254
Chapter 6
VPNs and the PIX Firewall
Windows ME
Windows NT 4.0
Windows 2000
Windows XP
Linux (using Intel processors)
Solaris (UltraSparc 32- and 64-bit processors)
Mac OS X 10.1 and 10.2
The Cisco VPN client works with the following Cisco platforms:
Cisco VPN 3000 Series Concentrator 3.0 and later
Cisco IOS 12.2 T and later
Cisco PIX Firewall 6.0 and later
After you have installed the VPN Client, you need to configure it to access the PIX Firewall.
If you need help installing the Cisco VPN 3000 Client software, refer to the documentation
on line at http://www.cisco.com/univercd/cc/td/doc/product/vpn/index.htm.
If you are using a preshared key for authentication, follow these steps to configure the client
to interoperate with the PIX Firewall:
1.
Click Start Programs Cisco Systems VPN 3000 Client VPN Dialer.
2.
At the VPN Client main dialog box, click New.
3.
Enter a name for this connection that is not already being used. Click Next.
4.
Enter the hostname or IP address of the remote PIX Firewall. Click Next.
5.
Click Group Access Information.
6.
Enter the name of the VPN group and the password. Click Next.
7.
To complete the configuration, click Finish.
For the Cisco VPN 3000 Client to gain VPN access to the PIX Firewall using a digital certificate, you must first obtain the certificate from a CA server.
We will not cover how you obtain a digital certificate for the client, but you can
refer to the chapter “Obtaining a Certificate” in the Cisco VPN 3000 Client User
Guide on line at the URL above.
Only after this is done can you follow the steps below to create a VPN client connection using
a digital certificate:
1.
Click Start Programs Cisco Systems VPN 3000 Client VPN Dialer.
2.
At the VPN Client main dialog, click New.
3.
Enter a name for this connection not already being used. Click Next.
4.
Enter the hostname or IP address of the remote PIX Firewall. Click Next.
Installing and Configuring the Cisco VPN Client
5.
Click Certificate.
6.
Click the name of the certificate you are using. Click Next.
7.
To complete the configuration, click Finish.
255
You might be asking, where is the VPN group name configured in the client? The VPN group
name is cleverly stored in the digital certificate as the Organization Unit (OU) field. So if you
change the name of the VPN group, you will need to obtain a new digital certificate with the correct VPN group stored in the OU field.
Deploying the VPN Client
The VPN client can be preconfigured for mass deployments and the initial login requires very
little user intervention. The VPN client access policies and configurations are downloaded from
the central gateway and pushed to the client when a connection is established, which allows for
simple deployment and management as well as a high degree of scalability.
The group of configuration parameters used for remote users to connect to a VPN server is
called a profile. There are two varieties of profiles: global and individual. The global profile (vpnclient.ini) is a file that sets rules for all remote users, and it contains parameters for the VPN client
as a whole. The individual profiles are files that contain the parameter settings for each connection
entry and are unique to that entry. The individual profiles files have a .pcf extension.
Profiles get created in two ways:
When an administrator or a remote user, using the Windows or Macintosh client, creates
connection entries using the VPN Client GUI
When you create profiles using a text editor
When using the VPN client GUI, the user is also creating a file that can be viewed and edited
through a text editor. You can start with a profile file generated through the GUI and edit it.
This approach lets you control some parameters that are not available in the VPN Client GUI
application, for example, auto-initiation or dial-up wait for third-party dialers.
The default location for all profile files for the various operating systems is
Windows platforms: C:\Program Files\Cisco Systems\VPN Client\Profiles
Linux, Solaris, and Mac OS X platforms: /etc/CiscoSystemsVPNClient/Profiles/
We will explain how to create and edit the vpnclient.ini and individual profile files. Both files
follow the normal Windows.ini file format convention. The following is a list of these conventions:
Use a semicolon (;) to begin a comment.
Section names are specified within brackets [section name], and they are not case sensitive.
Use key names to set values for parameters (i.e., keyword = value). For keywords without
values, or unspecified keywords, the VPN client will use the defaults. Keywords can be in
any order and are not case sensitive, although using lower and uppercase makes them more
readable.
To make an individual parameter read-only, so the client user cannot change it within the VPN
client applications, precede the parameter name with an exclamation mark (!). This controls what
256
Chapter 6
VPNs and the PIX Firewall
the user can or cannot do within the VPN client applications only. You cannot prevent someone
from editing the global profile (vpnclient.ini) or individual profile (.pcf) files and remove the
read-only designator.
Features Controlled by the Global Profile
The global profile file (vpnclient.ini) controls the following global features on all VPN client
platforms:
Start before logon
Automatic disconnect upon logoff
Control of logging services by class
Certificate enrollment
Identity of a proxy server for routing HTTP traffic
Identity of an application to launch upon connect
Missing-group warning message
Logging levels for log classes
RADIUS SDI extended authentication behavior
GUI parameters—appearance and behavior of GUI applications
The vpnclient.ini file controls the following additional features when using a Windows
platform:
Location of the Entrust.ini file
List of GINAs that are not compatible with the VPN Client
Auto-initiation
Setting of the Stateful Firewall option
Microsoft Outlook–to–Microsoft Exchange polling
The method to use in adding suffixes to domain names on Windows 2000 and Windows
XP platforms
When working with a third-party dialer, time to wait after receiving an IP address before
initiating an IKE tunnel
Network proxy server for routing HTTP traffic
Application launching
DNS suffixes
Force Network Login, which forces a user on Windows NT, Windows 2000, or Windows
XP to log out and log back in to the network without using cached credentials
Profiles for the VPN Client are interchangeable between platforms, while keywords that are specific to the Windows platform are ignored by other platforms.
Installing and Configuring the Cisco VPN Client
257
The following is a sample vpnclient.ini file, which shows what you might see if you open
it with a text editor:
[main]
IncompatibleGinas=PALGina.dll,theirgina.dll
RunAtLogon=0
EnableLog=1
DialerDisconnect=1
AutoInitiationEnable=1
AutoInitiationRetryInterval=1
AutoInitiationList=techsupport,admin
[techsupport]
Network=172.17.0.0
Mask=255.255.0.0
ConnectionEntry=ITsupport
[admin]
Network=172.18.0.0
Mask=255.255.0.0
ConnectionEntry=Administration
[LOG.IKE]
LogLevel=1
[LOG.CM]
LogLevel=1
[LOG.PPP]
LogLevel=2
[LOG.DIALER]
LogLevel=2
[LOG.CVPND]
LogLevel=1
[LOG.CERT]
LogLevel=0
[LOG.IPSEC]
LogLevel=3
[LOG.FIREWALL]
LogLevel=1
[LOG.CLI]
LogLevel=1
[CertEnrollment]
SubjectName=Wade Edwards
Company=Sybex Corp
Department=Internal Relations
258
Chapter 6
VPNs and the PIX Firewall
State=Utah
Country=US
[email protected]
CADomainName=SybexCerts
CAHostAddress=10.11.12.13
CACertificate=CAU
[Application Launcher]
Enable=1
Command=c:\apps\apname.exe
[ForceNetLogin]
Force=1
Wait=10
DefaultMsg=You will be logged off in 10 seconds
Separator=**************************************
[GUI]
WindowWidth=578
WindowHeight=367
WindowX=324
WindowY=112
VisibleTab=0
ConnectionAttribute=0
AdvancedView=1
DefaultConnectionEntry=ACME
MinimizeOnConnect=1
UseWindowSettings=1
ShowToolTips=1
ShowConnectHistory=1
The VPN client uses parameters that must be uniquely configured for each remote user.
These parameters together make up a user connection profile, which is contained in a profile
configuration file (.pcf file) in the VPN client user’s local file system.
Some of these parameters include
Remote server address
IPSec group name and password
Use of a log file
Use of backup servers
Automatic Internet connection via dial-up networking
Each connection entry has its own .pcf file. For example, if you have three connection
entries, named Sybex Server, Documentation, and Engineering, the Profiles directory shows the
list of all these .pcf files.
Installing and Configuring the Cisco VPN Client
259
Features Controlled by Connection Profiles
A connection profile (.pcf file) controls the following features on all platforms:
Description of the connection profile
Remote server address
Authentication type
Name of IPSec group containing the remote user
Group password
Connecting to the Internet via dial-up networking
Name of remote user
Remote user’s password
Backup servers
Split DNS settings
Type of dial-up networking connection
Transparent tunneling
TCP tunneling port
Allowing of local LAN access
Enabling of IKE and ESP keepalives
Setting peer response timeout
Certificate parameters for a certificate connection
Setting certificate chain
Diffie-Hellman group used
Verifying the domain name (DN) of a peer certificate
RADIUS SDI extended authentication setting
Use of SDI hardware token setting
Use of legacy IKE port setting
A.pcf file controls the following additional features when using a Windows platform:
Dial-up networking phone-book entry for Microsoft
Command string for connecting through an ISP
NT domain
Logging on to Microsoft Network and credentials
Changing the default IKE port from 500/4500 (must be explicitly added)
Enabling Force Network Login, which forces a user on Windows NT, Windows 2000, or
Windows XP to log out and then log back in to the network without using cached credentials.
260
Chapter 6
VPNs and the PIX Firewall
Here is a sample of a .pcf file:
[main]
Description=connection to Sybex server
Host=10.20.79.35
AuthType=1
GroupName=sybexusers
GroupPwd=
enc_GroupPwd=158E47893BDCD398BF863675204775622C494B39523E5CB65434D3C851
EnableISPConnect=0
ISPConnectType=0
ISPConnect=
ISPCommand=
Username=Wade
SaveUserPassword=0
UserPassword=
enc_UserPassword=
NTDomain=
EnableBackup=1
BackupServer=Doc1, Doc2, Doc3, Doc4
EnableMSLogon=0
MSLogonType=0
EnableNat=1
EnableLocalLAN=0
TunnelingMode=0
TCPTunnelingPort=10000
CertStore=0
CertName=
CertPath=
CertSubjectName
SendCertChain=0
VerifyCertDN=CN=”ID Cert”,OU*”Cisco”,ISSUER-CN!=”Entrust”,ISSURE-OU!*”Sybex”
DHGroup=2
PeerTimeOut=90
ForceNetLogin=1
You can configure the VPN client for remote users by creating a profile configuration file for
each connection entry and distribute the .pcf files with the VPN client software. These configuration files can include all or some of the parameters needed. Users must configure those settings that are not already configured.
You can also distribute the VPN Client to users without a configuration file and let them configure it on their own. In this case, when they complete their configuration using the VPN client GUI,
they are in effect creating a .pcf file for each connection entry, which can be edited and shared.
Using PDM to Create VPNs
261
To protect system security you should not include key security parameters such
as the IPSec group password, authentication username, or authentication password in .pcf files for remote users. You will then supply users with the information they need to configure the VPN client for their individual installation.
Using PDM to Create VPNs
If you remember in Chapter 5, “Firewall Failover and PDM,” when we talked about the PDM
but didn’t show you how to create VPNs using the PDM. In this section, we will show you how
to use the PDM to create site-to-site and remote access VPNs.
Once you have PDM up and running on your workstation, you need to navigate to the VPN
tab, as seen in Figure 6.4.
Remember that if you are using the Firewall Services Module (FWSM), the VPN
tab will not work because the FWSM does not support VPN services.
FIGURE 6.4
The PDM VPN tab
262
Chapter 6
VPNs and the PIX Firewall
From the PDM VPN tab, you can choose to configure IPSec, IKE, remote access, and global
VPN parameters on the PIX Firewall. Under the IPSec section, you can configure IPSec rules,
tunnel policies, and transform sets. Under the IKE section, the options are policies, Xauth/
Mode Config, preshared keys, and certificate parameters. When configuring a remote access
VPN, this section of the GUI allows you to configure the Cisco VPN and L2TP/PPTP client
plus the IP pools used for these clients. Finally, the global VPN parameters available are to
enable the PIX Firewall to bypass the access check for IPSec, L2TP, and PPTP traffic plus configuring the PIX Firewall to act as an Easy VPN Remote.
You can set up all of these parameters through the GUI, but to make it easier, the PDM has a
wizard to step you through the configuration of site-to-site and remote access VPNs. To access the
VPN Wizard, select Wizards VPN Wizard from the drop-down menu, as seen in Figure 6.5.
FIGURE 6.5
Selecting the VPN Wizard
Choosing the VPN Wizard will open another window, which will step you through the configuration of either a site-to-site or remote access VPN. In the following sections, you will see
how to use the wizard to set up a site-to-site VPN and a remote access VPN.
Using PDM to Create VPNs
263
Setting Up a Site-to-Site VPN
Once you have activated the VPN Wizard, follow these steps to set up a site-to-site VPN:
1.
On the VPN Wizard screen, shown in Figure 6.6, choose the site-to-site VPN option and
select the outside interface to terminate the VPN to. Then click the Next _button.
FIGURE 6.6
Selecting site-to-site VPN
2.
Since this is a site-to-site VPN, we must specify a peer, or remote, IP address to terminate
the other end of the VPN to. Select the method of authentication to use before negotiating
IPSec. The choices on the Remote Site Peer screen are preshared key or certificate. As you
can see from Figure 6.7, when you choose the preshared key authentication method, you
must enter the key to be used for authentication. If you choose to use a certificate, you must
choose between using the IP address or a fully qualified domain name (FQDN) or DNS
name for the peer. Click the Next button.
3.
On the IKE Policy screen, create the IKE policy to use between the peers (see Figure 6.8).
Here, you must choose the encryption and authentication methods in addition to which
DH group to use. The authentication here is used to authenticate the IKE tunnel traffic and
not the remote peer, like the previous screen setup. The options for encryption are DES and
3DES. The authentication scheme can be either SHA or MD5 and the DH group options
are Group 1 or 2. Click the Next button.
264
Chapter 6
VPNs and the PIX Firewall
FIGURE 6.7
Choosing a remote site peer
FIGURE 6.8
Specifying an IKE policy
Using PDM to Create VPNs
265
4.
On Transform Set screen, create the transform set used by IPSec (see Figure 6.9). As on the
previous screen, the IPSec transforms options are the same for encryption and authentication. The IKE policy (from Figure 6.8) and the IPSec transform set encryption and authentication options can be different. Click Next.
5.
On the IPSec Traffic Selector screens specify which source traffic on the local site is going
to be protected by IPSec and which source traffic is not going to be protected (see Figure
6.10). In this example, you can see that we’ve selected to use an IP address range to protect
with IPSec, and this happens to be the range used by the inside interface of the PIX Firewall.
We could have also chosen to use the name of a group of hosts or networks that have been
previously configured on the PIX Firewall through the PDM. You must select the range you
have entered by pressing the right arrow button to make it one of your selected networks.
Click the Next button.
6.
On the IPSec Traffic Selector (Continued), select the remote traffic destination. This screen
looks very similar to the last screen, but this is to specify the remote site or destination traffic to protect with IPSec. Because the PIX Firewall does not know how to get to the remote
network range, you get the message seen in Figure 6.11. You will need to create and add
the host or network to the PIX Firewall configuration. Use the Create Host/Network dialog
box (shown in Figure 6.12) to create this remote network range, which is accessible from
the outside interface, called the host/network Remote_Protected. Click Next.
FIGURE 6.9
Creating the transform set
266
Chapter 6
VPNs and the PIX Firewall
FIGURE 6.10
Selecting an IPSec traffic that is protected by IPSec
FIGURE 6.11
The Add Host/Network? dialog box
7.
Once you have created the host or network to protect on the remote site, select that network on the IPSec Traffic Selector (Continued) screen using the right arrow button, just as
you did on the IP Traffic Selector screen. Figure 6.13 shows that we’ve selected the Remote_
Protected network to protect with this IPSec tunnel.
8.
To complete the wizard, click the Finish button on the IPSec Traffic Selector (Continued)
screen.
You can now navigate through the options in the VPN tab to see the various parameters and
objects created by the wizard. You can also change these to make changes to your site-to-site VPN.
Using PDM to Create VPNs
FIGURE 6.12
Creating a remote network range
FIGURE 6.13
Selecting the network
267
268
Chapter 6
VPNs and the PIX Firewall
Setting Up a Remote Access VPN
In the previous section, you saw how to set up a site-to-site VPN. Now we will go through the
VPN Wizard again, but this time we will follow the remote access VPN track:
1.
On the initial VPN Wizard screen (refer back to Figure 6.6), select Remote Access VPN and
press Next.
2.
On the Remote Access Client screen (see Figure 6.14), select the type of VPN client that will
be accessing the PIX Firewall. In this example, our users will be using the Cisco VPN client
3.x or higher, so we need to select that option and click Next.
FIGURE 6.14
3.
Selecting the remote access client
On the VPN Client Group screen (see Figure 6.15), create a VPN group and authentication method used by the clients. In this example, because we have a smaller group of people that will be accessing the VPN from remote, use preshared key, which is also known
as the group password. Call the group Sales_Force because the sales staff will be using
this remote access VPN the most. (We could also select to use a certificate for authentication.) Click the Next button.
Using PDM to Create VPNs
FIGURE 6.15
269
Creating a VPN group
4.
If you are using Xauth, you need to select the AAA server group that will be used to
authenticate VPN users to this group. On the Extended Client Authentication screen (see
Figure 6.16), check the Enable Extended Client Authentication check box to use AAA
services for VPN client authentication. You can also create an AAA group if one is not
already created from this screen. You can also specify if this AAA server group is using
the one-time password feature for greater security. If you are not using Xauth, you can
uncheck the Enable Extended Client Authentication check box. Select Next to move to
the next screen.
5.
On the Address Pool screen (see Figure 6.17), create or select the IP pool to use for clients
in this VPN group. In this example, we have chosen to create a new pool called Sales_Pool
and add 100 addresses to this pool. These IP addresses will be assigned to VPN clients
authenticated to this group so they appear as nodes on the inside network. Click Next to
continue.
270
Chapter 6
VPNs and the PIX Firewall
FIGURE 6.16
Selecting an AAA server group
FIGURE 6.17
Creating an IP address pool
Using PDM to Create VPNs
6.
This next step is optional. On the Attributes Pushed to Client screen (see Figure 6.18), configure the VPN client with the DNS, WINS, and domain name of the inside network. In this
example, we have chosen to push these attribute values to the VPN clients so they will be
able to resolve internal DNS and WINS addresses as if they were on the inside of the network. Click Next to go on to the next screen.
FIGURE 6.18
7.
271
Pushing attributes to a VPN client
This next step is optional as well. On the Address Translation Exemption screen (see Figure 6.19), configure NAT for VPN users. Usually you want to expose the real IP addresses
on the internal network to the VPN users. If no selection is made, then no internal hosts
will be NATed to the VPN users. One instance where this might be useful is if the remote
VPN user is using a network address that is used inside the corporate network. You can
create a rule here to NAT that address range from the corporate network to the VPN user
so they will be able to see the resources on the corporate network. Click Finish to complete the VPN configuration.
Now that you have completed both the site-to-site and remote access VPN wizards, you can
look through the VPN tab to see the changes that were made and the objects that were added.
Figure 6.20 shows the VPN tab after the VPN configuration. There are now two new IPSec
rules: one for the site-to-site and one for the remote access VPN.
272
Chapter 6
VPNs and the PIX Firewall
FIGURE 6.19
Choosing whether to make the internal network exposed to outside users
FIGURE 6.20
The VPN tab
Enterprise PIX Firewall Management and Maintenance
273
Enterprise PIX Firewall Management
and Maintenance
When it comes to managing and mainting the PIX Firewall, the PDM is good if you have one
PIX Firewall. You can even manage several PIX Firewalls from a single workstation, but what
if you have hundreds of PIX Firewalls? This is where the Cisco Secure Policy Manager and
CiscoWorks VMS come into play.
In the next sections, we will talk about the Cisco Secure Policy Manager, PIX Management
Center, and the Auto Update Server and how these tools can be used to manage the PIX Firewall
in the enterprise.
Cisco Secure Policy Manager (CSPM)
The CSPM is a scalable and powerful security-policy management system for Cisco PIX Firewalls, Cisco IOS firewalls, VPN routers, and intrusion detection system (IDS) sensors. Using
CSPM, you can define, distribute, enforce, and audit network-wide security policies from a central location. CSPM streamlines the tasks for managing complex network security elements,
such as perimeter access control, NAT, and IPSec-based VPNs. Figure 6.21 shows the CSPM
screen and an example of a network topology.
FIGURE 6.21
CSPM screen
274
Chapter 6
VPNs and the PIX Firewall
CSPM is the cornerstone of the Cisco end-to-end security solution, and it simplifies the
deployment of security devices and services within a Cisco centric network. CSPM was produced to replace the PIX Firewall configuration completely, and provides the following firewall
management capabilities:
Defines the interface settings such as the name, IP address, and security level.
Defines device characteristics such as timeouts, flood guard, and logging.
Defines access rules that can manage the traffic flow on Context-Based Access Control
(CBAC) enabled routers plus it can add commands generated from policy statements.
Converts policy statements into PIX Firewall configuration commands that are inserted
into an existing configuration for a router-based firewall. It completely replaces the configuration of a PIX Firewall.
Manages remote and local devices over the network.
With CPSM you can define high-level security policies visuals for multiple PIX Firewalls,
routers, and IDS sensors. First, you need to define the network topology and how the controlled
devices are situated in the network. Then you can define a global policy using the access and
translation rules, which describe how different traffic flows should be treated. Since the CSPM
has information about the relative position of controlled devices, the policy statements do not
need to be defined per device. The software calculates which devices must enforce each policy
statement and creates commands for those devices.
VPNs can be configured between multiple devices with CSPM. This can be done through the
GUI or multiple IPSec templates for both full-mesh and hub-and-spoke networks. These templates add value in any security network environment by simplifying small security networks,
multi-site deployments, and large service-provider environments by centralizing and abstracting
the management of security networks. After these policies have been created, you need to save
and generate the device configurations. This goes through a consistency checker, which allows
you to resolve any errors encountered.
Once checked and saved, the configurations can be distributed, or pushed, from a centralized
location, eliminating the costly, time-consuming practice of implementing security commands
on a device-by-device basis via the CLI. This is done under the Command tab of each device.
This is where a certain level of version control can be accomplished. You can review carefully
the generated commands and click the Approve Now button, which deploys the configuration
to the target device.
For CSPM to manage a PIX Firewall, a special IPSec Bootstrap Configuration section is generated in the Command section of the PIX Firewall object. This section is located at the end of
the Command box and is denoted by a hash mark (#)before each command. This character
must be removed for these commands to be activated. Since CSPM accomplishes management
through secure Telnet, you must also enable Telnet from the CSPM host.
Enterprise PIX Firewall Management and Maintenance
275
PIX Management Center (MC)
While the PDM addresses single-device management and CSPM addresses policy-based
management, the PIX MC addresses the mid-level, multi-device management. The PIX MC
is a component of CiscoWorks2000 under the VPN/Security Management Solution (VMS),
uses terminology and concepts consistent with PDM, and has a look and feel consistent with
PDM. It communicates with the PIX Firewall on TCP port 443 (HTTPS), so communications are secured.
The PIX MC is installed on the CiscoWorks2000 Server system. You must log in to the
CiscoWorks2000 Server desktop and navigate to the VPN/Security Management Solution
drawer. As you can see in Figure 6.22, you must expand the Management Center folder and
click on the PIX Firewalls icon. This will launch the Management Center for PIX Firewalls in
a separate window.
FIGURE 6.22
CiscoWorks2000
276
Chapter 6
VPNs and the PIX Firewall
Figure 6.23 shows the PIX MC screen so you can see the options available.
The Devices tab is used to import PIX Firewalls to be handled in the Management Center,
arrange them in groups, and administer those groups. The Configuration tab allows you to configure firewall settings, access rules, transition rules and building blocks, and view the configuration for each device. Using building blocks, you can create service groups. The Workflow tab
is used to manage activities and jobs that can ensure the correct procedures are in place to
approve device configuration changes. The Report tab allows you to review audit records about
actions that users have taken within an activity. Finally, the Admin tab is used to require
approval for activities and jobs, perform database maintenance, and gather troubleshooting
information through the MDCSupport utility when debugging problems.
Before you can import a PIX Firewall into the PIX MC, you must bootstrap the device by setting up the firewall with a minimum configuration. You need to name the PIX Firewall, assign
an IP addresses, bring up the interfaces, create and enable a Telnet password, and enable the
HTTP server to allow access from the PIX MC server because the server uses TCP port 443 for
secure communications.
FIGURE 6.23
Management Center for PIX Firewalls
Enterprise PIX Firewall Management and Maintenance
277
Here is an example of a bootstrap configuration for the PIX Firewall, which will allow the
Firewall to be imported into the PIX MC:
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 dmz security60
enable password 2KFQnbNIdI.2KYOU encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
hostname PIX
interface ethernet0 auto
interface ethernet1 auto
interface ethernet2 auto
ip address outside 120.110.1.1 255.255.255.0
ip address inside 192.168.10.1 255.255.255.0
ip address dmz-a 127.0.0.1 255.255.255.255
http server enable
http 192.168.10.11 255.255.255.255 inside
Whenever you are doing a task within the PIX MC, the software requires you to create an
activity. This activity will be a procedure for the PIX MC to accomplish. For example, importing or creating a device in addition to modifying the device requires an activity. You might be
thinking it’s over. You approve the activity and the changes are made. But the PIX MC has this
other workflow item called a job. A job is a collection of activities, and this is where the work
is really done. You need to create a job, assign one or more activities to the job, and approve
the job before the activities are executed.
Each job can be executed right away or it can be sent to the Auto Update Server. When you
choose to execute right way, you can choose to deploy to each affected device individually or
all devices simultaneously.
Auto Update Server (AUS)
Like the PIX MC, the AUS is accessible through the CiscoWorks2000 Server desktop and is under
the VPN/Security Management Solution drawer. If you look at Figure 6.22, you will see the Auto
Update Server icon, which you click to launch the AUS in a separate window. Figure 6.24 shows
the AUS screen and the options available.
From the Devices tab, you can see a summary of information about the devices known to the
AUS. You cannot add or delete devices from this tab; you can only view the summarized device
information. You add and delete AUS-managed devices through the PIX MC. The Images tab
displays information about the PIX Firewall software images, PDM images, and configuration
files in the repository. It also allows you to add or delete PIX Firewall software images and PDM
images. The Assignments tab allows the user to change device-to-image and image-to-device
assignments. The Reports tab displays the system information report and event report. The
Admin tab allows the user to change the database password and configure the NAT address.
278
Chapter 6
FIGURE 6.24
VPNs and the PIX Firewall
Auto Update Server screen
Sometimes the AUS is placed behind a firewall and is not accessible from the outside network.
The AUS needs to be able to update those devices outside the network, so there must be a mechanism to allow the outside devices to communicate with the AUS. The NAT address is used to control which IP address these outside devices use to communicate with the AUS. If you are managing
all internal devices, then this should be the IP address of the AUS. If not, then it needs to be
changed to the outside IP address, which is being NATed to the IP address of the AUS.
If you choose to manage a device using the Auto Update Server, you need to configure certain
settings on the PIX Firewall to bootstrap it and others on the PIX MC. To bootstrap the PIX
Firewall to communicate with the AUS for the first time, use the auto-update commands.
If you have enabled the unique identity feature, discussed below, then use the auto-update
device-id command together with the parameter for the type of unique identification. The identification parameter options include hardware-serial, hostname, ipaddress, mac-address,
and string. If you use ipaddress or mac-address, then you must add an interface parameter.
If you use string, then you must supply a unique string value.
The auto-update server command takes one URL that is made up of several portions. The
syntax is https://username:[email protected]/autoupdate/AutoUpdateServlet.
The username and password is the username and password to use on the PIX MC, and this
username must have the ability to add devices and add or delete configuration files. The ipaddress is the IP address or hostname of the AUS.
Enterprise PIX Firewall Management and Maintenance
279
You can also change the time between polling intervals with the auto-update poll period
interval command. The polling interval is in minutes, and the default is 720 minutes. Now
let’s look at what it takes to add a PIX Firewall to the AUS.
The following is the list of settings on the PIX MC that need to be changed. First, you need
to configure the settings the PIX Firewall will use to connect to the AUS by following these steps.
1.
Select Configure Settings Server and Services Auto Update Server. The Auto Update
Server page appears.
2.
Uncheck the Inherit Settings check box.
3.
Select the Enable Auto Update Server check box to activate the Auto Update Server feature
on the PIX Firewall.
4.
In the IP Address field, enter the IP address of the AUS.
5.
In the Port field, enter the number of the port used for AUS. The default is 443 (HTTPS).
6.
In the Path field, enter the directory path to the servlet that the device uses to access the
Auto Update Server. The default path is /autoupdate/AutoUpdateServlet.
7.
In the Username field, enter the username for the PIX Firewall.
8.
In the Password field, enter the password for the PIX Firewall.
9.
In the Confirm Password field, reenter the password for the PIX Firewall.
10. In the Poll Period (Minutes) field, enter the number of minutes for the PIX Firewall to wait
between polls to AUS. The default is 720 minutes.
11. In the Poll Retry Count field, enter the number of times the PIX Firewall should try to con-
nect to the AUS if the first try is unsuccessful. The default is 0.
12. In the Poll Retry Period (Minutes) field, enter the number of minutes between retries. The
default is 5.
13. In the Deactivate PIX Firewall If No Update For field, enter the number of minutes the PIX
Firewall should wait for updates from the AUS with no response before it deactivates itself.
14. Click Apply.
Then, you need to configure the method of identification that will be used between the PIX
Firewall and the AUS by following these steps:
1.
Select Configure Settings PIX Firewall Administration Unique Identity.
2.
Uncheck the Inherit Settings check box.
3.
Select the Enable Device Unique Identity check box to activate the feature on the PIX Firewall.
Select the method to confirm the PIX Firewall identity. Options are
4.
5.
Host Name
Hardware Serial Number
IP Address
MAC Address
Unique Identity String
Click Apply.
280
Chapter 6
VPNs and the PIX Firewall
Next, configure the information that PIX MC will use to contact the AUS by following
these steps:
1.
Select Configure Settings PIX MC Control Auto Update Server Contact.
2.
In the Auto Update Server Name field, enter the hostname or IP address of the AUS.
3.
In the Auto Update Port field, enter the number of the port to access AUS. The default is
443 (HTTPS).
4.
In the Unique ID field, enter the value that corresponds to the unique identity chosen in the
Unique Identity page.
5.
In the Username field, enter the username used to gain access to the AUS. The username
should have permission to add devices and add or delete configuration files. You most
likely should enter admin.
6.
In the Password field, enter the password used to gain access to the AUS. You should use
the password assigned to the username above.
7.
In the Confirm Password field, reenter the password.
8.
Click Apply.
Finally, configure deployment of configuration files to AUS for the selected device by following these steps:
1.
Select Configure Settings PIX MC Control Deployment.
2.
Uncheck the Inherit Settings check box.
3.
In the Deployment Type field, select the destination to which configuration files are
deployed. Choose the Auto Update Server option, which downloads the configuration files
to the Auto Update Sever for later deployment to firewalls operating in Auto-Update mode.
4.
Click Apply.
To bootstrap the PIX Firewall, which will allow the firewall to contact the AUS the first time,
enter the following command:
PIX(config)# auto-update device-id hardware-serial
PIX(config)# auto-update server
➥https://admin:[email protected]/autoupdate/AutoUpdateServlet
PIX(config)#
You can verify the configuration is correct and how long before the next poll by using the
show auto-update command. An example is shown below:
PIX(config)# show auto-update
Server: https://10.192.12.100/autoupdate/AutoUpdateServlet
Poll period: 720 minutes, retry count: 0, retry period: 5 minutes
Timeout: none
Device ID: host name [PIX]
Next poll in 0.83 minutes
PIX(config)#
Exam Essentials
281
Once you have configured the PIX MC and PIX Firewall to access the AUS, you can now
manage the firewall from the AUS. Whenever changes are made to the PIX Firewall from the
PIX MC, those changes will be sent to the AUS, then on the next polling cycle, the PIX Firewall
will download those changes.
Summary
This chapter described how to configure IPSec on the PIX Firewall, including the preliminary
preparation, IKE configuration, preshared keys configuration, and CA configuration. Configuring IPSec on the PIX Firewall is very easy, but the PIX Firewall really does not like Transport
mode tunnels, so it limits how those tunnels can be formed.
The PIX Firewall prevents traffic from coming into the firewall unless a device on the trusted
side initiated the connection. Since this can be a problem with VPNs, the PIX Firewall needs to
be configured to allow VPN traffic in from the outside.
We talked about how to manage and maintain the PIX Firewall in an Enterprise network
using Cisco Secure Policy Manager and CiscoWorks2000. VPN/Security Management Solution
is the CiscoWorks2000 software that consists of the PIX Management Center and the Auto
Update Server. With these solutions, you can manage and maintain not only PIX Firewalls but
also IOS routers and IDS Sensors.
Exam Essentials
Understand how the PIX Firewall implements IKE and IPSec. Know that the PIX Firewall uses
IKE to authenticate and create a secure tunnel to communicate IPSec parameter to the VPN peer.
Authentication can take place with a preshared key or by using digital certificates. IPSec provides
secure tunnels between two peers and can protect and authenticate traffic inside the VPN tunnel
using DES or 3DES encryption and SHA or MD5 hash for authentication using a transform set.
Know how to use IKE Mode Config for Xauth and dynamic IP addressing. IKE Mode Config can be used to authenticate remote access VPN users using Xauth to an AAA server group.
This can also be used to configure the VPN Client with a dynamic IP address and other optional
network parameters.
Remember how to configure and deploy the VPN Client. Understand the different options
for VPN Client and how to configure it for a VPN using preshared keys or digital certificate
authentication. You should also know how to customize the deployment of the VPN Client to
allow the user to install and run the software more easily.
Know how to use the PDM to create VPNs. You need to remember how to use the VPN Wizard to configure both site-to-site and remote access VPNs. You should also study the PDM
interface to see how the different VPN settings can be modified and the impact this has on the
PIX Firewall configuration.
282
Chapter 6
VPNs and the PIX Firewall
Understand the role of the Cisco Secure Policy Manager. The CSPM is a stand-alone application that allows a user to remotely manage many Cisco security devices including the PIX
Firewall. The CSPM uses policies for a high-level view of the security network. Each device
implements its portion of the overall security policy and the CSPM pushes those portions to the
respective device.
Know the components of VMS and how to access them. The PIX Management Center and
Auto Update Server are both components of the VPN/Security Management Solution. The VMS
has its own drawer, which is accessible from the CiscoWorks2000 Server desktop, where you
can launch the AUS and management centers for PIX Firewall, routers, and IDS sensors.
Understand how to add a device to PIX MC and AUS. You should know what commands
are needed to bootstrap the PIX Firewall to be managed by the PIX MC and AUS. You need to
understand what configuration settings need to be implemented on the PIX MC to make a
device manageable by AUS. You should also understand how to implement activities and jobs
within the PIX MC and how to manage PIX Firewall configurations and images from the AUS.
Key Terms
Before you take the exam, be certain you are familiar with the following terms:
.pcf extension
individual profiles
Adaptive Security Algorithm (ASA)
Network Time Protocol (NTP)
Bootstrap
PIX Management Center (MC)
Cisco Secure Policy Manager (CSPM)
profile configuration file
extended authentication (Xauth)
protection suite
Fully Qualified Domain Name (FQDN)
Security Associations (SAs)
global profile
VPN/Security Management Solution (VMS)
IKE policy
vpnclient.ini
Written Lab
1.
What is the strongest encryption available on a PIX Firewall running version 6.2?
2.
What command is used to create a pool of IP addresses on the PIX Firewall to be assigned
to remote access VPN users?
3.
Which tab on the AUS allows you to view the device summary?
Hands-On Lab
283
4.
What is used to make it easy to create VPNs on the PDM?
5.
What is the default poll period for the PIX Firewall to communicate to the AUS?
6.
What command is used to assign a DNS server to remote access VPN users?
7.
What functions can be accomplished from the Admin tab in AUS?
8.
What parameters must be used in the isakmp key command to ensure a site-to-site VPN
peer is not assigned a dynamic IP address or DNS/WINS servers?
9.
What kind of crypto map must be used for remote access VPNs?
10. What command do you use to enable IKE globally on the PIX Firewall?
Hands-On Lab
In this section, we will implement what we learned in this chapter to configure a couple of PIX
Firewalls to protect traffic between two subnets. We will configure the PIX Firewall to use the
strongest possible encryption available to protect the traffic from users on the Internet.
The following graphic displays the physical layout of the network and PIX Firewalls.
117.102.19.20
216.10.189.12
Inside
10.192.12.0/24
Inside
10.192.13.0/24
PIX1
Internet
PIX2
This section includes the following labs:
Lab 6.1: Create an IKE policy to use a preshared key for authentication.
Lab 6.2: Create a strong transform set using 3DES and SHA.
Lab 6.3: Configure an access list that represents the traffic that will be protected by IPSec
through the tunnel without NATing the traffic.
Lab 6.4: Create a crypto map and assign a preshared key to the remote peers.
Lab 6.5: Tie all options together and assign to the outside interface.
Lab 6.6: Verify proper operation of the configuration.
284
Chapter 6
VPNs and the PIX Firewall
LAB 6.1
Creating an IKE policy to use a preshared key for authentication.
1.
Create an IKE policy on PIX1 that uses preshared keys to authenticate each other.
2.
Configure the IKE policy on PIX1 to use SHA for the hash algorithm.
3.
Configure the IKE policy on PIX1 to use Diffie-Hellman Group 2.
4.
Configure the IKE policy on PIX1 to use 3DES for encrypting the IKE tunnel.
5.
Leave the tunnel lifetimes at the default values on PIX1.
6.
Enter the same commands on PIX2.
LAB 6.2
Creating a strong transform set using 3DES and SHA.
1.
Create an IPSec transform set on PIX1 that encrypts data using 3DES and uses SHA to
authenticate the traffic.
2.
Create a transform set on PIX2 that matches the transform set just created on PIX1.
LAB 6.3
Configure an access list that represents the traffic that will be protected
by IPSec through the tunnel without NATing the traffic.
1.
Create an access list on PIX1 that reflects the traffic that will be protected by IPSec.
2.
Create an access list on PIX2 that reflects the traffic that will be protected by IPSec; this
should be a mirror of the access list on PIX1.
LAB 6.4
Create a crypto map and assign a preshared key to the remote peers.
1.
Create a crypto map of type ipsec-isakmp on PIX1 that will be used by the VPN.
2.
Configure the preshared key on PIX1 that will be used to authenticate the remote peer and
make sure this peer will not be assigned any network configuration options or be authenticated to the AAA server group if one is configured later.
3.
Enter the same commands on PIX2.
Hands-On Lab
285
LAB 6.5
Tie all options together and assign to the outside interface.
1.
Assign the transform set created in Lab 6.2 to the newly created crypto map.
2.
Assign the access list created in Lab 6.3 to the newly created crypto map.
3.
Assign the crypto map to the outside interface.
4.
Enable ISAKMP on the outside interface.
5.
Permit IPSec traffic to terminate on the PIX Firewall.
6.
Enter the same commands on PIX2.
LAB 6.6
Verifying proper operation of the configuration
1.
Enter the command to view information about which crypto maps are active on PIX Firewall PIX1.
2.
Enter the command to view the security associations active on PIX Firewall PIX1.
3.
Enter the same commands above on PIX2.
286
Chapter 6
VPNs and the PIX Firewall
Answer to Lab 6.1
PIX1# conf t
PIX1(config)#
PIX1(config)#
PIX1(config)#
PIX1(config)#
PIX1(config)#
PIX1#
isakmp
isakmp
isakmp
isakmp
exit
policy
policy
policy
policy
10
10
10
10
authen pre-share
encrypt 3des
hash sha
group 2
PIX2# conf t
PIX2(config)#
PIX2(config)#
PIX2(config)#
PIX2(config)#
PIX2(config)#
PIX2#
isakmp
isakmp
isakmp
isakmp
exit
policy
policy
policy
policy
10
10
10
10
authen pre-share
encrypt 3des
hash sha
group 2
Answer to Lab 6.2
PIX1# conf t
PIX1(config)# crypto ipsec transform-set strong-set esp-3des esp-sha-hmac
PIX1(config)# exit
PIX1#
PIX2# conf t
PIX2(config)# crypto ipsec transform-set strong-set esp-3des esp-sha-hmac
PIX2(config)# exit
PIX2#
Answer to Lab 6.3
PIX1# conf t
PIX1(config)#
➥10.192.13.0
PIX1(config)#
PIX1(config)#
PIX1#
access-list Protect permit ip 10.192.12.0 255.255.255.0
255.255.255.0
nat (inside) 0 access-list Protect
exit
Hands-On Lab
PIX2# conf t
PIX2(config)#
➥10.192.12.0
PIX2(config)#
PIX2(config)#
PIX2#
access-list Protect permit ip 10.192.13.0 255.255.255.0
255.255.255.0
nat (inside) 0 access-list Protect
exit
Answer to Lab 6.4
PIX1# conf t
PIX1(config)# crypto map CiscoVPN 10 ipsec-isakmp
PIX1(config)# isakmp key sybex address 216.10.189.12 no-xauth no-config-mode
PIX1(config)# exit
PIX1#
PIX2# conf t
PIX2(config)# crypto map CiscoVPN 10 ipsec-isakmp
PIX2(config)# isakmp key sybex address 117.102.19.20 no-xauth no-config-mode
PIX2(config)# exit
PIX2#
Answer to Lab 6.5
PIX1# conf t
PIX1(config)#
PIX1(config)#
PIX1(config)#
PIX1(config)#
PIX1(config)#
PIX1(config)#
PIX1#
crypto
crypto
crypto
isakmp
sysopt
exit
map CiscoVPN 10 match address Protect
map CiscoVPN 10 set transform-set strong-set
map CiscoVPN interface outside
enable outside
connection permit-ipsec
PIX2# conf t
PIX2(config)#
PIX2(config)#
PIX2(config)#
PIX2(config)#
PIX2(config)#
PIX2(config)#
PIX2#
crypto
crypto
crypto
isakmp
sysopt
exit
map CiscoVPN 10 match address Protect
map CiscoVPN 10 set transform-set strong-set
map CiscoVPN interface outside
enable outside
connection permit-ipsec
287
288
Chapter 6
VPNs and the PIX Firewall
Answer to Lab 6.6
PIX1# show crypto map
Crypto Map: "CiscoVPN" interfaces: { outside }
Crypto Map "CiscoVPN" 10 ipsec-isakmp
access-list Protect; 1 elements
access-list Protect permit ip 10.192.12.0 255.255.255.0 10.192.13.0
255.255.255.0 (hitcnt=0)
Current peer: 216.10.189.12
Security association lifetime: 4608000 kilobytes/28800 seconds
PFS (Y/N): N
Transform sets={ strong-set, }
PIX1# show crypto ipsec sa
interface: outside
Crypto map tag: CiscoVPN, local addr. outside
local ident (addr/mask/prot/port): (216.10.189.12/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (117.102.19.20/255.255.255.255/0/0)
current_peer: 216.10.189.12
PERMIT, flags={origin_is_acl,}
#pkts encaps: 91, #pkts encrypt: 91, #pkts digest 91
#pkts decaps: 77, #pkts decrypt: 77, #pkts verify 77
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0, #pkts
decompress failed: 0
#send errors 55, #recv errors 0
local crypto endpt.: outside, remote crypto endpt.: 216.10.189.12
path mtu 1514, ipsec overhead 44, media mtu 1514
current outbound spi: 2efc960f
inbound esp sas:
spi: 0xe51b943c(3843789884)
transform: esp-3des esp-md5-hmac,
in use settings ={Tunnel, }
slot: 0, conn id: 4, crypto map: CiscoVPN
sa timing: remaining key lifetime (k/sec): (4607998/4514)
IV size: 8 bytes
Hands-On Lab
replay detection support: Y
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x2efc960f(788305423)
transform: esp-3des esp-md5-hmac,
in use settings ={Tunnel, }
slot: 0, conn id: 3, crypto map: CiscoVPN
sa timing: remaining key lifetime (k/sec): (4607995/4505)
IV size: 8 bytes
replay detection support: Y
outbound ah sas:
outbound pcp sas:
PIX1#
PIX2# show crypto map
Crypto Map: "CiscoVPN" interfaces: { outside }
Crypto Map "CiscoVPN" 10 ipsec-isakmp
access-list Protect; 1 elements
access-list Protect permit ip 10.192.13.0 255.255.255.0 10.192.12.0
255.255.255.0 (hitcnt=0)
Current peer: 117.102.19.20
Security association lifetime: 4608000 kilobytes/28800 seconds
PFS (Y/N): N
Transform sets={ strong-set, }
PIX2# show crypto ipsec sa
interface: outside
Crypto map tag: CiscoVPN, local addr. outside
local ident (addr/mask/prot/port): (117.102.19.20/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (216.10.189.12/255.255.255.255/0/0)
current_peer: 117.102.19.20
PERMIT, flags={origin_is_acl,}
289
Chapter 6
290
#pkts
#pkts
#pkts
#pkts
#send
VPNs and the PIX Firewall
encaps: 77, #pkts encrypt: 77, #pkts digest 77
decaps: 91, #pkts decrypt: 91, #pkts verify 91
compressed: 0, #pkts decompressed: 0
not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
errors 55, #recv errors 0
local crypto endpt.: outside, remote crypto endpt.: 117.102.19.20
path mtu 1514, ipsec overhead 44, media mtu 1514
current outbound spi: e51b943c
inbound esp sas:
spi: 0x2efc960f(788305423)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 4, crypto map: CiscoVPN
sa timing: remaining key lifetime (k/sec): (4607998/4514)
IV size: 8 bytes
replay detection support: Y
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xe51b943c(3843789884)
transform: esp-3des esp-md5-hmac,
in use settings ={Tunnel, }
slot: 0, conn id: 3, crypto map: CiscoVPN
sa timing: remaining key lifetime (k/sec): (4607995/4505)
IV size: 8 bytes
replay detection support: Y
outbound ah sas:
outbound pcp sas:
PIX2#
Review Questions
291
Review Questions
1.
What default RSA key size does the PIX Firewall use?
A. 512
B. 768
C. 1024
D. 2048
2.
How may an ACL state that the IP address in the list is for a single device? (Choose all that apply.)
A. user
B. host
C. 0.0.0.0
D. 0
E. 255.255.255.255
3.
What traffic does the PIX Firewall allow in by default?
A. Everything
B. Nothing
C. Pings
D. Replies
4.
Which PIX Firewall operating system version first allowed VPNs to terminate on any interface?
A. 5.0
B. 5.1
C. 5.2
D. 5.3
E. 6.0
5.
Which types of tunnels can use Transport mode in PIX Firewall operating system 6.0?
A. L2TP
B. L2F
C. PPTP
D. IPSec
292
6.
Chapter 6
VPNs and the PIX Firewall
What is the default IKE tunnel lifetime?
A. One hour
B. Six hours
C. One day
D. One week
7.
What is the debug message that shows the IKE tunnel came up?
A. IPSEC_NO_ERROR
B. ISAKMP_NO_ERROR
C. IKE_NO_ERROR
D. IKMP_NO_ERROR
8.
When configuring the CA enrollment parameters, what is required? (Choose all that apply.)
A. Name
B. Serial number
C. Password
D. IP address
9.
What are the components of the CiscoWorks2000 VMS? (Choose all that apply.)
A. PIX Management Console
B. PIX Management Center
C. Auto Update Server
D. Campus Manager
E. LAN Management Solution
10. What devices are manageable from the Cisco Secure Policy Manager (CSPM)? (Choose all
that apply.)
A. VPN Concentrators
B. IOS Routers
C. PIX Firewalls
D. IDS Sensors
E. All of the above
Answers to the Written Lab
293
Answers to the Written Lab
1.
3DES is the strongest encryption algorithm for version 6.2 of the PIX Firewall software.
2.
The ip local pool command is used to create a pool on the PIX Firewall. These can be
assigned to remote access VPN clients.
3.
The Device tab is used to view a summary of device information.
4.
The VPN Wizard is used to easily create VPNs on the PDM.
5.
The default poll period is 720 minutes, which is 12 hours.
6.
The vpngroup dns-server command is used to assign the DNS server option to the VPN
clients.
7.
You can change the database password and NAT address under the Admin tab in AUS.
8.
The no-xauth and no-mode-config parameters are used on the isakmp key command
to exclude this peer from the IKE Xauth and Mode Config modes.
9.
You must use a dynamic crypto map for remote access VPNs.
10. This is a trick question because IKE is enabled globally on the PIX Firewall but is enabled
or disabled only on the interface.
294
Chapter 6
VPNs and the PIX Firewall
Answers to Review Questions
1.
B. The default RSA key size on the PIX Firewall is 768 bits.
2.
B, E. An ACL can specify a single IP address by using the term host or by using an “all ones”
subnet mask: 255.255.255.255.
3.
D. Once the PIX Firewall has the appropriate NAT configuration set up, the Adaptive Security
Algorithm (ASA) will allow only replies through the firewall until it is specifically configured to
allow other traffic.
4.
B. 5.1 is the first version of the PIX Firewall operating system that allows any interface to terminate a VPN tunnel.
5.
A. L2TP is the supported tunneling method for Transport mode VPNs.
6.
C. The default lifetime for both IPSec and IKE tunnels is one day.
7.
D. IKMP_NO_ERROR is the debug level message that appears when the IKE tunnel comes up.
8.
A, C. The CA name and a challenge password are needed when enrolling with a CA. Including
the interface IP address and the device serial number in the certificate is optional.
9.
B, C. The PIX Management Console is not a valid package and Campus Manager and LAN
Management Solution are valid but not part of VMS.
10. B, C. Only IOS Routers and PIX Firewalls are manageable from the CSPM.
Cisco Secure
Virtual Private
Networks
PART
II
Chapter
7
Introduction to
Virtual Private
Networks
THE FOLLOWING TOPICS ARE COVERED IN
THIS CHAPTER:
The Cisco Secure virtual private network (VPN) product
family developed by Cisco Systems
IPSec and other open standards supported by Cisco Secure
VPN products
Component technologies of IPSec
How IPSec works
This chapter introduces VPN concepts and explains how VPN
tunnels are created. The information presented here provides the
foundation for the detailed, device-specific material in the following chapters.
We’ll begin with some basics, including discussions of the types of VPNs and devices. The
remainder of this chapter covers IPSec and Internet Key Exchange. IPSec is a standards-based
method of negotiating a secure connection between peers. Internet Key Exchange is a protocol
used to provide authentication between peers. We’ll discuss the various authentication types,
the different ways a VPN tunnel can be built, the steps involved in the process, and the order
of events. Finally, we’ll address potential problems associated with tunnels and how to troubleshoot them.
VPN Basics
A VPN is an extension of a network. It is virtual because it does not use reserved circuits. A VPN
may pass over a circuit that is used for only VPN traffic, but this is not a requirement. It is private because it is a tunnel. This tunnel does not need to be encrypted or have any sort of protection for the data, although it can use encryption and other security measures. A device can
be configured to allow only certain types of traffic to access the tunnel. It is a network because
it extends an existing network past its natural boundaries.
In the following sections, we will discuss the major types of VPNs configurations used in most
production environments today and the various Cisco devices on which they are configured.
Major Types of VPNs
There are many types of VPNs, but they are usually defined by how they are created and what
purpose they serve. The following are three major types of VPNs:
Access VPN An access VPN is used to connect to the network over a shared medium such as the
Internet. People using the modem on their PC to connect to a modem at work are crossing the
shared medium of the public telephone system. People connecting to their ISP to use the Internet
to transport VPN traffic are connecting to two shared mediums. They first use DSL, cable, or dialup connections to access their ISP, and then use the Internet to go the rest of the way.
Intranet VPN An intranet VPN is used to connect two trusted locations to each other over a
dedicated connection. An example would be a VPN between a corporate headquarters in Maine
VPN Basics
299
and a manufacturing facility in Thailand. The key elements are the trusted locations and connection dedicated to VPN traffic.
Extranet VPN An extranet VPN is used to connect untrusted locations to each other over a
dedicated connection. An example would be a headquarters office in Maine using a VPN to connect to the ordering system of a supplier in Ohio. There is a certain amount of trust, but not as
much as there would be if both sides were part of the same corporate infrastructure.
VPN Devices
A VPN is a tunnel, and each tunnel must begin and end somewhere. Cisco has many devices that
can act as one end of a VPN tunnel or manage it, including Cisco routers, the PIX Firewall,
Cisco VPN Concentrators, and the Cisco Secure VPN client software.
Cisco Secure is the name of the product line for Cisco’s security products. Cisco
Secure Policy Manager (CSPM), a component of Cisco Works, can be used to
manage VPNs.
Cisco devices don’t need to talk to just other Cisco devices. A Cisco router can be set up for a
direct VPN connection to a Windows 2000 server, a non-Cisco router, or another IPSec device.
IPSec is a standard, and as long as both vendors follow the instructions in the standard and
both devices are set up with the correct configuration, they should be able to form a tunnel. (IPSec
will be discussed in detail later in this chapter, beginning with the “Introducing IPSec” section.)
Let’s take a closer look at each type of Cisco VPN device and its capabilities.
Cisco Routers
Cisco routers come in various flavors and can do different tasks based on the available hardware and software. Different IOS feature sets will give more or fewer options for creating a VPN
tunnel. Cisco routers began supporting IPSec with IOS 11.3(T). Prior to this, they used Cisco
Encryption Technology (CET), which should not be used if IPSec is available.
Cisco IOS software can form many different types of tunnels. Along with IPSec tunnels,
Cisco routers can build Layer 2 Forwarding (L2F), Layer 2 Tunneling Protocol (L2TP), Pointto-Point Tunneling Protocol (PPTP), IP in IP encapsulation (IPinIP), and Generic Routing
Encapsulation (GRE) tunnels.
Even low-end routers can do encryption, but the type of encryption depends on the type of
router, the version of IOS, and the amount of memory. Newer routers with enough flash and
NVRAM can use an IOS image that allows for 3DES encryption. A 1600-series router or a
2500-series router doesn’t have the processing ability and is limited to basic Data Encryption
Standard (DES) encryption. Some 800-series routers are capable of using 3DES. (DES and 3DES
encryption are discussed in the “Encryption” section later in this chapter.)
It is normally not a good idea to terminate many VPN connections at even a robust router
because of the amount of processing that goes on in the encryption and decryption process. The
exception to this rule is when your router is outfitted with a VPN module. This module offloads the
300
Chapter 7
Introduction to Virtual Private Networks
processing from the CPU, keeping valuable CPU cycles free for other tasks. (For more information
about the VPN module, visit www.cisco.com/univercd/cc/td/doc/pcat/vpnnm.htm.)
Using Cisco routers for IPSec tunnels is discussed in detail in Chapter 9, “Configuring the VPN Concentrator.”
The PIX Firewall
Cisco has a number of PIX Firewall models available, from the low-end 501 to the high-end
535. The PIX Firewall has supported IPSec since version 5.0. This firewall can form a tunnel
with another device that is capable of a direct IPSec VPN connection, including Cisco routers,
firewalls, and VPN Concentrators.
All PIX Firewalls can use DES and 3DES encryption, but they must be licensed for it. A 3DES
license can be purchased through a Cisco reseller. If you currently have a PIX Firewall that is
not licensed for encryption, you can get a free key for DES by registering at www.cisco.com/
kobayashi/sw-center/ciscosecure/pix.shtml (access to this URL is available only with
a valid CCO login ID and password).
Configuring PIX Firewalls for VPNs is discussed in detail in Chapter 9.
The Cisco VPN Concentrator
The Cisco VPN Concentrator is designed to terminate many client VPN connections. It can also
form a tunnel with a router, firewall, or another concentrator.
You should use the VPN Concentrator if you have more than a few users who want to access
a network via a VPN tunnel. The concentrator is a stand-alone network device that offloads the
task of processing VPN tunnels from routers and firewalls. The VPN Concentrator can be managed via the command-line interface (CLI) or an HTML-based graphical user interface (GUI).
The 3000-series VPN Concentrators can terminate up to 10,000 user tunnels. The 5000series VPN Concentrators can terminate up to 50,000 tunnels. Because the 5000 models are
service-provider devices, neither this book nor the CSVPN exam covers them.
The features of the VPN Concentrator models are described in Chapter 8,
“Introduction to Cisco VPN Devices.” Details on configuring and managing
VPN Concentrators are provided in Chapter 9, as well as Chapter 10, “Managing the VPN Concentrator.”[
VPN Client Software
VPN client software is used on PCs and servers as one end of a tunnel. When users create a VPN
from their home PC, it terminates at a router, firewall, or concentrator.
VPN Basics
301
The Cisco Secure VPN client comes in two flavors. The older one is the SafeNet client that
Cisco uses to connect client PCs to routers and firewalls. There are two versions: 1.0 (which cannot use a certificate from a Windows 2000 certificate authority) and 1.1 (which can use a certificate from a Windows 2000 or XP certificate authority).
The other type of client is the concentrator client, often referred to as the Altiga client. It is
used to connect client PCs to the VPN Concentrator. There are two major versions of this client:
2.5 and 3.0. You should use whichever version of the client matches the software version on the
concentrator; for example, use a 2.5 client if you have version 2.5 software on the concentrator.
Why VPN Networking?
There are two main reasons why companies choose to install VPN technology: ease of administration and the all-important cost. Remote access and Intranet WAN networking are the two
most popular implementations for VPNs.
Remote Access
The use of Remote Access Services (RAS) has been a staple in remote IT connectivity for many
years. This remote access method required administrators to keep up the extra devices needed
such as modems, servers, operating systems, etc. And then there were the phone line access
charges, and if remote users were beyond the local calling area, then toll-free lines or calling
cards need to be issued, adding another level of expense. With a remote-access VPN, a company can eliminate the need for RAS and the costly phone lines. There will still be a cost for
Internet access however, and companies can negotiate excellent access rates (some as low as
$10 per month per user) and nationwide carriers boast local numbers from nearly everywhere,
thus eliminating the need for long-distance charges. Administration and hardware upkeep cost
are also reduced significantly. On average, a company that implements a VPN remote access
solution will realize 60–70 percent in overall cost savings.
Intranet WAN Networking
Prior to VPN technology, any connections between offices had to be done with costly dedicated
circuits. For most small/medium businesses (SMBs), the days of dedicated circuits between
remote offices and headquarters are gone. A much more cost-effective solution has become
connecting each office directly to the local Internet. Creating private VPN tunnels between
those offices provides adequate protection for the data and the cost savings of having the dedicated lines. Offices have access to the Internet and the remote office with a single connection
to the Internet. Multiple tunnels can even be configured to create remote-office-to-remoteoffice connectivity in a mesh configuration that once would have been cost prohibitive.
Chapter 7
302
Introduction to Virtual Private Networks
Cisco realized that requiring two different clients when only one can be installed at a time
was problematic. They have merged the two into the Unified Client. The latest version of the
Unified Client as of this writing is 4.0, which allows for VPNs to general Cisco devices. This version even comes with a transparent stateful firewall for the client. If you are using Windows XP,
you must use version 3.1 or higher.
Chapter 9 provides more details on using the VPN client software.
Introducing IPSec
IPSec is a standards-based way of creating a tunnel that data will travel along to get to its destination. An example of an IPSec tunnel is shown in Figure 7.1.
FIGURE 7.1
An IPSec tunnel
IPSec has the option of using several other standards to get the tunnel set up. One of these
is Internet Key Exchange (IKE), which is a protocol that works with IPSec.
IKE, RSA signatures, and certificate authorities are discussed in the “Internet
Key Exchange” section later in this chapter.
We will cover the IPSec components that provide authentication, encryption, and other services. These include the following:
The Authentication Header (AH) and Encapsulating Security Payload (ESP) protocols
Hashing
Encryption
Diffie-Hellman Key Exchange
IKE
Transform sets
IPSec Security Associations (SAs)
Introducing IPSec
303
However, before we discuss the individual components of IPSec, let’s see what services it can
provide.
IPSec Services
There are several tasks that IPSec can accomplish, if you wish to configure them. These include
the following:
Data Confidentiality Data confidentiality can be ensured by encrypting traffic as the packets
leave the router.
Data Integrity Data integrity can be ensured by verifying that packets have not changed after
they were sent. Hashing is used to verify that there have not been any changes to transferred data.
Data-Origin Authentication Data-origin authentication verifies the identity of the originator
of the packet.
Anti-Replay Anti-replay is a process by which the receiver can detect that a packet has already
been received and will reject any duplicate packets. (This does not interfere with the TCP
retransmission function.)
Configurations for all IP-related services are covered in depth in Chapter 9.
IPSec Building Blocks: AH and ESP
To establish an IPSec tunnel between two devices, those devices must negotiate how the tunnel
will be built. IPSec operates at layer 3 (the Network layer) of the OSI model in such a way that
it really inserts itself between layers 3 and 4 of the OSI model, but by ISO definition, encryption
is a layer 7 function There are two protocols to build tunnels and protect the data traveling
across the tunnel:
Authentication Header (AH), which uses protocol 51
Encapsulating Security Payload (ESP), which uses protocol 50
Knowing what AH and ESP do is essential to creating a good tunnel blueprint. We will look
at each of these, as well as Tunnel and Transport mode in the following sections.
The Authentication Header Protocol
AH, defined in RFCs 1826 and 2402, does not perform any sort of data encryption, so the information is passed in clear text. Its purpose is to provide data integrity and authentication as well as
anti-reply service, which is optional. It ensures that a packet that crosses the tunnel is the same packet
that left the peer device and that no changes have been made. It uses a keyed hash to accomplish this.
Figure 7.2 illustrates the hash creation. (Hashing is discussed in more detail a little later in
this chapter, in the “Hashing” section.)
304
Chapter 7
FIGURE 7.2
Introduction to Virtual Private Networks
The Authentication Header (AH) process
192.168.4.1/24
IP header
Data
Hash OIH987GH90VM
IP
AH
header
Router A
Data
Router B
Encryption is a very processor-intensive task, so there are situations where you
might want to use just AH. For example, you might not want to bother to
encrypt routing updates, but you will want to make sure that the data inside the
packets has not changed.
The AH information sits in the packet between the spots reserved for layers 3 and 4. The AH
header consists of six fields:
Next Header This 8-bit field identifies the protocol type after the AH. For example, for TCP
or UDP, this field would contain 4 or 17, respectively. When used as the IPSec protocol, the
value in the Next Header field will be 51.
Payload Length This 8-bit field indicates the length of the IPSec header in 32-bit word, minus
two. The fixed part of the length field is three words (96 bits) long. Although the Authentication
Data portion is a variable length, it still has a standard length of three words for a grand total
of six 32-bit words. When you accommodate for the deduction of two, the value entered in the
Payload Length field would then be four.
Reserved These 16 bits are currently unused and consist of zeros.
Introducing IPSec
305
Security Parameter Index (SPI) This 32-bit field holds a pseudo, random, arbitrarily assigned
number that is paired with the destination IP address and IPSec protocol to identify a particular
tunnel. The SPI identifies AH information and links it to an appropriate peer IP address and SA.
Sequence Number This 32-bit field can be used to enable anti-replay, helping prevent old
packets from being captured and reused. If anti-replay is not used, this field still exists. The
sequence number is an ever-increasing counter that is not allowed to repeat for the duration of
the SA. Often the number will be set to 0 when an SA is first established. The sequencing information is not always used by the receiver, however, it is included from the sender just in case.
Authentication Data This field is where the data is stored to ensure that the packet hasn’t been
tampered with, and it contains the Integrity Check Value (ICV). The field size depends on the
method used to do the hashing. The two methods used for Cisco devices, MD5 and SHA, will
truncate at 96 bits of information. Implementations in IPv4 require blocks of 32 bits, and IPv6
requires blocks of 64 bits. Padding is used to fill any spaces to reach the appropriate block size.
The AH process runs on the entire packet, with the exception of fields in layer 3 that are
designed to change. For example, the Time to Live (TTL) field is designed to decrement as the
packet goes from one network to the next.
AH takes the output from the process, encrypts it, and then truncates it so the result will fit
in the Authentication Data field. When the packet arrives at the other end of the tunnel, the
device performs the same calculation on the packet it received and compares the output it got
with the one that was sent by the originator. If they match, the data is authenticated.
The IP address is a field that is not designed to be changed. However, many network implementations use network address translation (NAT), which changes
the IP address. Creating a tunnel that uses AH across a device using NAT will
result in a broken tunnel.
Encapsulating Security Payload
ESP, defined in RFC 2406, can provide for data integrity and authentication, but its primary
purpose is to encrypt the data crossing the tunnel. When using the hash to provide for authentication and integrity, ESP does not protect as much of the packet as AH does, but this can be
a benefit in some situations.
There are two reasons why ESP is the preferred building block of IPSec tunnels:
The authentication component of ESP does not include any layer 3 information. This
means that it can work in conjunction with a network using NAT.
On Cisco devices, ESP supports encryption using DES or 3DES.
Figure 7.3 shows the ESP header and its placement in the packet, depending on whether IPSec
is configured in Transport mode or Tunnel mode. These modes are discussed in detail in the
next section.
306
Chapter 7
FIGURE 7.3
Introduction to Virtual Private Networks
The ESP header and packet
Security parameter index — 32 bits
Sequence number — 32 bits
Payload data — variable length
Padding — 0–255 bytes
Pad length Next header
Authentication data — variable length
Transport mode
IP header
ESP header
Data
ESP trailer
ESP auth
Tunnel mode
New IP header
ESP header
IP header
Data
ESP trailer
ESP auth
Because ESP offers both authentication and encryption, it is possible to do both without
needing to use AH. When using both ESP and AH, it is important to remember that encryption
comes first. Everything from layer 4 through the end of the data is encrypted. Once the packet
has been encrypted, the authentication process is applied.
In addition to the ESP header, which sits right after the layer 3 information, ESP also has a
trailer for encryption and a trailer for authentication. There are two 32-bit fields within the ESP
header: The Security Parameter Index (SPI) and Sequence Number fields. These work in the
same way as they do in the AH header (described in the previous section). The ESP trailer contains three fields:
Pad Length This 8-bit field indicates how many bytes have been used for padding for
encryption.
Next Header This 8-bit field identifies the type of data found in the Payload Data field.
Padding This field indicates how much padding has been used to get the encrypted packet to
a fixed size. The size used depends on the encryption protocol, but it can be up to a block size
of 2,040 bits.
The ESP authentication trailer contains a single field: the ESP Authentication field. This is
where the authentication information is stored. Its size depends on the hashing algorithm.
Introducing IPSec
307
Tunnel Mode and Transport Mode
An IPSec tunnel can be in either of two modes: Tunnel mode or Transport mode. Most of the
IPSec sessions that Cisco devices deal with are using Tunnel mode. Figure 7.4 illustrates the difference between these modes.
FIGURE 7.4
Tunnel mode versus Transport mode
Tunnel mode
Transport mode
A Transport-mode tunnel encrypts from the device that originally created the packet all the
way to the device that is receiving the packet. At no time does the packet leave the IPSec tunnel.
If users wish to protect their e-mail as they send it to the server, they can encrypt it on their end,
and the server will decrypt it. The message is protected from one end all the way to the other.
Transport mode might be used if an administrator wanted to be able to administer the router
from home via a VPN tunnel, for example.
If the IPSec tunnel does not protect the packet from end to end, then it is a Tunnel-mode tunnel.
For example, if a company’s headquarters has a router and the company’s remote site has a router,
there could be a Tunnel-mode tunnel between them. When users at the remote site check their email, the traffic goes across the tunnel, but it is not protected from end (user) to end (server).
The VPN concept deals with Tunnel-mode tunnels. A virtual network is created that spans
some other network. A Tunnel-mode tunnel actually takes the packet and places it inside another
packet. You end up with two IP addresses: one for the tunnel endpoint and one for the origination.
In the example shown in Figure 7.5, a packet with an IP header and payload is depicted at the
top. If the packet needs to cross a Transport-mode tunnel, the AH process will run on the packet,
and the AH header will be inserted. A Transport-mode tunnel does nothing to the IP header.
If the packet needs to cross a Tunnel-mode tunnel, the IPSec device takes the original packet
and places it inside a new packet. The old IP address is now considered to be part of the data
field. The new packet has a source IP address of the interface at one end of the tunnel and a destination IP address of the interface at the other end of the tunnel. ESP will work in the same way,
except that if both encryption and authentication are used, encryption happens first.
Hashing
Hashing is used to verify that data hasn’t changed or to hide data crossing the network. For example,
Challenge Handshake Authentication Protocol (CHAP) uses hashing to disguise passwords. In the
world of VPNs, hashing is used to verify that there haven’t been any changes to data.
308
Chapter 7
FIGURE 7.5
Introduction to Virtual Private Networks
AH in Tunnel mode and in Transport mode
IP header
Data
Transport mode
IP header
AH
Data
Authenticated except for
mutable fields in IP header
Tunnel mode
New IP header
AH
IP header
Data
Authenticated except for
mutable fields in new IP header
The process of hashing an authentication is often referred to as a Hashed Message Authentication Code (HMAC).
A hash is a simple thing to create. For example, suppose that you want to send the number
12,345 across the network and use hashing to make sure there were no changes to this transmission. If the chosen algorithm said to multiply the data by 56,789, invert the result, and chop
off all but the first four characters, here is what would happen:
Multiply
12,345 × 56,789 = 701,060,205
Invert
701,060,205 = 502,060,107
Truncate
502,060,107 = 5,020
When sending the number 12,345, the value 5,020 would also be included. To make sure
that the data had not changed, the device on the other end of the tunnel would perform the same
computation on the value 12,345. Once it came up with its own four-digit hash, it would compare the hashes. If they matched, the data had not changed.
A typical hash will combine encryption and truncation or padding to get to a fixed-size authentication value. Cisco devices make good use of Message Digest 5 (MD5) which is 128-bit as well
as the Secure Hash Algorithm (SHA) at 160-bit, for hashing. These techniques perform the requisite encryption, and then truncate or pad the message to 96 bits. Because of this, it is nearly
impossible to regenerate the original value that was used to create the hash if it is not already
known. The value 5,020 could have originally been 50,201, or it could have been 5,020,983,478.
Part of the negotiation of IPSec to set up the tunnel is the negotiation of various keys. The
key used here is a shared secret, which will be explained in more detail in the “Diffie-Hellman
Key Exchange” section, coming up shortly.
Introducing IPSec
309
Encryption
Encryption is commonly associated with VPN tunnels, but encryption is not a required component. Encryption involves a message, a key, and a way of combining the two.
One type of encryption will take a message and a key and lightly stir the two together;
whereas a stronger encryption would be like putting the message and key in a blender completely mixing the two. The result is a string of seemingly random characters that can be
reversed at the other end into its clear-text form.
The tunnel endpoints must use the same type of encryption, which is verified before the tunnel comes up and data can be sent. If a message were encrypted in one form but the other side
tried to decrypt it in another form, the output would be undecipherable.
Cisco devices currently support DES and 3DES. DES uses 56-bit encryption, and so does
3DES, but 3DES uses it three times. Where DES negotiates a key, 3DES will negotiate a key,
and then break it up into three parts. The first part is 56-bit encryption, the second process
is to decrypt the message with the second key, and then the third part is used to encrypt
again. Because the first and second keys are not identical, the second process is just another
way of doing 56-bit encryption. 3DES yields encryption that is about twice as strong as regular DES.
The U.S. government has approved a new standard called Advanced Encryption Standard (AES) based on an algorithm called Rijndael. Cisco has indicated
support for AES and has started integrating it into some products, such as the
Content Accelerator.
Diffie-Hellman Key Exchange
The Diffie-Hellman (DH) key exchange protocol, defined in RFC 2631, was created by Whitfield
Diffie and Marten Hellman in 1976. The encryption protocol was designed to allow two peers to
exchange a secret key without having any prior secrets and is an example of how two pairs can use
different public keys to create a singe private key. This key exchange is used to create something
called a shared secret. A shared secret is made when two networking devices create a key and then
share part of it with the peer.
The first task is for each network device to create a key pair. One mathematical expression
is generated and from it, two keys are formed: a private key and a public key, as shown below.
Bob’s
private
key
Bob’s
public
key
Alice’s
public
key
Alice’s
private
key
310
Chapter 7
Introduction to Virtual Private Networks
The private key is never shared with any other device, but it is linked mathematically with
the public key. Each network device will send its public key to its peer:
Bob’s
private
key
Alice’s
public
key
Bob’s
public
key
Alice’s
private
key
This results in each device having a copy of its private key, its public key, and the peer
device’s public key. Nothing more will be done with its own public key, but the other two keys
are very important. Each device will mathematically combine its own private key with the peer
device’s public key. This process results in the shared secret:
Bob’s
private
key
Alice’s
public
key
Shared
secret
Bob’s
public
key
Alice’s
private
key
Shared
secret
Because the keys are all linked together, each side ends up with the same key. Encrypting and
decrypting data using the same key is called symmetric key encryption. (The other form is asymmetric key encryption, which will encrypt using one key and decrypt using a different but mathematically related key.)
Diffie-Hellman is used to protect the IPSec tunnel setup process. The Diffie-Hellman tunnel
is used to encrypt the IPSec negotiations that are required before the tunnel can come up. The
Diffie-Hellman tunnel will not be used to encrypt conventional traffic—for that, you need the
IPSec tunnel.
There are several strengths of Diffie-Hellman available, but most Cisco devices support only
the two weakest types, called Group 1 and Group 2. Group 1 is 768-bit encryption; Group 2
is 1,024-bit encryption.
With the approval of the new AES encryption standard, the IETF is working on
increasing Diffie-Hellman up to 8,192 bits.
Introducing IPSec
311
Internet Key Exchange
The Internet Key Exchange (IKE) works hand in hand with IPSec and is defined in RFC 2409.
IPSec sets up the tunnel for the traffic to cross in a protected fashion. IKE handles all of the
administration and gets everything ready so that the IPSec tunnel can form. If there is no connection with IKE, IPSec has no chance of forming a tunnel.
IKE goes through two distinct processes when establishing an IPSec VPN tunnel. During
Phase 1 IKE is tasked with the authentication of the IPSec peers, and will negotiate an IKE
security association between those peers on its way to initiating a secure tunnel using the
Internet Security Association and Key Management Protocol (ISAKMP). Phase 2 of the IKE
process the peers use the tunnel established in Phase 1 to negotiate the specified security
parameters for the tunnel. Once negotiated, these parameters stay in place; the tunnel is
either terminated by expiration of the SA lifetime or torn down manually.
IKE is implemented on Cisco devices using transform sets. Configuration
details and default settings are detailed under the “Transform Sets” heading
below.
Just as a foundation must be laid before a house can be built, an IKE tunnel must exist before
IPSec information can be exchanged.
The term IKE is used synonymously with ISAKMP. Throughout this book, the
terms are used interchangeably.
IKE is configured manually on network devices and has several components that must match
on both sides of the potential tunnel. Authentication is required to ensure that each device is
talking to the correct peer. Cisco devices that support IPSec will support two or three methods
of authentication: preshared keys, RSA signatures, or RSA encrypted nonces. In larger networks, a certificate authority (CA) is going to be the most efficient method for authentication
due to the less cumbersome configuration and easier management.
In addition to determining how the devices will authenticate, the devices also need to be configured with a peer identifier. Acceptable methods of identifying a peer are via IP address and
via a fully qualified domain name. Whichever method is chosen will apply to the router or firewall as a whole. You may not point to one peer via IP address and another via domain name.
Preshared Keys
A preshared key can be manually configured on each network device. When using preshared
keys, it is vitally important that the two peers be given the same key. When the process starts,
device A will send a packet to device B. This packet includes, among other things, a keyed hash
and the data that made the hash. Device B will create a hash using its key and the data that was
sent by device A. If the hashes match, then the two devices are using the same key and have
authenticated.
312
Chapter 7
Introduction to Virtual Private Networks
Because preshared keys must be manually entered, this method of authentication is not recommended for systems with many devices. However, this is a simple way of establishing authentication and works well when only a few devices are involved.
RSA Signatures
An RSA signature can be used if the devices have access to a CA. RSA signatures are keys that are
generated on network devices and are used to authenticate the peer device. RSA signatures are the
primary component when two network devices need to create a shared secret key (as explained in
the “Diffie-Hellman Key Exchange” section earlier in this chapter). The peers will use a public key
and a private key to accomplish this, and they often use a CA to exchange keys.
Each device will register with the CA and get a device-specific identity certificate. When
attempting to authenticate, the devices will exchange certificates.
CAs are discussed in more detail in the “Certificate Authorities” section, after
the discussion of RSA encrypted nonces.
The authentication is actually the process of being able to understand the certificate that was
received. This method is not efficient if there are only a few devices involved, but it can save
quite a bit of time if there are many devices using IPSec tunnels.
RSA is a term that occurs frequently in encryption and security white papers
and manuals. It stands for Rivest, Shamir, and Adleman, three doctors who
invented the RSA Public Key Cryptosystem.
RSA-Encrypted Nonces
The RSA-encrypted nonce method employs everything that is not desirable in the preshared key
and RSA signature methods. It is manually configured on each device, so it increases the potential for making mistakes when entering data. Also, it depends on generated keys, so there is a
risk that the keys will be compromised.
RSA-encrypted nonces start in the same way that RSA signatures do: Each network device
must generate a large number, which gets split into public and private keys. The public key must
be copied over to the peer device, where the nonce is encrypted in it. When the IPSec session needs
to start and IKE needs to be authenticated, the devices exchange nonces. At this point, each side
generates a shared secret in the same fashion that Diffie-Hellman key exchange operates.
RSA-encrypted nonces do have one advantage: They provide for a deniable transaction. A
preshared key transaction can happen with only the peer that has the key. Since you have the
IP address and the key, it’s easy to prove. RSA signatures are difficult to deny because a trusted
third party, the CA, maintains records of certificate serial numbers and can identify the device
that registered. RSA-encrypted nonces have neither of these ways of proving the identity of the
other device. After all, it is not hard to spoof an address or hijack an IP address. If deniability
is required, go with encrypted nonces.
Introducing IPSec
313
Certificate Authorities
A CA is a trusted, third-party device that may or may not be under your administrative control.
CAs are used to simplify administration of a large number of IPSec devices. Each device needs
to register with the CA rather than have a separate configuration for every peer it might wish
to create a tunnel with. A CA is normally not recommended for small networks because of the
initial cost in money and time to set one up.
It doesn’t take long to set up four routers to do authentication via preshared keys for each
of the other three routers in the group; it is a total of 12 keys. Expand the model from four routers to 400, and then add a new router. Not only will someone need to configure the new router
for 400 preshared keys—one for each of the existing routers—but someone will need to log in
to every one of the existing routers to add a single new key. Adding 800 keys will take quite a
while, and troubleshooting the typos will take even longer. With a CA, you can avoid all this
by simply registering the new router with the CA.
To enroll to a CA, a device needs to generate an RSA key. As explained earlier, part of the
RSA key is a public key and part of it is a private key. During the certificate-enrollment procedure, the network device gets a copy of the CA’s public key. The network device also sends its
public key to the CA. The CA encrypts the client’s public key in a certificate and sends it to the
enrolling client.
When two devices wish to form a tunnel and are authenticating via certificates, they need to
exchange the certificates. Because the certificates are nothing more than an encrypted packet,
the peers must have the necessary information to decrypt them. Since they were encrypted using the
CA’s private key, a device needs the same CA’s public key to decrypt the certificate. Once
the certificate is decrypted, device A has a copy of device B’s public key and vice versa.
It doesn’t matter which CA you use; there are several available to serve your needs. All CA
applications that want to be compatible follow the format specified in the X.509 standards. The
CA application gaining the most widespread usage is the one that Microsoft includes with Windows 2000 Server. There is no extra cost to use the CA supplied with Windows 2000, unlike
other CA applications.
Chapter 9 provides details on requesting and installing digital certificates for
use with CAs.
Transform Sets
To build the IPSec tunnel, you need to tell the network device how to use AH and/or ESP. A
transform is an option that describes how to build the tunnel. For example, a transform may tell
a router to use ESP with DES encryption, tell a firewall to use AH with MD5 hashing, or it may
say to use several items.
An IPSec blueprint, or transform set, can have up to three instructions in it: one AH transform and two ESP transforms (one for encryption and one for authentication). However, if
314
Chapter 7
Introduction to Virtual Private Networks
more are needed, you can configure multiple transform sets within a given device’s crypto policy
to identify combinations. Figure 7.6 illustrates the options for transform sets.
FIGURE 7.6
Transform set options
Standard
IPSec
Protocol
AH
Encryption/Hash
HMAC-MD5
or HMAC-SHA
Transport type
Tunnel or
transport
ESP
DES
or 3DES
HMAC-MD5
or HMAC-SHA
Tunnel or
transport
Part of the configuration is also telling the network device if the IPSec tunnel will use Tunnel
mode or Transport mode. The default on the Cisco router is for Tunnel mode.
Other types of transforms are available for odd purposes. For example, the ahnull transform is used to create a tunnel without authentication or encryption.
Building a transform set for an IKE tunnel on a Cisco device requires setting up five parameters for IKE Phase 1 and three for IKE Phase 2.
The five parameters and their default settings for the VPN 3000 Concentrator Series are
shown in Table. 7.1:
TABLE 7.1
IKE Phase 1 parameters
Setting
Default
Option
Encryption algorithm
56-bit DES
168-bit 3DES
Hash algorithm
MD5
SHA-1
*Shorter lifetime settings are an option and more secure but will cause futher use of processing cycles.
Introducing IPSec
TABLE 7.1
315
IKE Phase 1 parameters (continued)
Setting
Default
Option
Authentication
method
RSA digital signatures
Preshared keys, RSA encrypted nonces
Key exchange method 768-bit Diffie-Hellman Group 1 1,024-bit Diffie-Hellman Group 2
IKE SA lifetime
86,400 seconds (1 day)
Variable*
*Shorter lifetime settings are an option and more secure but will cause futher use of processing cycles.
The parameters set for IKE Phase 1 must match the opposite end of the tunnel
exactly or the tunnel will not establish the connection.
Once the IKE Phase 1 configuration is complete, the only IKE Phase 2 configuration requirements to establish the tunnel are shown in Table 7.2:
TABLE 7.2
IKE Phase 2 parameters
Setting
Option
IPSec protocol
AH or ESP
Hash algorithm
MD5 or SHA-1
Encryption algorithm (ESP only)
DES or 3DES
IPSec Security Associations
An IPSec Security Association (SA) contains the instructions on how to build a tunnel to a given
destination. When two peers decide that they will use ESP-DES and AH-MD5 for the IPSec tunnel, this information is stored somewhere along with items such as the SA lifetime and appropriate keys. All of the properties of the blocks used to build an IPSec tunnel are placed in this
database. The SA tells the router the recipe to use when sending traffic through the tunnel to a
given destination.
An IPSec SA will have several components:
The peer IP address (the IP address of the other end of the IPSec tunnel)
The Security Parameter Index (SPI), which is a pointer used to identify the characteristics
of a tunnel
316
Chapter 7
Introduction to Virtual Private Networks
The transform set used to build the IPSec tunnel
Keys used to hash or encrypt the traffic that crosses the tunnel
Optional attributes, such as the tunnel lifetime
Each tunnel will have at least one SA associated with it. An IKE SA is bidirectional; the referenced properties apply in both directions. IPSec tunnels are unidirectional; they apply on a
one-way basis only. Since the peers must negotiate and have identical ways of setting up the tunnel, the question, “Why are they unidirectional?” is often raised. The answer is that the router
needs to be able to invert the ACL for incoming traffic.
When the ACL is created, it applies to outgoing traffic, which is associated with the outgoing
SA. To make sure that traffic coming in is protected in the way it should be, the router makes
a mirror image of the ACL and associates it with incoming traffic for the incoming SA.
Each network device is responsible for setting up its outgoing SA. When router A receives
traffic that wants to be encrypted, it sends the SA policy information to router B. This becomes
router B’s incoming SA. Router B will compile all the information it needs to determine appropriate characteristics for its outgoing SA and send that to router A. The numbers identifying a
particular SA (the SPI) will be identical on both sides of the tunnel.
Figure 7.7 shows that there are two separate connections, based on the connection IDs in use
(conn id). The SPIs are unique on a per-SA basis; each side uses the same SPI when referring
to the same SA. Because there are two different SAs, there are two different SPIs. The other
information must match across both SAs and on both sides.
FIGURE 7.7
IPSec Security Associations (SAs)
Host A
Host B
192.168.4.78
192.168.4.56
10.0.1.14
10.0.2.57
10.0.1.1
10.0.2.1
Router A
Router B
1. Host A sends interesting traffic to Host B.
2. Routers A and B negotiate an IKE phase 1 session.
IKE SA
IKE Phase 1
IKE SA
3. Routers A and B negotiate an IKE phase 2 session.
IPSec SA
IKE Phase 2
IPSec SA
4. Information is exchanged via IPSec tunnel.
How IPSec Works
317
The crypto map: mymap shown in Figure 7.7 defines the crypto map used for
IPSec configuration. The crypto map name (such as mymap in this example) does
not need to match between the peers; it is a locally significant value. Chapter 9
provides more information about crypto maps for IPSec configuration.
IPSec SAs are traditionally negotiated through IKE (discussed in the next section). It is possible to create an SA manually, but doing so is not advisable for most environments, because it
can require additional record keeping and increase the possibility of errors.
How IPSec Works
In the previous section, we introduced you to the IKE, and explained that it must exist before
IPSec can be set up. But before IKE or IPSec can perform their tasks, there must be some traffic
that needs to cross the tunnel. This traffic is the entire purpose for setting up these tunnels in the
first place and is defined as interesting traffic. Once that occurs, the router can communicate
with the tunnel peer to set up the tunnel. IKE tasks are broken into two phases: The first is setting up the IKE tunnel, and the second does quite a bit of setup for IPSec. In the coming sections
we will look at the logical process of how a tunnel is setup, starting with how we define the
interesting traffic that requires the tunnel to be setup. Next we will examine the next steps as
we look at both Phase 1 and Phase 2 of IKE. Finally, we will look at the different decisions that
need to be made as the tunnel is being used for various tasks.
Defining Interesting Traffic
Interesting traffic is simply the packets that need to be transported to the opposite side of the
tunnel. Without interesting traffic, there is nothing to trigger the tunnel creation. The tunnel
must have a reason to exist, and traffic that wants to cross is that reason.
In the network pictured in Figure 7.8, routers A and B are configured to create a tunnel if
traffic wants to go from the network that host A resides on to the network that host B resides
on. To do this, an access control list (ACL) needs to be configured.
The ACL will not be applied directly to an interface; instead, it is used to determine which
traffic is able to use the tunnel. When building an ACL to determine which traffic will cross, use
permit statements to permit traffic to use the tunnel and deny statements to prevent the traffic
from using the tunnel. Traffic that is denied will not be protected by the tunnel. However, the
traffic will not be blocked from leaving the router.
Consider the following access-list statement:
access-list 101 permit ip 10.0.1.0 0.0.0.255 10.0.2.0 0.0.0.255
This ACL will permit traffic originating from the 10.0.1.0 network to cross the tunnel if it
is heading to a device on the 10.0.2.0 network. Since there are no other statements, all other
318
Chapter 7
Introduction to Virtual Private Networks
traffic is denied by the “implicit deny all” rule. The denied traffic can still access the network;
it just won’t cross in the tunnel.
When an interesting packet arrives, the ACL determines if it should go across the tunnel. If
so, the router determines what should be done and inserts the SPI (from the SA, as discussed in
the “IPSec Security Associations” section earlier in the chapter) into the IPSec header. When the
packet arrives at the destination peer, the device looks up the IPSec information based on the
SPI in the packet.
FIGURE 7.8
Interesting traffic triggers tunnel creation.
Host A
Host B
192.168.4.78
192.168.4.56
10.0.1.14
10.0.2.57
10.0.1.1
10.0.2.1
Router A
Router B
access-list 101 permit ip 10.0.1.0 0.0.0.255 10.0.2.0 0.0.0.255
IKE Phase 1
Once the router has received the interesting traffic and determined that the traffic needs to cross
the tunnel, the router buffers the packet and starts the process to bring up the IPSec tunnel.
It is not unusual to create an ACL that uses pings for interesting traffic. Ping the
far side, and watch three to five pings fail. If this happens, test it by pinging
again.
To bring up the tunnel, the two ends must negotiate what the IKE settings are supposed to
be. The following items need to be negotiated:
IKE SA
Encryption
Hash method
Authentication method
Diffie-Hellman group
Tunnel lifetime
How IPSec Works
319
Each of these items must match on both sides of the tunnel, with the exception of the tunnel
lifetime. A tunnel will not form if one side is using MD5 hashing and the other side is using SHA,
or if one side is using Diffie-Hellman Group 1 and the other side is using Group 2. However,
the tunnel lifetime values are not required to match. This setting will default to the shortest time
value of the tunnel pair. For example, if one side leaves the lifetime at the default of one day and
the other changes it to half a day, the tunnel will form, and it will expire in half a day.
Each Cisco network device has a default policy that is used for IKE phase one negotiations.
This means that an administrator needs to make only the desired changes in the configuration.
All other settings will use the defaults. For example, if you need to change only the default setting of using a CA for authentication, just change that to preshared keys in the profile. The rest
of the profile settings will use the built-in defaults. Therefore, it is recommended that default settings be used for the initial configuration, leaving the custom requirements for the tunnels until
after any necessary troubleshooting during initial setup.
IKE phase 1 has two different methods of communicating: Main mode and Aggressive mode.
Main Mode Communication
Main mode has three two-way exchanges between the peers:
In the first exchange, the devices agree on the algorithms and hashing that will be used.
The second exchange implements Diffie-Hellman to generate the shared secret key information and pass it back and forth.
The third exchange involves verifying the identity of the peer device. This process is protected by the Diffie-Hellman tunnel created in the second step.
Once everything is set up, there is an SA that defines the tunnel. As explained in the “IPSec
Security Associations” section earlier in the chapter, an SA is nothing more than a pointer to a
database entry that defines how the IKE tunnel is formed. The appropriate information includes
the hash method used, Diffie-Hellman information, how long the tunnel will stay up, and so on.
It is important to remember that the IKE SA is bidirectional. The information the SA provides
applies to both incoming and outgoing traffic.
Aggressive Mode Communication
Aggressive mode is great for reducing the latency involved with setting up the IKE tunnel, since
only half of the communication is used. The downside is that there is not enough communication to protect the identity information when it is being passed, because it is sent along with the
Diffie-Hellman information.
The following Aggressive-mode steps are one-way communications:
Router A will send all of the information it can to router B. This includes policy information
such as the hash type and Diffie-Hellman group, the Diffie-Hellman public key information, and device identity information.
Router B sends back a similar packet, essentially saying what is being used so that router
A knows that the tunnel is valid.
Router A acknowledges receipt of the packet that router B sent.
320
Chapter 7
Introduction to Virtual Private Networks
It is possible for someone to sniff the wire while an Aggressive-mode transaction occurs and find out
the identity information, since it is not protected the way that a Main-mode transaction is protected.
IKE Phase 2
The purpose for the second phase of IKE is to negotiate the IPSec tunnel parameters. The negotiations for this are protected by the IKE tunnel created in Phase 1. Most of the items the two
peers are negotiating are the items configured in the transform sets. If the transform sets do not
match, a tunnel will not be set up.
Phase 2 negotiation is also responsible for renegotiating the tunnel when the tunnel lifetime
expires. There are two ways to do this: fully renegotiate the keys or partially renegotiate the
keys. When the keys are only partially regenerated, it saves computational power because not
as much is being redone. It also isn’t quite as secure. If the desire is for the keys to be regenerated
fully and have a new Diffie-Hellman tunnel to protect the negotiation, you need to ensure that
you are using Perfect Forward Secrecy (PFS).
PFS is a switch that tells the VPN device to go through the entire process of generating keys when the IPSec tunnel is about to expire. If PFS is not used, part of
the old key may be reused and if the IKE tunnel is still up, it also may be reused.
If PFS is enabled, the old IKE tunnel is torn down and rebuilt, and a totally new
IPSec key is generated.
Once the IPSec tunnel has come up, packets will move along it in both directions. ACLs are
used to determine not only which packets need to exit through the tunnel, but also which packets should be arriving via the tunnel.
In the previous example, packets that originated on the 10.0.1.0 network and destined for the
10.0.2.0 network were to be encrypted. If the router received a packet from a 10.0.2.0 course
heading for a 10.0.1.0 destination and the packet was not encrypted, the router would know there
was something wrong and would discard the packet. ACLs determine which packets should be
encrypted as they leave and which packets should be decrypted as they arrive.
The IPSec tunnel will stay up for a certain duration. The choices for tunnel duration are a finite
time limit in seconds or a number of kilobytes of traffic. The IPSec tunnel will collapse once the
timeout has been exceeded. More recent versions of code, such as IOS 12.1 and PIX software 6.0,
allow for both ways to be used. For example, a router can be configured to have an IPSec tunnel
that will expire in 12 hours or after 1GB of data has passed through it, whichever comes first.
The peers will automatically renegotiate the tunnel 30 seconds or 256KB before the tunnel
would expire. On a high-bandwidth link, the tunnel might expire in the middle of negotiations
for a new tunnel, leaving a small gap in communications.
IPSec Task Flow
As traffic arrives and leaves, as traffic is encrypted and decrypted, decisions need to be made.
Now that we’ve looked at the phases of IPSec tunnel creation, let’s examine how the decisions
are made in the process. Figure 7.9 shows a flowchart of the decision-making process.
How IPSec Works
321
Let’s review each of the decisions in the process:
Does the traffic need to be encrypted? The IOS on the router needs to determine what it can do
with traffic that arrives. The router will compare the packet to the ACL and determine if the traffic
should be encrypted. If the ACL denies the packet, the traffic is forwarded out the interface. If the
ACL permits the packet, the traffic goes through the tunnel before leaving the interface.
Does the IPSec SA need to be negotiated? Before the traffic enters the tunnel, the router needs
to make sure that the tunnel is up. If the IPSec tunnel already exists, the appropriate manipulations performed on the packet before it goes on its way. If the tunnel is not up, the router needs
to do some more work.
Does the IKE SA need to be negotiated? The IPSec and IKE tunnels are two distinct entities. If
the IPSec tunnel drops, it doesn’t mean the IKE tunnel has dropped as well. If the IPSec tunnel
is down, the characteristics need to be negotiated for it to come up. This cannot happen if the
IKE tunnel is down. If both the IPSec tunnel and the IKE tunnel are down, the IKE tunnel needs
to be negotiated to protect the negotiations that go on to bring up the IPSec tunnel.
Does the traffic need to be authenticated with CA? A decision needs to be made to use either
a CA or preshared keys. If a CA is used, the configuration, key creation, and certificate enrollment will all take place before the IKE tunnel negotiation can begin.
FIGURE 7.9
IPSec decision-making flow
IOS
Select traffic with access-lists
Encrypt?
Transmit out interface
N
Y
IPSec
Once per IPSec SA
(between source and destination)
IPSec
SA?
Y
N
Encrypt packet and transmit
Keys
with access-lists
IKE
Once per IKE SA
(between two peers)
IKE
SA?
Y
Negotiate IPSec
SA over IKE SA
N
Negotiate IKE SA
with other peer
N
CA authentication
Once per private/public key pair
Authenticate
with CA?
Y
Create own public/private keys
Get CA’s public keys
Get certificate for own public key
322
Chapter 7
Introduction to Virtual Private Networks
IPSec Troubleshooting
IPSec is often a good choice for VPNs, but you must be aware of how changes will affect your
network. Traffic that is crossing the network through an IPSec tunnel is still IP traffic. This
means that you need to deal with standard IP issues when passing traffic through the tunnels.
The issues you might need to troubleshoot include traffic delay, filtering, NAT, and ACLs.
In the following sections, we will look at some of the more common problems associated
with IPSec VPNs, including such issues as working with NAT and filtering, and we will offer
some suggestions for isolating trouble spots.
Traffic Delay Problems
There is a certain amount of delay associated with IP traffic. How much delay depends on several factors. There is propagation delay of about one microsecond per kilometer that the packet
needs to travel. Packet travel isn’t necessarily “as the crow flies” either. Do a traceroute to
your destination to see the path being used.
Interfaces also have a delay associated with them. The slower the interface, the more time it
takes to place the packet on the network. It also takes time to do the computations and processing to place a packet into the IPSec tunnel. Tests with three 2600-series routers connected
via 10Mbps Ethernet showed about a 7-millisecond delay to place a ping packet into the IPSec
tunnel using only DES encryption.
Encrypting Voice over IP (VoIP) traffic can be unnoticeable, or it can cause enough jitter
(delay-triggered jerkiness) to make using VoIP connections undesirable. Test such applications
as much as possible before implementing them on a wide-scale basis.
Filtering Problems
If the packets can leave the network device but never reach the far side, it is possible that there
is some filtering occurring somewhere in the network. If an intermediate router is filtering UDP
port 500, then the IKE session will not complete. If the IPSec tunnel comes up but the intermediate router is filtering protocols 51 or 50, then packets with AH or ESP headers will be filtered.
The key to detecting filtering is to debug the setup of both IKE and IPSec and see how far the
tasks complete. If the IPSec tunnel comes up, try to ping the far device without encryption. Then
try to ping it with the ping configured as interesting traffic.
With high-speed cable Internet connections growing, filtering is becoming
more common. At least one cable provider is filtering IPSec packets generated
by subscribers of their low-end residential service to force them to upgrade to
the more expensive business package.
Exam Essentials
323
NAT Problems
Detecting a problem caused by NAT isn’t surefire, but it is fairly easy. The main thing to look
for is errors on encapsulated packets. If the packets are arriving and being discarded, and the
device is configured to use AH, this is a good indication of NAT problems. An appropriate test
would be to create a second tunnel from the same two devices using only ESP, and then ping the
far end across the tunnel.
ACL Problems
When an ACL is created on a router, the router uses that list to determine which traffic is privileged, or interesting, enough to cross the tunnel. The router will also exchange the source and destination information when examining incoming traffic to see what should have come in via the
tunnel. If a packet should have come through the IPSec tunnel but did not, the router will drop it.
It is very important that the ACLs on the peer devices are mirror images of each other. If
router A permits traffic from 10.1.2.3 to destination 99.5.6.7, then router B should have a line
permitting 99.5.6.7 to 10.1.2.3.
Summary
This chapter serves as an introduction to the rest of the chapters dealing with VPNs. First, you
learned about the major types of VPNs and the Cisco VPN devices.
The rest of the chapter dealt with IPSec and Internet Key Exchange (IKE). You learned that
IKE is the base; IPSec couldn’t exist without an IKE foundation. Authentication is a critical
component of IKE and one of the options supported is the certificate authority (CA).
As you learned, IPSec is largely a self-negotiating process. While IKE tunnels can be manipulated in many ways, IPSec configurations usually specify the broad building blocks that will be
used and let the two network devices negotiate the details. IPSec’s Authentication Header (AH)
and Encapsulating Security Payload (EPS) protocols are used to build tunnels. IPSec can use
encryption (DES or 3DES) and hashing techniques (MD5 or SHA) to enhance security. Transform sets define a device’s IPSec requirements. Actual tunnel creation is triggered by traffic that
needs to use a tunnel, as defined by ACLs.
This is an excellent chapter to refer back to as you head further into this section of the book.
The remaining chapters in this part will provide product-specific configuration information.
Exam Essentials
Understand the relationship between IKE and IPSec. For VPN tunneling, two tunnels need to
be set up. IKE is used to provide for authentication between the two devices, and it sets up the
first tunnel. This tunnel then protects the information the devices exchange to bring up the IPSec
324
Chapter 7
Introduction to Virtual Private Networks
tunnel. Also, remember that the IKE tunnel is bidirectional, and there are actually two unidirectional tunnels used in IPSec.
Know what AH and ESP can do. AH and ESP are the two protocols that make up IPSec tunnels. Each can provide building blocks in the form of transforms, and the individual transforms
are responsible for building the tunnel. AH provides only for authentication. ESP transforms
can provide for authentication and/or encryption.
Remember the IPSec order of events. When two devices are configured for IPSec, a tunnel
isn’t created spontaneously. Some sort of traffic needs to arrive at one of the routers to start the
whole process. Interesting traffic arrives at a router, and that device starts an IKE session with
its peer. If IKE resolves, IPSec negotiations can begin, and if they are successful, the interesting
traffic can cross the tunnel.
Understand hashing. Hashing is used in authentication to ensure the data being sent across
the wire hasn’t been changed. The data is sent in clear text, but sent along with it is an identifying code. When certain processes are run on the plain-text data, the result will be a code. If
the two codes match, the receiving device knows that the data hasn’t been changed.
Key Terms
Before you take the exam, be certain you are familiar with the following terms:
3DES
Hashing
access VPN
Internet Key Exchange (IKE)
Anti-replay
intranet VPN
Authentication Header (AH)
IPSec
CA
ISAKMP
Cisco Encryption Technology (CET)
preshared key
Data confidentiality
RSA signature
Data integrity
Security Association (SA)
Data-origin authentication
shared secret
DES
transform
Diffie-Hellman (DH)
transform set
Encapsulating Security Payload (ESP)
Transport mode
Encryption
tunnel
extranet VPN
Tunnel mode
Hashed Message Authentication Code (HMAC)
VPN
Review Questions
325
Review Questions
1.
How many AH transforms may be used in a transform set?
A. One
B. Two
C. Three
D. Four
E. Five
2.
What are valid modes for IKE to use when establishing a tunnel? (Choose all that apply.)
A. Collect mode
B. Main mode
C. Static mode
D. Express mode
E. Aggressive mode
3.
How long before the IPSec tunnel expires will the peers attempt to renegotiate keys?
A. 30 seconds
B. 60 seconds
C. 90 seconds
D. 120 seconds
E. 300 seconds
4.
Which encryption protocols are supported on Cisco routers in IOS version 12.0? (Choose all
that apply.)
A. Blowfish
B. DES
C. AES
D. 2DES
E. Twofish
F. 3DES
G. Redfish
H. Bluefish
326
5.
Chapter 7
Introduction to Virtual Private Networks
Which IPSec component does not work well when NAT is being done in the middle of the tunnel?
A. AH authentication
B. ESP encryption
C. ESP authentication
D. AH encryption
6.
What level of security is used by Diffie-Hellman Group 1?
A. 384-bit
B. 512-bit
C. 768-bit
D. 1,024-bit
E. 2,048-bit
7.
There are 10 routers in a network and each one has an IPSec tunnel to all of the others. One new
router is added and is configured for preshared keys. How many keys will need to be configured?
A. 10
B. 11
C. 20
D. 21
E. 22
8.
What standard specifies the format for certificates?
A. X.25
B. X.525
C. X.121
D. X.509
9.
If two routers have set up an IPSec tunnel, how many SAs will they each know about?
A. One
B. Two
C. Three
D. Four
E. Five
Review Questions
327
10. How is AH identified?
A. As TCP port 50
B. As TCP port 51
C. As UDP port 50
D. As UDP port 51
E. As protocol 50
F. As protocol 51
11. Which of the following is NOT a component of IPSec , providing authentication, encryption,
and other services?
A. The Authentication Header (AH) and Encapsulating Security Payload (ESP) protocols
B. Hashing
C. RSA Encrypted Nonces
D. Diffie-Hellman Key Exchange
E. IKE
F. IPSec Security Associations (SAs)
12. 12. How many Security Associations (SAs) does it take to establish bidirectional IPSec communications between two peers?
A. One
B. Two
C. Three
D. Four
E. Five
328
Chapter 7
Introduction to Virtual Private Networks
Answers to Review Questions
1.
A. Only one AH transform may be a part of any single IPSec tunnel.
2.
B, E. Main and Aggressive are the two modes available. Main mode takes longer than Aggressive mode but is more secure.
3.
A. When the lifetime is based on time, the peers will attempt to renegotiate 30 seconds before
the tunnel collapses.
4.
B, F. Cisco routers running IOS 12.0 support DES (Data Encryption Standard) and 3DES but
should support Advanced Encryption Standard (AES) soon. Blowfish and Twofish are real protocols. Redfish and Bluefish are from the Dr. Seuss children’s stories.
5.
A. NAT breaks IPSec tunnels using Authentication Header (AH). AH does not provide encryption.
6.
C. Group 1 is 768-bit encryption. Group 2 is 1,024-bit encryption. (384-bit and 512-bit are not
valid group values.)
7.
C. The new router will need to be configured with 10 keys, and each of the existing 10 routers
will need to be configured with one new key.
8.
D. X.509 is the OSI Directory standard for authentication. X.525 deals with replication. X.25
and X.121 deal with wide-area networking.
9.
C. Each router will know about one bidirectional IKE Security Association (SA) and two unidirectional IPSec SAs.
10. F. Authentication Header (AH) uses protocol number 51.
11. C. RSA-Encrypted Nonces are not a component of IPSec.
12. C. There are three SAs required to establish a bidirectional IPSec communication between two peers.
Chapter
8
Introduction to Cisco
VPN Devices
THE FOLLOWING TOPICS ARE COVERED IN
THIS CHAPTER:
Overview of the Cisco VPN 3000 concentrator series
Cisco VPN 3000 concentrator series models
Cisco VPN 3000 concentrator series client support
Configure the Cisco VPN 3002 hardware client for remote
access using preshared keys
Configure the Cisco Windows VPN software client
Overview of the Cisco VPN software client auto-initiation
Configure the Cisco VPN software client auto-initiation
Overview of the VPN 3002 reverse route injection feature
While a router or firewall can be used to terminate a virtual private network (VPN), that is not the best use of either of those
devices’ CPU cycles. If you have VPNs that need to be terminated,
it is better to use a device optimized for VPNs. Cisco has two types of dedicated physical devices
that can terminate VPNs: the VPN concentrator and the VPN hardware client. Cisco also offers
a software client, which is loaded on a computer so that a PC can terminate a VPN tunnel.
This chapter begins with an overview of the Cisco VPN concentrator models devices, including their main features. Next, we’ll discuss the VPN hardware client and how to configure it
using the Quick Configuration utility. Finally, we’ll cover the VPN software clients, including
how to configure them.
Details on configuring and managing VPN concentrators are covered in Chapter 9, “Configuring the VPN Concentrator,” and Chapter 10, “Managing the
VPN Concentrator.”
Introducing the VPN 3000 Concentrators
As VPNs gained popularity, Cisco realized that being able to terminate a VPN on a router was a
good selling point. However, terminating more than a few VPNs on a 2500 series router resulted
in unacceptable performance degradation. Using a router for VPN termination might be acceptable for an office where one or two people at a time would be using a VPN. However, if an office
decided to allow 50 users to telecommute, it often experienced performance problems.
The solution was to develop a hardware device dedicated to terminating VPNs, called a VPN
concentrator. Until 2002, Cisco offered two classes of VPN concentrators: the 3000 series and
the 5000 series. The 3000 series is designed for corporate enterprise use, and the 5000 series is
designed for use by service providers (and handles more connections than the 3000 models).
The two series operate in a similar fashion, but they are not configured the same way. This book
covers only the 3000 series because the 5000 series was announced as an End of Sales (EoS) in
February of 2002. Thus, there will be no further feature development for the Cisco VPN 5000
product line. Enterprise customers using Cisco VPN 5000 series concentrators have been encouraged to move to Cisco 7200 series routers. The CSVPN exam covers only the 3000 series.
Introducing the VPN 3000 Concentrators
331
Cisco’s 3000 VPN concentrator is often still referred to as the Altiga concentrator because Altiga developed it.
In the following sections, we will introduce the VPN 3000 concentrator series models and summarize their features. Chapters 9 and 10 will cover configuring and managing VPN concentrators.
Overview of the VPN 3005 Concentrator
The 3005 model is an entry-level VPN concentrator designed for small to medium offices. This
model is a good choice if your organization is not growing very quickly. For example, if a 500user company has anywhere from 30 to 50 salespeople on the road at any one time and 15 to
20 other off-site employees, this concentrator will handle the job. If the company is expanding
at a rapid pace, however, the 3005 model is not an appropriate choice.
The 3005 can support up to 100 simultaneous tunnels via software-based encryption and is
not upgradeable. Like the other 3000 series models, it offers the option of using 40-bit, 56-bit,
or 128-bit DES, 3DES, or Microsoft Point-to-Point Encryption (MPPE). It can also use MD5
and SHA for hashing and Diffie-Hellman for key exchanges. (Encryption, hashing, and DiffieHellman are covered in Chapter 7, “Introduction to Virtual Private Networks.”)
MPPE is an encrypted form of a PPP packet. For more information about MPPE,
refer to RFC 3078.
The VPN 3005 is a 1U device. A U is a measurement of height for placement in a rack and
is equal to 1.75 inches (4.45 centimeters). For comparison, other 1U devices include the Cisco
2500 and 2600 series routers and the thin Catalyst 1900, 2900, and 3500 series switches.
Table 8.1 summarizes the characteristics of the VPN 3005 concentrator.
TABLE 8.1
Characteristics of the VPN 3005 Concentrator
Feature
Description
Memory
64MB (fixed)
Simultaneous users
Up to 100
Power supply
Single
Height
1U
Encryption throughput
4MB
332
Chapter 8
TABLE 8.1
Introduction to Cisco VPN Devices
Characteristics of the VPN 3005 Concentrator (continued)
Feature
Description
Encryption
Software based
Upgradeability
None
Processor
Motorola PowerPC
Console Port
DB9 Async (9600-N-8-1)
Client License
Unlimited
Figure 8.1 shows the front and back of a 3005. While the front of the 3005 is fairly nondescript, the 3005 comes with two LAN interfaces on the back. One interface is for the outside
connection and is labeled public. The other interface is for the inside connection and is labeled
private. There is a default configuration that comes with each VPN concentrator, so it is important that these interfaces are attached to the correct locations on your network. In addition to
the LAN connections, there is also a DB-9 interface for the console port. A standard RS-232
straight-through serial cable can be used for console access. As will most Cisco devices, a terminal emulation configured for 9600-N-8-1 is the default configuration.
FIGURE 8.1
The VPN 3005 concentrator
Console
Console
Private
Public
Link
Tx
Link
Tx
Col
100
Col
100
Private
Reset
Public
Each of the LAN interfaces supports 10/100 Ethernet. There is no provision for other types
of LAN media (Token Ring, FDDI, or CDDI) at this time. The interfaces also have LEDs to indicate link, collision, transmit, and receive status.
Site-to-site tunnels are more complex than remote access tunnels because they create a tunnel
between two concentrators and encrypt all the traffic that flows between. Because the amount
of traffic is usually higher, the number of site-to-site tunnels that are supported is lower than the
number of remote access (user) tunnels. The 3005 can support 100 site-to-site tunnels.
Introducing the VPN 3000 Concentrators
333
Overview of VPN 3015 through 3080 Concentrators
Models 3015 through 3080 are 2U VPN concentrators that are more flexible than the 3005. If
your organization is growing rapidly or already needs more than 100 tunnels terminated at a
time, these are the models to consider.
The 3015 has the same tunnel capacity as the 3005, but it is upgradeable to add support for
more tunnels. The 3030, 3060, and 3080 models use hardware-based encryption and decryption. Since these tasks are offloaded from the CPU, more tunnels can be terminated by these
devices than by the 3005. All of these models can use 40-bit, 56-bit, or 128-bit DES, 3DES, AES,
or MPPE encryption; MD5 or SHA for hashing; and Diffie-Hellman for key exchanges.
DES/SHA encryption transforms are not supported in newer versions of the
hardware and software clients. This might cause clients to stop working after
an upgrade.
Table 8.2 summarizes the capabilities of the 3015, 3030, 3060, and 3080 models.
TABLE 8.2
Base Characteristics of the VPN 3015, 3030, 3060, and 3080 Concentrators
VPN Concentrator
3015
3030
3060
3080
Simultaneous users
100
1500
5000
10,000
Encryption throughput
4Mbps
50Mbps
100Mbps
100Mbps
Encryption method
Software
Hardware
Hardware
Hardware
Encryption (SEP) modules
0
1
2
4
Available expansion slots
4
3
2
2
Upgradeability
Yes
Yes
N/A
N/A
System memory
128MB
128MB
256MB
256MB
Dual power supply (hot swap)
Optional
Optional
Optional
Default
Processor
Motorola
Motorola
Motorola
Motorola
PowerPC
PowerPC
PowerPC
PowerPC
Figure 8.2 shows the back of a 3015. Just as on the 3005, the console port is a DB-9. The concentrator has both public and private Ethernet ports, as well as a third port, which can be used
334
Chapter 8
Introduction to Cisco VPN Devices
to connect to another LAN segment, such as a DMZ or extranet. The 3015 also has an option
for a redundant power supply and up to four Scalable Encryption Processing (SEP) modules.
The SEP is what does the hardware-based encryption. Overall, the more memory and more
SEPs, the higher the number of tunnels the concentrator can handle. The digital signal processors in the SEP can be reprogrammed as standards change.
FIGURE 8.2
The rear of the VPN 3015 concentrator
100-240V power supplies
load sharing
SEP modules
Console
Reset
Private
Link
Tx
Public
Link
Tx
External
Link
Tx
Col
100
Col
100
Col
100
10/100
Ethernet
Console
Private
Public
External
Like the 3005 concentrator, the 3015 can support 100 site-to-site tunnels. The 3030 can support 500, and the 3060 and 3080 can each support 1,000.
Cisco used to sell T1/E1 modules for VPN 3015 through 3080 concentrator models, and Altiga sold a 3005 that had a T1/E1 port. These devices have been discontinued, and support for them in CiscoView is nonexistent after version 5.3.
Customers using these products should see “Field Remediation Efforts” at
http://www.cisco.com/warp/public/cc/pd/hb/vp3000/prodlit/eoswm_
pb.htm.
In Figure 8.3, we take a glimpse at the 3015, 3030, 3060, and 3080 concentrators. The
3015 is upgradeable whereas the 3005 is not. All of these models share the same case, so
only the 3015 is illustrated. Unlike the 3005, the front of the 3015 actually shows some
information. There are quite a few LEDs on the front panel that show the status of the concentrator, as illustrated in Figure 8.3. See Chapter 10 for information about what each of
the LEDs indicates.
On the VPN concentrator, a blinking green LED for link status does not mean
that data is passing through the interface. Instead, it means that the link is connected but disabled.
Introducing the VPN 3000 Concentrators
FIGURE 8.3
335
The front panel of the VPN 3015 concentrator
System
Ethernet Link Status
Expansion Modules
Insertion Status
1
2
3
Run Status
1
2
3
Fan Status
4
CPU Utilization
Power Supplies
Active Sessions
A
Throughput
B
On the right side of the LED panel, there is an LED meter. Below that, there are a button and
three categories. Pressing the button will migrate the lit LED through the three choices of CPU Utilization, Active Sessions, and Throughput. The meter will display whichever of these three is active.
VPN Concentrator Client Support
The VPN concentrator should be placed somewhere near the entrance to your network. It is not
a good idea to have too many encrypted tunnels going too far into your network because they
present a security risk. Figure 8.4 illustrates the concept of a VPN crossing a shared network.
FIGURE 8.4
Client support for a VPN concentrator
Analog, ISDN,
DSL, cable
PPTP, LTP
over IPSec, IPSec
Web server
Corporate
office
Internet
VPN
concentrator
Client
Secure VPN session
File server
Figure 8.4 shows the client connection coming across the Internet, passing through the
router, and terminating at the concentrator. If the router were set to block a certain type of traffic, that router would not be able to check the traffic inside the tunnel as it passed through. This
becomes a more serious risk when a firewall allows encrypted traffic through. Of course, it
might not be possible or desirable to eliminate all VPNs passing beyond a firewall or concentrator, but with good design planning, the number of VPNs that do this can be minimized.
336
Chapter 8
Introduction to Cisco VPN Devices
Introducing the 3002 VPN Hardware Client
The VPN hardware client is a great tool if your network has several users that need to communicate via a tunnel, but it is impractical to purchase a piece of hardware for every user. Unlike
the VPN concentrator, which was developed by Altiga and picked up by Cisco, the hardware
client was developed by Cisco.
The hardware client is nothing more than a very basic router with the strong point of creating
a tunnel to another location that is serviced by a VPN concentrator. The purpose of using the
VPN hardware client is to offload the client-processing requirements when there are several clients on the same network creating VPNs to the same destination. While this device supports up
to 253 users, it is most appropriate for a small network with fewer than 50.
Figure 8.5 is an illustration of the VPN 3002 hardware client. There is an RJ-45 console connection, if one is required, but unlike the VPN concentrator, the hardware client comes with an
IP address preset on the active private interface. This makes it easy for someone to use a Web
browser to surf to the administration page to set up the device. An optional 8-port Ethernet
switch is also available, which makes the 3002 the perfect solution for remote office locations
that require little to no IT support.
In addition to accessing the hardware client via a Web browser, using HTTP or
HTTPS, the VPN 3002 hardware client also supports administrative connections via Telnet and SSH.
FIGURE 8.5
The VPN 3002 hardware client
Power
Console
Public
Private
Power
Hardware Console
reset switch
Public
Private
The client is configured for the IP address of 192.168.10.1 on the private interface. The hardware client uses Port Address Translation (PAT) to provide address translation out to the Internet. The PAT feature can also be disabled, if necessary. The public interface can be configured
to use Dynamic Host Configuration Protocol (DHCP) to request an IP address from the service
provider.
Introducing the 3002 VPN Hardware Client
337
Once the client is up and running, anyone with the proper credentials can log in and make
changes. The client needs to be configured, and then the tunnel needs to be brought up manually. Until this happens, secure communication between the sites does not exist. We will look at
how to configure the hardware client in the next section.
Configuring the 3002 CLI Quick Configuration Utility
When you first remove the 3002 from the box, you must start the configuration process from
the command-line interface (CLI). Everything required to be configured on the 3002 can be
done from the CLI. We will look at how to configure the hardware client using the CLI in the
following sections.
Interface Configuration
The following steps show you how to configure the interface:
1.
The system prompts you for the configuration of the interfaces:
1) Modify Ethernet 1 IP Address (Private)
2) Modify Ethernet 2 IP Address (Public)
3) Configure Expansion Cards
4) Save changes to Config file
5) Continue
6) Exit
Quick -> _
Press 1 and Enter to select the option to modify the private-side Ethernet interface.
2.
The CLI returns a table showing the existing configuration, including IP addresses and subnet masks:
This table shows current IP addresses.
Interface IP Address/Subnet Mask MAC Address
----------------------------------------------------------------Ethernet 1 - Private | 10.10.4.6/255.255.0.0| 00.10.5A.1F.4F.07
Ethernet 2 - Public
|
0.0.0.0/0.0.0.0
|
Ethernet 3 - External |
0.0.0.0/0.0.0.0
|
----------------------------------------------------------------> Enter IP Address for Ethernet 1 (Private)
Quick -> [ 0.0.0.0 ]
When you enter the IP Address and press enter, the system prompts you for the subnet
mask. The default setting automatically takes the natural mask for the IP address entered.
3.
The system prompts you to set up the speed of the interface. The default is to set to
auto-detect.
338
4.
Chapter 8
Introduction to Cisco VPN Devices
The 3002 now requires the configuration of the transmission mode for the interface; the
default is option 1 (Half/Full/Auto):
1) Enter
2) Enter
3) Enter
Quick ->
Duplex - Half/Full/Auto
Duplex - Full Duplex
Duplex - Half Duplex
[ 1 ] _
Configure System Information
To configure the system information, follow these steps:
1.
The CLI prompts you to assign a system name to the 3002; the name must be unique to the
system:
-- : Assign a system name to this device.
> System Name
Quick -> _
2.
The system prompts you for a DNS server IP address:
-- : Specify a local DNS server, ...
> DNS Server
Quick -> [ 0.0.0.0 ]
3.
You are then prompted to enter the domain name for the system:
-- : Enter your Internet domain name; ...
> Domain
Quick -> _
4.
The next prompt is the default gateway:
> Default Gateway
Quick -> _
This is the IP address that packets should be sent to where the system has no routing information. This IP address must be different from any of the other configured interfaces; it also
may be left blank to configure no forwarding gateway.
Configure a Tunneling Protocol
To configure the tunneling protocol, follow these steps:
1.
The system first shows that PPTP and L2TP are both enabled with no encryption in the
default configuration setting:
-- : Configure protocols and encryption options.
-- : This table shows current protocol settings
PPTP | L2TP |
Introducing the 3002 VPN Hardware Client
339
----------------------------------------|
Enabled
|
Enabled
|
| No Encryption Req | No Encryption Req |
----------------------------------------1) Enable PPTP
2) Disable PPTP
Quick -> [ 1 ]
2.
You are then asked to choose to require encryption or not:
1) PPTP Encryption Required
2) No Encryption Required
Quick -> [ 2 ]
3.
The system then prompts you to enable or disable L2TP:
1) Enable L2TP
2) Disable L2TP
Quick -> [ 1 ]
4.
You are then asked whether or not you wish to force encryption:
1) L2TP Encryption Required
2) No Encryption Required
Quick -> [ 2 ] _
5.
The next prompt is for IPSec:
1) Enable IPSec
2) Disable IPSec
Quick -> [ 1 ] _
Configure IP Addresses
To configure the IP addresses, follow these steps:
1.
To begin the setup of the DHCP addressing, the system prompts you to enable or disable
a client-specified address assignment:
-- : Configure address assignment for PPTP, L2TP and IPSec.
1) Enable Client Specified Address Assignment
2) Disable Client Specified Address Assignment
Quick -> [ 2 ]
2.
The system then prompts you to enable or disable address assignment on a per-user basis:
1) Enable Per User Address Assignment
2) Disable Per User Address Assignment
Quick -> [ 2 ] _
340
3.
Chapter 8
Introduction to Cisco VPN Devices
The system then asks if you are going to use DHCP:
1) Enable DHCP Address Assignment
2) Disable DHCP Address Assignment
Quick -> [ 2 ] _
4.
You are prompted for the DHCP server address:
> DHCP Server
Quick -> _
5.
The next prompt is for the pool assignment:
1) Enable Configured Pool Address Assignment
2) Disable Configured Pool Address Assignment
Quick -> [ 2 ] _
6.
The system then asks you to configure the pool:
> Configured Pool Range Start Address
Quick -> _
7.
You are prompted for the ending address:
> Configured Pool Range End Address
Quick -> [ 0.0.0.0 ]
Configure the IPSec Group
To configure the IPSec group, follow these steps:
1.
The system prompts you for an IPSec group name, as follows:
> IPSec Group Name
Quick -> _
2.
Once the group name is entered, the system prompts you for a password and asks for a verification:
> IPSec Group Password
Quick ->
Verify -> _
Change the Admin Password
To change the Admin password, follow these steps:
1.
The system prompts you to change the Admin password:
-- : We strongly recommend that you change the password ...
> Reset Admin Password
Quick -> [ ***** ] _
Introducing the 3002 VPN Hardware Client
2.
341
Enter your password, and then verify it:
Verify -> _
The system displays asterisks for your keystrokes.
Save and Exit the CLI
To save and exit the CLI, follow these steps:
1.
You are prompted to either go to the main menu, save changes to the Config file, or exit:
1) Goto Main Configuration Menu
2) Save changes to Config file
3) Exit
Quick -> 2
2.
Exit the system by selecting the default option 3:
1) Goto Main Configuration Menu
2) Save changes to Config file
3) Exit
Quick -> 3
Done
Configuring the Hardware Client with the
Quick Configuration Utility
The hardware client is easy to set up through its Quick Configuration utility. You can walk a
user through setup over the phone.
While you can configure the client via the CLI through the console port, most people choose
to configure it via the Web browser. However, the initial configuration (at least to get to configure the private-side IP address) must be done with the CLI as described in detail above.
The first step is logging in to the device. Once the browser is pointed to the correct IP address,
the login screen appears, as shown in Figure 8.6. No matter how the client is configured, the
default username is admin and the default password is admin.
Anyone who is familiar with initial setup mode on a router will understand the concept of
Quick Configuration. This utility’s opening screen is shown in Figure 8.7. As you can see, it
takes you through each configuration step:
1.
Set the system time, date, and time zone.
2.
Optionally, upload an existing configuration file.
3.
Configure the Ethernet interface to your private interface.
4.
Configure the public interface to a public network.
342
Chapter 8
Introduction to Cisco VPN Devices
5.
Specify a method for assigning IP addresses.
6.
Configure the IPSec tunneling protocol.
7.
Set the hardware client to use either PAT or LAN Extension mode.
8.
Configure Domain Name System (DNS).
9.
Configure static routes.
10. Change the Admin password.
FIGURE 8.6
Logging in to the hardware client
FIGURE 8.7
The opening Quick Configuration screen
Let’s take a look at some of the Quick Configuration details.
Setting the System Time
It is always advisable to ensure that the clock is set to the correct time. If the client will be using
a digital certificate, it is also advisable to set the time and time zone to reflect Greenwich Mean
Time (GMT). Setting the time on the client involves entering on the Time And Date screen (see Figure 8.8) the time, date, and time zone and specifying whether daylight savings time (DST) is used.
Introducing the 3002 VPN Hardware Client
FIGURE 8.8
343
Configuring the time
Using an Existing Configuration File
The next step allows the administrator to upload a configuration file. This is done by a Webbased transfer tool. No Trivial FTP server is needed, but the file does need to reside on a drive
that the administrator can access. If the file is on a mapped network drive, you can access it by
clicking the Browse button.
Configuring the Private Interface
The Private Interface screen, shown in Figure 8.9, displays the properties of the interface for
inside the network. By default, it has an IP address of 192.168.10.1 with a 24-bit mask. If you
want to change the IP address, select the Yes radio button. Also make sure that the interface has
a DHCP server for client addressing if your site requires such support.
FIGURE 8.9
Configuring the private interface
344
Chapter 8
Introduction to Cisco VPN Devices
Configuring the Public Interface
The Public Interface screen, shown in Figure 8.10, contains properties for the interface going
out to the Internet. The IP address may be statically configured or it may be set up via DHCP.
Since many DHCP servers require the use of a valid hostname, this is an option on the Public
Interface screen.
The public interface also has routing information associated with it. You can configure a
default gateway. You can configure other routes later, but most networks that use the hardware
client will not have a router further inside the network.
FIGURE 8.10
Configuring the public interface
Configuring IPSec
All VPNs consist of a tunnel with two endpoints. Since the hardware client is one end of the tunnel, it needs to be told where the other end is. You configure this information on the IPSec
screen, shown in Figure 8.11.
FIGURE 8.11
Configuring the IPSec peer
Introducing the 3002 VPN Hardware Client
345
You can set up IPSec to use a group name and password, as well as a username and password
for remote authentication via a database (such as a Windows domain or Active Directory database). Alternatively, IPSec can be set up to use digital certificates. These settings must match on
both sides of the tunnel.
Configuring PAT or LAN Extension Mode
Port Address Translation (PAT) is used to translate from one IP address to another. If the
default IP address of 192.168.10.1 remains on the private interface, PAT will remain enabled
and cannot be disabled. If you do not want to use PAT, you will need to use some other IP
address; if the packets will be seen by Internet devices, the IP address must be routable. Also,
PAT must be disabled (and a different IP address used) if you want to use LAN Extension mode.
When configuring PAT, the first screen you come to is the Configuration | Policy Management screen, as seen in Figure 8.12.
FIGURE 8.12
The Configuration | Policy Management screen
PAT is a way that a network device can translate several IP addresses into a
single IP address. Each IP address and port assignment will equal a like IP
address and port assignment when a packet wishes to enter the Internet. This
allows the potential for more than 64,000 IP addresses to use a single registered address, although the functional limit is about 4,000.
Next you are sent to the Configuration | Policy Management Screen | Traffic Management
screen, as seen in Figure 8.13. To configure the Port Address Translation, click PAT.
FIGURE 8.13
The Traffic Management screen
346
Chapter 8
Introduction to Cisco VPN Devices
On the Configuration | Policy Management Screen | Traffic Management | PAT screen (see
Figure 8.14), click Enable.
FIGURE 8.14
The PAT screen
The Configuration | Policy Management Screen | Traffic Management | PAT | Enable screen
(see Figure 8.15) finally lets you enable PAT, which will effectively apply PAT to any traffic
flowing from the private to the public interface.
FIGURE 8.15
The Enable screen
LAN Extension mode allows the hardware client to present a routable network to the tunneled network. IPSec encapsulates all traffic from the private network behind the hardware client to networks behind the central-site concentrator. PAT does not apply, therefore, devices
behind the concentrator have direct access to devices on the hardware client private network
through the tunnel.
Configuring DNS
The Configuration | System | Servers | DNS screen of the Quick Configuration utility contains
settings that allow the hardware client to communicate with a DNS server and for a local
domain to be configured (see Figure 8.16). The domain name can be important when requesting
an IP address via DHCP from some service providers.
Introducing the 3002 VPN Hardware Client
FIGURE 8.16
347
The DNS screen
The DNS screen identifies and configures the servers that will be used for name resolution.
The following options are available:
Enabled To enable the DNS functions, check the DNS box. The default is for the DNS services
to be enabled. If you do not wish to use the DNS services, then you can clear the box.
Disabling DNS effects more than just server IP address lookups. Many certificate services use DNS names for identification rather than IP addresses. Turning off DNS might prevent certificate usage.
Domain This field allows you to assign a domain name field to be appended to hostnames
before sending them to a DNS service for resolution. A 48-character limit is put on the field.
Primary DNS Server Enter the IP address of the primary DNS server in this field.
Secondary DNS Server Enter the IP address of the secondary DNS server in this field. The secondary DNS server is to be used as a backup if the primary server is not available or does not
respond before the specified timeout.
Tertiary DNS Server In this field, enter the IP address of the DNS server to be queried if the
primary and secondary DNS servers do not respond within the specified timeout.
Timeout Period In this field, enter the time in seconds. A query will wait before going to the
next level of backup server (i.e., Secondary, Tertiary). The default is 2 seconds, with a maximum
value of 30 and minimum of 1.
Timeout Retries In this field, enter the attempts to cycle through each of the DNS servers before
displaying an error. The default value is 2 times, with a maximum of 10 and minimum of 0.
348
Chapter 8
Introduction to Cisco VPN Devices
Apply/Cancel Click Apply when you are satisfied with your input; click Cancel to return to
the previous menu without keeping the input.
Configuring Static Routing
The Configuration | System | IP Routing | Static Routes screen is used to configure static routes
for the client. The public interface has a setting for a default route, but if other routing information is required, you will need to configure static routes. If you need to remove a route, select
it and choose Delete. Click the Add button to display the Add screen, shown in Figure 8.17.
FIGURE 8.17
The Add screen
Changing the Admin Password and Enabling Users
The Admin screen allows you to change the Admin password. After you set a new Admin password (for security), the Quick Configuration utility displays a screen that lists four other users
who are disabled by default:
The config user is used for quick configuration and monitoring.
The monitor user has read-only privileges.
You can enable one or both of these users by selecting the Enabled checkbox next to the
appropriate user.
These default users can be useful as templates for a multi-class administrative
system that delegates certain authority to different persons or groups.
Introducing the 3002 VPN Hardware Client
349
Managing the Hardware Client
After you’ve completed the Quick Configuration utility’s steps, the Hardware Client Manager
screen appears, as shown in Figure 8.18. This screen has links to three broad areas:
The Configuration option is for configuring device properties such as IP addressing.
The Administration option allows you to change user passwords.
The Monitoring option shows system statistics and allows you to create the tunnel.
To see the status of a tunnel, click the Monitoring link, then System Status, which brings up
the System Status screen. If a tunnel exists, it can be disabled. If a tunnel doesn’t exist, you can
activate one by clicking the Connect Now button, as shown in Figure 8.19. This screen also
shows how long the client has been up and the type of software running.
If a tunnel currently exists, the Monitoring screen will show other information, including
how long the tunnel has been up, the IKE and IPSec building blocks used to create the tunnel,
and how much traffic has passed through the tunnel.
FIGURE 8.18
The Hardware Client Manager opening screen
Additional VPN 3002 Client Features
In addition to the configuration options available during Quick Configuration, there are several
ways of configuring the VPN 3002 so it is more secure or to alleviate problems found during
setup. Some of these features are version dependent, and might require up to version 3.6 software to exist on the client, concentrator, or both.
350
Chapter 8
FIGURE 8.19
Introduction to Cisco VPN Devices
Bringing up the tunnel
Reverse Route Injection
Reverse Route Injection (RRI) is how routes are added into VPN concentrator. These routes are
then advertised out to the remote VPN clients or LAN-to-LAN connections. RRI is a feature
supported on the concentrator that will forward routing information to the hardware client.
While this affects the client’s routing table, it needs to be configured on the concentrator. The
concentrator will advertise the assigned IP address of the hardware client for other devices to be
able to reach it.
The Cisco 3002 hardware client does not require any configuration to use RRI. The only
requirement is to be in Network Extension Mode (NEM). The only routing protocols used by
RRI are the Routing Information Protocol version 2 (RIPv2) and Open Shortest Path First
(OSPF). Each of these is configured on the network interfaces. You access the interfaces to make
those configurations through their respective Configuration | Interfaces screen.
Take caution using Virtual Router Redundancy Protocol (VRRP) with RRI, as
routing loops might be created because both the primary and backup servers
will advertise the same routes.
At minimum there must be at least an outbound RIPv2 configuration on the private interface. Outbound RIPv2 must also be configured to enable Autodiscovery. Configuration for RRI
setup details are covered in Chapter 9.
Introducing the 3002 VPN Hardware Client
351
IPSec Over TCP and Backup Servers
IPSec over TCP as well as backup servers may be configured on the VPN 3002 by going to the
Configuration | System | Tunneling Protocols | IPSec screen (see Figure 8.20).
At the top of the screen is the address for the primary concentrator, and below is a box where additional IP addresses may be added for tunnel termination. The easiest way of configuring additional
servers is to fill in the appropriate public IP addresses of concentrators in the Mode Config tab on the
concentrator, then select Use The List Below. When a hardware client connects, the concentrator will
push the list of available backup servers to the client. The client can also have IP addresses hard configured, and if this is used, the Mode Config setting should be to use the client configured list.
At the bottom of the page is where IPSec over TCP is set up. Mark the checkbox for IPSec
over TCP and ensure the proper port number is set up. The default on both the concentrator and
the VPN 3002 is port 10000. Be sure to fill in the appropriate username, group name, and passwords for both and ensure the port number is set correctly. This feature is useful when there is
a device performing PAT or filtering IPSec along the path the encrypted traffic will take. PAT
doesn’t support encrypted traffic well due to changing the port used during ISAKMP negotiations as well as ESP and AH not having ports to translate.
FIGURE 8.20
The IPSec screen
352
Chapter 8
Introduction to Cisco VPN Devices
Interactive Authentication
When a hardware client will allow all traffic from the local network to cross to the VPN concentrator on the far side, a potential security risk emerges. To combat this, Cisco has a feature
on the VPN 3002 that requires a user to authenticate before the VPN 3002 will encrypt the traffic. This works well if you don’t want some users, such as contractors, using the tunnel.
The username and password for the VPN 3002 itself can also be left off and provided when
the tunnel needs to come up. This is more secure than the default storage method and is useful
if the VPN 3002 is in a location that is not secure. By default, the unit password is permanently
stored in the hardware client’s memory.
Configuration is accomplished on the concentrator, but authentication takes place on the client. Authentication is checked on the concentrator and pushed down to the client during tunnel
negotiations.
The following instructions assume that both client and user authentication are required:
1.
From the VPN 3002 Hardware Client Manager login screen, click the Connection/Login
Status button (see Figure 8.21).
2.
The Connection/Login Status screen appears (see Figure 8.22). Click Connect Now.
FIGURE 8.21
The VPN 3002 Hardware Client Manager login screen
Introducing the 3002 VPN Hardware Client
FIGURE 8.22
3.
The Connection/Login Status screen
The VPN 3002 Interactive Authentication screen appears (Figure 8.23). Enter the username
and password for the VPN 3002 and click Connect.
FIGURE 8.23
4.
353
The VPN 3002 Interactive Authentication screen
If everything was entered correctly, the client should indicate it is now connected. To authenticate a user, at the Connection/Login Status screen, click Log In Now (see Figure 8.24).
FIGURE 8.24
The Connection Login Status screen
354
Chapter 8
Introduction to Cisco VPN Devices
5.
The Login screen appears. Enter the username and password and click Login.
6.
The IP address of the connection is now associated with the user that just logged in.
Load Balancing
Load balancing is a feature that is supported by configuring the concentrator, however, it
works only with the hardware client version 3.5 or higher or Cisco VPN Clients running version 3.0 or higher. LAN-to-LAN and other connections may establish tunnels with concentrators that are set up for load balancing, however, these devices will not participate in the
load balancing by being directed away from the primary connection point. If the hardware client does not have the necessary software, then the client needs to point to the IP address of
a real concentrator, not the IP address of the fake aggregating device that then shares the connections with real concentrators.
Due to the fact that the 3002 only receives the benefit of the load balancing, there is no configuration requirement at this end of the tunnel. Just remember to use the virtual IP address of
the cluster at the opposite end of the tunnel.
VRRP and load balancing should not be used together with the same concentrator. VRRP uses a hot stand-by for redundancy if the primary device fails,
meaning that only the primary passes traffic while the backup is in stand-by.
Conversely, load balancing requires that all devices in the cluster be active at
all times.
There is no configuration required to enable load balancing on the 3002. Load
balanced traffic will be received when the proper virtual IP address for the
remote end of the tunnel is used.
VPN concentrators are configured together in a single virtual cluster. Within that cluster will
be a virtual cluster master (VCM). This cluster will be assigned a single IP address that will be
the only address known to the opposite sides of the peer’s tunnel.
The job of cluster master is determined by the election of the most eligible candidate. Each of
the devices that are eligible to become the cluster master will have an assigned “priority” value
between zero and 10. Table 8.3 lists the default priority settings. The highest priority number in
the cluster will win the election and subsequently become the virtual cluster master. If two concentrators have the same priority values and there is a tie in the election process, then the device
with the longest uptime value will become the cluster master. Default priority values are assigned
in such a way that the faster, more capable concentrators have the higher-priority values, making
them more likely to become the master when clustered with a less-capable device.
These default priority values can be overridden on the Configuration| System | Load Balancing screen if need be (see Figure 8.25). However, it is recommended that the most capable concentrator be allowed to become the cluster master due to the processing overhead involved in
being the master.
Introducing the 3002 VPN Hardware Client
TABLE 8.3
Default Priority Settings by Model
Model
Priority
3080
9
3060
7
3030
5
3015
3
3005
1
FIGURE 8.25
355
The Load Balancing screen
In the event the master of the cluster fails, an election will be forced and the next most
capable concentrator will be elected. Additionally, any clients connected would be required
to renegotiate their VPN tunnel.
When a client makes an attempt to connect to the cluster (cluster addresses should be configured on the remote end, not on any of the actual IP addresses of any of the devices in the cluster), the master will handle the request by first determining which device in its cluster, including
itself, has the most processing cycles. Second, the master will hand the actual, hard-coded IP
address of that device back to the requestor, who will then reinitiate the IKE negotiations and
356
Chapter 8
Introduction to Cisco VPN Devices
set up the tunnel with that concentrator, at which point the load balancing processing is complete and the communication is only with the requestor and the assigned concentrator.
When a cluster receives a request for a connection, the IPSec group settings will be negotiated
to attempt to establish a tunnel. Every VPN concentrator must have identical settings for the
groups, and of course, one of those groups must match the requesting peer for a tunnel to be successfully established.
Configuration for load balancing is covered in Chapter 9.
Introducing the VPN Software Clients
Another alternative Cisco offers for VPN termination is the VPN software client. This software
allows a single PC or server to act as one end of an IPSec tunnel.
Cisco’s VPN offerings were derived from four independent engineering groups. As a result,
early versions of Cisco’s VPN clients were specific to the type of VPN concentrator device. The
VPN 3000 series of VPN concentrators were added to Cisco’s offerings through the acquisition
of Altiga Networks. While the original Altiga-only client is still available, Cisco has developed
a common VPN client that supports both the Altiga-derived devices as well as IOS router–based
and PIX firewall VPNs. IOS-based VPNs were first supported in version 12.2T. Unity clients are
supported on the PIX firewall after version 6.0. Prior to these versions, IOS- and PIX-based
VPN connections were available only by using the older Cisco SafeNet client.
Cisco initially released version 3.0 of the VPN client in the spring of 2002. This version,
which was commonly referred to as the Unified Client, was the first to support multiple types
of head-end devices. The version 4.0 software client has since replaced the version 3.x client.
Our discussions will deal with this newer version of the Unified Client.
When the VPN client starts, nothing is configured by default, as shown in Figure 8.26. To
configure the client, you need to set up the connection and set properties.
FIGURE 8.26
The VPN client at initial startup
Introducing the VPN Software Clients
357
Unified Client versions 3.0 and lower do not support Windows XP. If you install
version 3.1, and then upgrade your system to XP, XP might report that the client is not supported, even though it is. The solution is to uninstall and reinstall
the same client.
In the following sections, we will look at the specifics in configuring the Unified Client.
Configuring the Connection
To configure the connection, click the New button to start this process. On the Connection Setting screen, set the name of the connection along with a description and click Continue.
On the top of the Create New VPN Connection Entry screen (see Figure 8.27), specify a
name for the connection, a description of the connection, and the IP address or hostname of the
terminating device.
FIGURE 8.27
The Create New VPN Connection Entry screen
Setting Authentication Properties
Authentication can take place either via a digital certificate or a preshared key. The Authentication tab of the Properties dialog box, shown in Figure 8.28, allows you to set either group
parameters or certificate information.
The group name and password used for the preshared-key method of authentication must
match the ones set up on the destination device.
To use a certificate for authentication, simply select the Certificate Authentication radio button, then select the certificate you wish to use from the drop-down list.
358
Chapter 8
FIGURE 8.28
Introduction to Cisco VPN Devices
The Authentication tab
A certificate must exist before options will be available in the drop-down box.
This is covered later in this chapter, in the section “Installing a Certificate.”
The Send CA Certificate Chain check box is checked by default. This option instructs the
client to send the full CA (Certificate Authority) certificate chain to the VPN concentrator.
This might be necessary when the VPN concentrator and the VPN client use certificates
from different subordinate CAs that have the same root CA. If this option is not checked,
the VPN concentrator must directly trust the subordinate CA that issued the client’s
certificate.
Setting Connection Properties
The Connections tab of the Properties dialog box, shown in Figure 8.29, allows you to define
the other end of the tunnel for this particular configuration. Entries can be added with the Add
button and deleted with the Remove button.
Multiple concentrator IP addresses are supported when the Enable Backup Servers
checkbox is checked. If the concentrator with the first IP address is unavailable, the second
IP address will be tried. This allows an organization to use multiple concentrators for
failover purposes.
Introducing the VPN Software Clients
FIGURE 8.29
359
The Connections tab of the Properties dialog box
Installing a Certificate
Certificate management is done from the Certificates tab on the main VPN client screen, as
shown in Figure 8.30. The Certificate Enrollment screen allows for two types of certificate
enrollment: Online and File. The Cisco VPN client can automatically request a certificate on line
from a CA that supports Simple Certificate Enrollment Protocol (SCEP), or the certificate can
be installed as part of an offline process. Additionally, a certificate that already exists as part of
the internal Windows certificate store can be imported.
FIGURE 8.30
The Certificates tab
360
Chapter 8
Introduction to Cisco VPN Devices
The following procedure outlines the process of requesting a certificate using the online method:
1.
To request a certificate, select the Enroll icon from the top of the VPN client screen, as
shown in Figure 8.30.
2.
The Certificate Enrollment screen opens, as shown in Figure 8.31. This screen has four
fields: Certificate Authority, CA URL, CA Domain, and Challenge Password.
FIGURE 8.31
3.
The Certificate Enrollment screen
Select New to configure a new CA.
Once a CA is successfully used for the first time, that CA’s information is cached
and automatically populates the CA URL and CA Domain fields when selected.
4.
Configure the CA URL to identify where to forward the certificate request. The listed URL
is the standard SCEP URL for a Microsoft CA.
5.
Configure the CA Domain. This field selects the domain of the authority that the CA services. This is often the IP domain name.
6.
Configure the Challenge Password. The Challenge Password field is a simple authentication method that many CAs use to control certificate requests. If your CA doesn’t require
a challenge password, simply leave the field blank.
7.
Click the Next button to display the second Certificate Enrollment screen, as shown in
Figure 8.32.
Introducing the VPN Software Clients
FIGURE 8.32
361
The second Certificate Enrollment screen
8.
The second Certificate Enrollment screen prompts for certificate identification information. The only required field is the canonical name (CN). The field is usually the end user’s
full legal name.
9.
Click the Enroll button to request the certificate. If the CA is configured to automatically
issue the certificate, no further action is required.
10. If the CA authenticates requests manually, the certificate shows as Request in the Store column:
362
Chapter 8
Introduction to Cisco VPN Devices
11. The client must periodically check with the CA to pick up the approved certificate. To man-
ually check for the certificate, select the Retry Certificate Enrollment option from the Certificates toolbar:
Preconfiguring the VPN Client
The software client needs to be loaded on each machine that is expected to form a tunnel endpoint.
In many cases, it is not practical for a member of the IT department to visit the home of a remote
user just to install a single piece of software. Some people who work remotely can be talked
through the setup via the phone, but others might find setup difficult. Cisco has attempted to make
it easier to talk users through installations by “wizardizing” the process. Additionally, you can
preconfigure the client for your users.
By preconfiguring the client, not only do you make it easier for the user to install the software, but you also can make sure that your users use particular settings. Recent versions of the
VPN client have a built-in stateful firewall. How effective is that firewall if users can easily turn
it off? How secure is a wireless connection without a VPN? By requiring certain settings and
making it difficult for users to stray from those settings, you can strengthen the security of your
network.
When the VPN client is being installed, the application can automatically configure itself
based on custom parameters you created in the client’s profile file. Global configuration parameters are stored in the vpnclient.ini file. Parameters relating to specific connections are saved in
.pcf files. The vpnclient.ini configuration file is stored by default in the c:\Program Files\Cisco
Systems\VPN Client directory. The .pcf connection configurations are stored in the c:\Program
Files\Cisco Systems\VPN Client\Profiles subdirectory. Both types of files use the familiar Windows .ini format.
Version 2.x of the Unified Client used a file called IPSecdlr.ini to hold configuration information.
Introducing the VPN Software Clients
363
Each profile file has many variables that can be configured. Here is an example of part of a
vpnclient.ini file:
[MAIN]
!EnableLog=1
: This makes sure a log will always be kept.
DialerDisconnect=1
[LOG.DIALER]
LogLevel=1
: This enables dialer logging.
Table 8.4 lists the client configuration format for a profile file.
TABLE 8.4
Client Configuration Format
Symbol
Usage
!
Using the exclamation point as the first character makes this configuration
item mandatory. Not all keys can be marked mandatory.
: or ;
The colon or semicolon is used to denote a comment.
=
The equal sign is a reserved symbol. It separates a keyword from a value.
[]
The square brackets are used for section headings. They usually denote a
set of related keys and values.
For full explanations of each VPN client profile file variable, refer to http://
www.cisco.com/univercd/cc/td/doc/product/vpn/client/3_6/admin_gd/
vcach2.htm.
It is possible to create custom .pcf and .ini files and forward them to the
users. While this is very convenient, it is not a secure way of passing VPN passwords. Avoid the temptation to place authentication passwords and usernames in preconfigured files.
The user must place the client installation file, the vpnclient.ini file, and any .pcf files in
the appropriate directories. When the client begins installation, it will use the properties found
in the .ini file for customization. Cisco has made the VPN client software available in both
364
Chapter 8
Introduction to Cisco VPN Devices
Microsoft Installer and InstallShield formats. While outside the scope of this text, savvy support
personnel can easily script the installations to minimize user intervention and error.
For more information about installation automation using MSI or InstallShield,
refer to http://www.cisco.com/en/US/products/sw/secursw/ps2308/
products_administration_guide09186a00800bd992.html.
Another file, named oem.ini, controls the way the VPN client looks. If you want to change
the client software’s text or graphics from the defaults, you can use the oem.ini file. In this file,
you can provide the custom text or the location for custom text or graphic files.
For more information about using the oem.ini file, refer to http://
www.cisco.com/univercd/cc/td/doc/product/vpn/client/rel_3_0/admn_gd/
vcach4.htm.
Rolling Out a Number of VPN Concentrators
It is common in a corporate or VAR environment to install many VPN concentrators with very
similar configurations. Here are some suggestions for reducing the quantity of work and
improving the quality of the installation.
Take advantage of client preconfiguration tools
It’s not unusual to have to install the software client on hundreds of PCs during the initial rollout
and during upgrades. You can use a combination of preconfiguration files, installer scripts, and
CA tools to make the installation of the software client a one-click operation.
Use the ! operator in the configuration files to restrict changes to the client configuration. Mark
the configuration files read-only and/or set security on the files to prevent casual modification
or loss of the files.
Clone VPN concentrator configurations
Most experienced router administrators have discovered that configuring a new router is about
95 percent repetitive and 5 percent unique information. Because of this, many have created a
minimal template to paste into a router to set up things such as AAA and DNS and to disable
unused features. Some administrators have even gone so far as to write a script that does
things such as update the firmware and software and generate the encryption keys.
Overview of the Cisco VPN Software Client Auto-Initiation
365
You can upload and download the complete VPN concentrator configuration as a text file. The
basic format of the text file is very similar to the vpnclient.ini file. While we’ve been unable
to find a detailed Cisco authorized manual for the text format, the key names are very descriptive and can be easily figured out by an experienced administrator.
For example, many companies have several locations. In a WLAN installation, you might need
to configure many concentrators that have identical configurations except for IP addressing. In
this case, it might be easiest to configure one of the concentrators using the CLI or Web interface, then upload the configurations wholesale and make the address changes.
Standardize the client operation systems
The software VPN clients operate with subtle differences between versions of the client operating
systems. For example, Windows NT/2000/XP versions of the client often handle capitalization differently than Windows 9x versions do. This can cause problems with keys, passwords, and the
parsing of configuration files. Standardizing a client operating system makes sure that the features and installation process is consistent.
Overview of the Cisco VPN Software
Client Auto-Initiation
The Cisco VPN Software client includes an auto-initiation feature. This feature allows the client software to automatically start the VPN connection process based on other network criteria. Typically
this feature is used in wireless LAN (WLAN) environments where an untrusted wireless network is
used to access services on an otherwise secure wired LAN. Figure 8.33 shows an example network.
FIGURE 8.33
A Wireless Network with VPN
VPN Tunnel
Wired Network Subnet
10.0.10.0/24
Wireless Network Subnet
10.0.30.0/24
366
Chapter 8
Introduction to Cisco VPN Devices
In this configuration, the VPN concentrator provides two functions. First, it acts as a gateway
between the wireless and wired networks. This allows the network administrator to authenticate
wireless connections on a per-user basis. Second, the VPN concentrator allows for a per-client
encryption mechanism using standard VPN encryption methods. These features are unavailable
using standard Wired Equivalent Privacy (WEP) protocols and are only partially provided with
the new LEAP/PEAP wireless security protocols.
For more information about wireless security protocols, refer to
http://www.cisco.com/en/US/netsol/ns110/ns175/ns176/ns178/
netqa09186a008010018c.html.
The VPN client is not aware of the physical media being used for network connection. This
means that an alternative indicator must be used to trigger a VPN connection. The Cisco VPN
Software client uses a list of known IP subnets to determine when a WLAN network has been
connected. Each of the known IP subnets is tied to a preferred VPN connection.
Configuring the auto-initiation feature is a three-step process:
Step 1: Create and configure the connection that will be used for the WLAN VPN. No special configuration is required for an auto-initiation connection. Configure it as you would any
other VPN connection.
Step 2: Enable the auto-initiation feature in the vpnclient.ini file. The auto-initiation feature
cannot be enabled from the GUI and must be configured manually by editing the vpnclient.ini
file. Two keys must be added to the [MAIN] section to enable auto-initiation:
AutoInitiationEnable=1
AutoInitiationList=WLANList
The AutoInitiationEnable=1 key enables the auto-initiation feature.
The AutoInitiationList=WLAN ties the auto-initiation feature to a list of subnets named
WLANList.
Step 3: Configure the selection criteria for the WLAN and tie it to the connection created in step
1. The selection criteria require a header and four keys to configure:
[WLANList]
Network=10.0.30.0
Mask=255.255.255.0
ConnectionEntry=WLANConnection
The [WLANList] header identifies the subnet listing. This header must match the key value of
the AutoInitiationList key from step 2.
The Network and Mask keys identify the IP subnetwork that is assigned to the WLAN you wish
to VPN through.
Exam Essentials
367
The ConnectionEntry key ties the subnetwork to the VPN connection that will be automatically
initiated. This value must match the Connection Entry field in the GUI.
While not absolutely required for operation, several other keys are very useful when dealing
with the auto-initiation feature. These are listed in Table 8.5.
TABLE 8.5
Other important vpnclient.ini keys
key/Value
Usage
AutoInitiationRetryInterval=3
The value of this key sets the retry timer to a number
of minutes. The default setting is 1 minute.
DialerDisconnect=1
This key instructs the VPN client to disconnect the
VPN connection when the user logs off their system.
RunAtLogon=1
This key instructs the VPN client to initiate the VPN
connection prior to logon. By default, the VPN connection is initiated after the user logs on to the
machine. Use this key to ensure that VPN clients are
properly authenticated to the secured LAN.
Summary
Each VPN tunnel has two ends, and each end is a client of the tunnel. Three VPN components—
the concentrator, hardware client, and software client—are able to offload the VPN process
from other network equipment to some dedicated device or service.
The software client is portable but requires user intervention to run. At the very least, the user
must start the application and log in. The hardware client and concentrator don’t require user
intervention, but they aren’t portable.
The hardware client is totally GUI-driven and is simple enough to set up that someone could
be talked through the configuration over the phone. Even better, there is the option of using a
preconfiguration file that can be loaded into the client to provide the configuration.
The Unified software client is simple to configure and has a number of options for automating and standardizing the installation process for users.
Exam Essentials
Know the capabilities of the different VPN concentrator models. The VPN concentrators
come in two sizes of concentrator. The 3005 is 1U; all the others are 2U. Normally, a higher
number means increased capabilities for the unit. An exception is going from the 3005 to the
368
Chapter 8
Introduction to Cisco VPN Devices
3015. The 3015 is upgradeable, but otherwise has the same limitations that the 3005 does.
Make sure you know the memory each model comes with and the maximum number of connections it can handle.
Understand how to configure the VPN hardware client. Configuring the hardware client is
similar to configuring the concentrator. However, there are differences, such as the fact that the
hardware client comes with a preconfigured IP address.
Understand how to configure the VPN software client. Know where to configure properties
for the VPN client. Know where to configure the tunnel endpoint and how to start a new configuration. Also, know how to use a preconfiguration file.
Key Terms
Before you take the exam, be certain you are familiar with the following terms:
auto-initiation
Scalable Encryption Processing (SEP)
private interface
U
public interface
VPN concentrator
Quick Configuration
Written Lab
1.
What are the current models of VPN 3000 concentrators and how many tunnels does each
support?
2.
Which of the VPN 3000 series concentrators include SEP modules? What is the purpose of
these models?
3.
What are the maximum and recommended maximum users for a Cisco VPN 3002 hardware client?
4.
What are the default administrative username and password for a VPN 3002 hardware client?
5.
What are the names and functions of the two nonadministrative users that are preconfigured on a VPN 3002 hardware client?
6.
What is the purpose of a virtual cluster master and how is one selected? What are the
default priorities of the different models?
7.
What are the name and version of the earliest Cisco software VPN client to support multiple types of terminating devices? What types of VPN servers does it support?
8.
Three types of files are used to control the way the Unified Client looks and is configured.
What are the names of the three files, where are they stored, and what is the function of each?
Written Lab
9.
369
A customer is using the auto-initiation feature to provide security over a wireless LAN and
complains that login scripts aren’t running. What is one possible VPN-related explanation
for this problem and how would you correct it?
10. Which types of encryption are currently supported by the Cisco VPN 3000 series of products?
370
Chapter 8
Introduction to Cisco VPN Devices
Answers to the Written Lab
1.
Cisco currently offers five different models of the VPN 3000 series. The 3005 supports up
to 100 users; 3015 also supports 100 users; 3030 supports up to 1,500; 3060 up to 5,000;
and 3080 up to 10,000.
2.
Three models come with Scalable Encryption Processors (SEP) modules: 3030, 3060, and
3080. The SEP provides hardware-based encryption services and can be upgraded as
encryption features are changed or improved.
3.
The VPN 3002 hardware client supports up to 253 remote users, but is recommended only
for locations of fewer than 50 users.
4.
The default username for a VPN 3002 hardware client is admin with a password of admin.
5.
config and monitor are two other built-in users. The config user provides access during the
initial configuration. The monitor user provides read-only access to statistical information.
6.
The virtual cluster master (VCM) directs incoming VPN traffic to the least-busy VPN concentrator in a cluster that is providing load balancing. It is selected by an election in which
each concentrator is given a priority from 0 to 10. The highest-priority concentrator
becomes the VCM. In the event of a tie, the system that has the longest uptime is selected.
The default priorities for each model are 3005: 1; 3015: 3; 3030: 5; 3060: 7; and 3080: 9.
7.
Multiple VPN concentrator types were first supported by the Unified Client version 3.0. The
Unified Client supports VPN 3000 series concentrators, IOS-based routers, and PIX firewalls.
8.
The three types of files that control the behavior of the Unified Client are vpnclient.ini,
oem.ini, and any file ending with the extension .pcf. The vpnclient.ini and oem.inf
files are stored in the main program directory, which is c:\program files\cisco
systems\vpn client\ by default. The .pcf files are stored in the c:\program
files\cisco systems\vpn client\profiles subdirectory. The vpnclient.ini file
stores the main part of the configuration; the oem.inf file controls the way the GUI looks;
and the .pcf files store connection specific configuration information.
9.
It is likely that the login scripts are not running because the VPN tunnel is not initiated until
after the user has already logged on. To correct this problem, add the following key to the
vpnclient.ini file: RunAtLogon=1.
10. The =VPN 3000 series supports the following encryption standards: 40-bit DES, 56-bit
DES, 128-bit DES, 3DES, MPPE, and AES.
Hands-On Lab
371
Hands-On Lab
This lab is designed to guide you through the basic configuration of a VPN 3005 series using the
CLI Quick Configuration utility. The CLI on the 3005 is a menu-based configuration, administration, and monitoring tool, unlike the command line–only utility in the standard Cisco IOS.
You can however, access the CLI either through the console port of the device (9600-N-8-1) or
through a Telnet session to the IP address of the private side.
By the end of this exercise you will have configured the proper Ethernet interfaces, system
information, tunneling protocols, address assignment, NT Authentication server, and IPSec
group, as well as saving and exiting the configuration.
This section includes the following labs:
Lab 8.1: Configure Ethernet interfaces.
Lab 8.2: Configure system information.
Lab 8.3: Configure a unneling protocol.
Lab 8.4: Configure IP addresses.
Lab 8.5: Set up for authentication to an NT server.
Lab 8.6: Configure the IPSec group.
Lab 8.7: Change the admin password.
Lab 8.8: Save and exit the CLI.
LAB 8.1
Configure Ethernet interfaces.
1.
Configure the private side of the Ethernet interfaces as follows:
IP Address: 10.10.10.1
Subnet mask: 255.255.255.0
Speed: Auto detect
Duplex: Auto
2.
Configure the public side of the Ethernet interfaces as follows:
IP Address: 192.168.10.23
Subnet mask: 255.255.255.0
Speed: 10Mbps
Duplex: Full
372
Chapter 8
Introduction to Cisco VPN Devices
LAB 8.2
Configure system information.
1.
Use a system name of VPN3005a.
2.
Configure your DNS Server to be 192.168.10.42.
3.
The domain you want do configure is vpndomain.net.
4.
Your default gateway is 192.168.10.1.
LAB 8.3
Configure a tunneling protocol.
Configure PPTP and L2TP on your tunnel so that clients must use Microsoft encryption and
enable IPSec.
LAB 8.4
Configure IP addresses.
1.
Set up your 3005 VPN concentrator to use DHCP for assigning its IP addresses to clients as
a tunnel is established.
2.
Set the DHCP server IP address to 192.168.10.75.
3.
Set the pool to 192.168.10.80 - 192.168.10.180.
LAB 8.5
Set up for authentication to an NT server.
Use an NT server in your domain to authenticate the users of the VPN with an IP address of
192.168.10.70 with the Primary Domain Controller named MainPDC1 and use port 139.
LAB 8.6
Configure the IPSec group.
Set up an IPSec group. Use the group name: 3000Grp1 and password of S4rg0n1.
Hands-On Lab
373
LAB 8.7
Change the admin password.
Set the Admin password to a password of your choosing. Make sure to use at least eight alphanumeric characters and perhaps contain one special symbol.
LAB 8.8
Save and exit the CLI.
1.
Save your configuration work.
2.
Exit the CLI.
Answer to Lab 8.1
1.
The system first prompts you for the configuration of the interfaces:
1) Modify Ethernet 1 IP Address (Private)
2) Modify Ethernet 2 IP Address (Public)
3) Configure Expansion Cards
4) Save changes to Config file
5) Continue
6) Exit
Quick -> _
2.
Press 1 and Enter to select the option to modify the private side Ethernet interface. The CLI
returns a table showing the existing configuration, including IP addresses and subnet masks:
This table shows current IP addresses.
Interface IP Address/Subnet Mask MAC Address
----------------------------------------------------------------Ethernet 1 - Private | 10.10.4.6/255.255.0.0 | 00.10.5A.1F.4F.07
Ethernet 2 - Public
|
0.0.0.0/0.0.0.0
|
Ethernet 3 - External |
0.0.0.0/0.0.0.0
|
----------------------------------------------------------------> Enter IP Address for Ethernet 1 (Private)
Quick -> [ 0.0.0.0 ]
3.
Enter the assigned IP Address for the Private side: 10.10.10.1.
4.
Upon hitting Enter, the system prompts you for the subnet mask. The default setting automatically takes the natural mask for the IP address entered:
> Enter Subnet Mask for Ethernet 2
Quick -> [ 255.0.0.0 ] _
374
Chapter 8
Introduction to Cisco VPN Devices
Since the address we are using has a natural mask of 255.0.0.0, this was presented as a
default option. Our network requirements require a different mask, so you should enter
that at this time: 255.255.255.0.
5.
Set up the speed of the Interface. The default is to set to auto-detect, which matches our network requirements, so simply press Enter here:
1) Ethernet Speed 10 Mbps
2) Ethernet Speed 100 Mbps
3) Ethernet Speed 10/100 Mbps Auto Detect
Quick -> [ 3 ]
6.
Configure the mode of transmission for our interface:
1) Enter
2) Enter
3) Enter
Quick ->
Duplex - Half/Full/Auto
Duplex - Full Duplex
Duplex - Half Duplex
[ 1 ] _
You will notice the default is option 1 (Half/Full/Auto). This option meets our
network requirements, so press Enter to take that default setting.
7.
This completes the configuration process for the Ethernet interfaces, so the CLI returns you
to the configuration menu:
1) Modify Ethernet 1 IP Address (Private)
2) Modify Ethernet 2 IP Address (Public)
3) Configure Expansion Cards
4) Save changes to Config file
5) Continue
6) Exit
Quick ->
8.
From here, you can select option 2 and follow the same procedure for configuring the public side of the network. (Notice through the process that the system takes the natural mask
of the IP address entered.)
Answer for Lab 8.2
1.
The CLI prompts you to assign a system name to the 3005 (the name must be unique to the
system):
-- : Assign a system name to this device.
> System Name
Quick -> _
Enter the assigned name: VPN3005a.
Hands-On Lab
2.
375
The system prompts you for a DNS server IP address:
-- : Specify a local DNS server, ...
> DNS Server
Quick -> [ 0.0.0.0 ]
Enter the assigned DNS Server IP address: 192.168.10.42.
3.
You are then prompted to enter the domain name for the system.
-- : Enter your Internet domain name; ...
> Domain
Quick -> _
Enter the assigned domain name: vpndomain.net.
4.
The next prompt is the default gateway:
> Default Gateway
Quick -> _
This is the IP address that packets should be sent to where the 3005 has no routing information. This IP address must be different from any of the other configured interfaces; it also
may be left blank to configure no forwarding gateway. Enter the assigned default gateway:
192.168.10.1.
Answer for Lab 8.3
1.
When we begin, the system shows us that PPTP and L2TP are both enabled with no encryption in the default configuration setting:
-- : Configure protocols and encryption options.
-- : This table shows current protocol settings
PPTP | L2TP |
----------------------------------------|
Enabled
|
Enabled
|
| No Encryption Req | No Encryption Req |
----------------------------------------1) Enable PPTP
2) Disable PPTP
Quick -> [ 1 ]
Select option 1.
2.
You are asked to choose to require encryption or not:
1) PPTP Encryption Required
2) No Encryption Required
Quick -> [ 2 ]
Select option 1 to require PPTP connections to use Microsoft encryption.
376
3.
Chapter 8
Introduction to Cisco VPN Devices
The system then prompts you to enable or disable L2TP:
1) Enable L2TP
2) Disable L2TP
Quick -> [ 1 ]
The default of option 1 meets the requirement that our network be able to establish an
L2TP tunnel, so press Enter.
4.
You are asked whether or not you wish to force encryption:
1) L2TP Encryption Required
2) No Encryption Required
Quick -> [ 2 ] _
5.
Per the lab instruction, you want to negate the default and require encryption, so select
option 1.
6.
The next prompt is for IPSec:
1) Enable IPSec
2) Disable IPSec
Quick -> [ 1 ] _
The lab instructions require you to enable IPSec, so take the default option by pressing Enter.
Answer for Lab 8.4
1.
To begin the setup of the DHCP addressing, the system prompts you to enable or disable
a client-specified address assignment:
-- : Configure address assignment for PPTP, L2TP and IPSec.
1) Enable Client Specified Address Assignment
2) Disable Client Specified Address Assignment
Quick -> [ 2 ]
The lab requires you to enable such a service, so select option 1.
2.
The system then prompts you to enable or disable address assignment on a per-user basis:
1) Enable Per User Address Assignment
2) Disable Per User Address Assignment
Quick -> [ 2 ] _
You want a DHCP per user address assignment, so we select option 1 to enable per User
Address Assignment.
3.
The system then asks if you are going to use DHCP:
1) Enable DHCP Address Assignment
2) Disable DHCP Address Assignment
Quick -> [ 2 ] _
Hands-On Lab
377
Choose option1
4.
You are prompted for the DHCP server address:
> DHCP Server
Quick -> _
The lab tells you to use the IP address 192.168.10.75, so enter that value here:
5.
The next prompt is for the pool assignment:
1) Enable Configured Pool Address Assignment
2) Disable Configured Pool Address Assignment
Quick -> [ 2 ] _
The lab instructs you to use a pool address, so select option 1 to enable the configured pool
address assignment option.
6.
The system then asks you to configure the pool:
> Configured Pool Range Start Address
Quick -> _
The lab requests 192.168.10.80 as the starting address, so enter that here.
7.
You are prompted for the Ending address:
> Configured Pool Range End Address
Quick -> [ 0.0.0.0 ]
The ending address the lab asks you to use it 192.168.10.180, so enter that and press Enter.
Answer for Lab 8.5
1.
For configuring authentication, the system first prompts you to configure an authentication
server type:
-- : Specify how to authenticate users.
1) Internal Authentication Server
2) RADIUS Authentication Server
3) NT Domain Authentication Server
4) SDI Authentication Server
5) Continue
Quick -> _
Select option 3 to configure the NT server.
2.
The system prompts you for the IP address of the NT server:
> NT Domain Server Address
Quick -> _
3.
Enter the correct address as requested by the lab: 192.168.10.70.
378
4.
Chapter 8
Introduction to Cisco VPN Devices
Once entered, the system moves on to the Primary Domain Controller prompt:
> Primary Domain Controller
Quick -> _
5.
Enter the value MainPDC1 as requested in the lab.
6.
Now you must tell the system what port you wish to access the PDC on:
> NT Domain Server Port
Quick -> [ 0 ]
The lab asks us to use port 139, so enter that value here.
Answer for Lab 8.6
1.
The system prompts you for an IPSec group name, as follows:
> IPSec Group Name
Quick -> _
The lab asks you to use the name 3005Grp1, so you can enter that value here.
2.
Once complete, the system prompts you for a password and asks for a verification.
> IPSec Group Password
Quick ->
Verify -> _
3.
Enter the required value for the password: S4rg0n1.
Answer for Lab 8.7
1.
The system prompts you to change the Admin password:
-- : We strongly recommend that you change the password ...
> Reset Admin Password
Quick -> [ ***** ] _
2.
Enter your password and then verify it:
Verify -> _
Answer for Lab 8.8
1.
You are prompted to either go to the main menu, save changes to the Config file, or exit:
1) Goto Main Configuration Menu
2) Save changes to Config file
Hands-On Lab
3) Exit
Quick -> 2
The default is option 2, so press Enter to save the configuration in the memory.
2.
Next, exit the system by selecting the default option 3:
1) Goto Main Configuration Menu
2) Save changes to Config file
3) Exit
Quick -> 3
Done
379
380
Chapter 8
Introduction to Cisco VPN Devices
Review Questions
1.
What is the default IP address on the hardware client’s private interface?
A. 172.16.1.1
B. 172.16.10.1
C. 192.168.1.1
D. 192.168.10.1
E. Nothing
2.
What methods of routing are supported on the hardware client? (Choose all that apply.)
A. OSPF
B. Default route
C. BGP
D. Static routes
3.
How much memory does the VPN 3060 concentrator come with?
A. 32MB
B. 64MB
C. 128MB
D. 256MB
4.
How many tunnels can the VPN 3030 concentrator terminate?
A. 100
B. 1,500
C. 5,000
D. 10,000
5.
What is the default administrative password for the hardware client?
A. cisco
B. password
C. admin
D. Nothing
Review Questions
6.
381
To use a certificate for authentication with the Unified Client, what must be available?
A. A client certificate
B. The peer certificate
C. The key must be entered.
D. A registration code
7.
When using version 3.5 of the Unified Client, what file will store information that can be preconfigured and sent to remote users to allow them to connect with a minimum of setup?
A. IPSecclient.ini
B. IPSecdlr.ini
C. vpndlr.ini
D. vpnclient.ini
8.
The preshared-key method of authentication for the Unified Client requires that the key be
placed where?
A. The Preshared Key box
B. The Key box
C. The Certificate box
D. The Password box
9.
The Unified Client can talk to a router running at least what version of the IOS?
A. 12.0XM
B. 12.1T
C. 12.2T
D. No version
10. How tall is the VPN 3005 concentrator?
A. 1U
B. 2U
C. 3U
D. 4U
382
Chapter 8
Introduction to Cisco VPN Devices
Answers to Review Questions
1.
D. The default IP address on the private interface on the hardware client is 192.168.10.1.
2.
B, D. The hardware client supports static routes and default routes. It does not learn routing
information from dynamic routing protocols.
3.
D. The 3060 comes with 256MB of RAM.
4.
B. The 3030 can terminate 1,500 tunnels.
5.
C. The default password for the user admin is admin.
6.
A. To use certificates for authentication with the Unified Client, the PC must have a client certificate installed on it.
7.
D. The vpnclient.ini file is used to preconfigure clients that are version 3.x or later.
8.
D. A group name goes in the Group text box, and the key itself goes in the Password text box.
9.
C. Unified Client support was added to IOS as part of the 12.2T series of code.
10. A. The 3005 concentrator is 1.75 inches (4.45 centimeters) tall.
Chapter
9
Configuring the VPN
Concentrator
THE FOLLOWING TOPICS ARE COVERED IN
THIS CHAPTER:
Overview of remote access using preshared keys
Initial configuration of the Cisco VPN 3000 Concentrator
Series for remote access
Browser configuration of the Cisco VPN 3000
Concentrator Series
Configure users and groups
CA support overview
Certificate generation
Validating certificates
Configuring the Cisco VPN 3000 Concentrator Series for
CA support
IPSec Software Client Overview of software client’s
firewall feature
Software client’s “Are You There?” feature
Software client’s Central Policy Protection feature
Software client’s Stateful Firewall feature
Client firewall statistics
Customizing firewall policy
Overview of Hardware Client interactive unit and user
authentication feature
Configuring Hardware Client integrated unit
authentication feature
Configuring Hardware Client user authentication
Monitoring Hardware Client user statistics
Configuring the VPN 3002 backup server feature
Configuring the VPN 3002 load balancing feature
Overview and configuration of the VPN 3002 software
auto-update feature
Monitoring the VPN 3002 software auto-update feature
Overview of port address translation
Configuring IPSec over UDP
Configuring NAT-Transversal
Configuring IPSec over TCP
Cisco VPN 3000 IPSec LAN-to-LAN
LAN-to-LAN configuration
LAN-to-LAN overview
Configuring the Concentrator LAN-to-LAN NAT feature
Root certificate installation
Identity certificate installation
When you pull a switch out of its box, you can place it into a rack,
plug in the users, and it will work. But unlike a switch, a VPN
Concentrator doesn’t get its information from analyzing traffic
that passes through it. A Concentrator needs to be configured before it can be functional.
This chapter explains how to configure the Cisco VPN Concentrator from either the commandline interface (CLI) or from the browser-based GUI. The GUI is the preferred access method for most
administrators and is more intuitive than the CLI. However, you’ll need to perform the initial configuration from the CLI before you can use the browser-based GUI. Then you can use the GUI’s
Quick Configuration mode to perform the basic configuration.
To begin the opening setup, you need to gather the necessary information for your environment. At a minimum, you need the following:
Private interface IP address, subnet mask, interface speed, and mode configuration
Public interface IP address, subnet mask, interface speed, and mode configuration
Device or system name
System date and time
Whether IPSec, PPTP, or L2TP will be used
DNS server IP address
Domain name
Default Gateway IP address or hostname
You also might need the following information:
IP addresses, subnet masks, interface speed, and mode for and additional interfaces.
If you intend to hand out IP address information such as IP address range, subnet mask, and
gateway to remote users, you’ll need the Dynamic Host Configuration Protocol (DHCP)
server information.
IP address or hostname, port number, and server secret (or password) of any external
RADIUS server.
If you’re using Windows NT Domain user authentication, you’ll need the IP address, port
number and Primary Domain Controller information.
If you’re using any external SDI user authentication, you’ll need the IP address and port
number for the SDI server.
Usernames and passwords for all internal VPN users. If you’re using the per-user address
assignment, you’ll also need the IP address and subnet mask.
If you’re using the IPSec tunneling protocol, you’ll need the name and password for the
IPSec tunnel group.
386
Chapter 9
Configuring the VPN Concentrator
Once the basic setup is completed, you’re ready to configure the Concentrator to allow users
to build tunnels. We’ll cover how to configure Concentrator groups, users, authentication,
access hour policies, and filters. The chapter will wrap up with information about configuring
IPSec using digital certificates and installing them on the Concentrator and the client.
Using the CLI for Initial Configuration
Because the VPN Concentrator does not have a default IP address, you cannot use a Web
browser for initial Concentrator configuration. You need to use the CLI to configure at least
two things: an IP address on the private interface and a subnet mask if the default does not work
for the network setup.
In the following sections, we will review the CLI interface and all the nuances of making the
initial configurations of the Concentrator such as the initial interface configuration and routing
configurations.
Starting the CLI
To get started with configuration, use the enclosed blue or black console cable to attach a laptop to
the Concentrator via a serial port. Next, set up a communications program, such as HyperTerminal,
to communicate through the correct serial port on 8N1 (8 data bits, no parity, and 1 stop bit) with
no flow control. These are the same settings used to talk to a router, switch, or firewall.
The VPN 3000 series is one of the few Cisco devices that doesn’t come with an
RJ45 console connector. In the absence of the bundled console cable, you can
connect to the VPN Concentrator using two standard db9 to rj45 converters and
a standard Ethernet cable.
The Concentrator has at least two sides and might have three, depending on
the model purchased. The inside, or private, interface is the trusted part of the
network. When attaching cables to the Concentrator, make sure that the appropriate cables are plugged into the appropriate interface.
If the communications program has been configured correctly, when you press Enter, you
will be prompted to enter a login, where the default name is admin, followed by a prompt for
a password, where the default is also admin:
Login: admin
Password:
If the VPN Concentrator has no configuration, it will display the CLI Quick Configuration Wizard.This wizard will walk you through enough of the configuration to make your Concentrator
Using the CLI for Initial Configuration
387
available for basic use. The Quick Configuration Wizard uses the same format as the CLI configuration tool on the VPN 3002 hardware client. The wizard will prompt the administrator for
information and provide a default suggested value in square brackets. Pressing the Enter key
without entering a value sets the default value and moves to the next option.
The Quick Configuration Wizard can be aborted after the private interface has been configured. At that point, the VPN Concentrator will be available to configure via the Web configuration interface.
To provide the basic VPN concentrator configuration using the Quick Configuration Wizard, follow these steps:
1.
Set the current system time:
Welcome to
Cisco Systems
VPN 3000 Concentrator Series
Command Line Interface
Copyright (C) 1998-2003 Cisco Systems, Inc.
-- : Set the time on your device. The correct time is very important,
-- : so that logging and accounting entries are accurate.
-- : Enter the system time in the following format:
-- :
HH:MM:SS. Example 21:30:00 for 9:30 PM
> Time
Quick -> [ 11:42:38 ]
2.
Set the current system date:
-- : Enter the date in the following format.
-- : MM/DD/YYYY Example 06/12/1999 for June 12th 1999.
> Date
Quick -> [ 09/28/2003 ]
3.
Select the time zone:
-- : Set the time zone on your device. The correct time zone is very
-- : important so that logging and accounting entries are accurate.
-- :
-- :
Enter the time zone using the hour offset from GMT:
-12 : Kwajalein
-11 : Samoa
-10 : Hawaii
-9 : Alaska
388
Chapter 9
-- :
-8
-- :
-4
Atlantic
-- :
-1
-- :
+3
-- :
+5
-- : +6.5
-- : +9.5
Is.
Configuring the VPN Concentrator
: PST
: Atlantic
:
:
:
:
:
Azores
Kuwait
Karachi
Rangoon
Adelaide
-7 : MST
-3 : Brasilia
0
+3.5
+5.5
+7
+10
:
:
:
:
:
-6 : CST
-3.5 : Newfoundland
GMT
+1 : Paris
Tehran
+4 : Abu Dhabi
Calcutta +5.75 : Kathmandu
Bangkok
+8 : Singapore
Sydney
+11 : Solomon Is.
-5 : EST
-1 : Mid+2
+4.5
+6
+9
+12
:
:
:
:
:
Cairo
Kabul
Almaty
Tokyo
Marshall
> Time Zone
Quick -> [ -6 ]
4.
Enable or disable daylight savings time observation:
1) Enable Daylight Savings Time Support
2) Disable Daylight Savings Time Support
Quick -> [ 1 ]
5.
Set the IP address of the private network interface:
This table shows current IP addresses.
Intf
Status
IP Address/Subnet Mask
MAC Address
----------------------------------------------------------------------------Ether1-Pri|Not Configured|
0.0.0.0/0.0.0.0
|
Ether2-Pub|Not Configured|
0.0.0.0/0.0.0.0
|
----------------------------------------------------------------------------DNS Server(s): DNS Server Not Configured
DNS Domain Name:
Default Gateway: Default Gateway Not Configured
** An address is required for the private interface. **
> Enter IP Address
Quick Ethernet 1 -> [ 0.0.0.0 ] 10.0.10.190
At this point, the CLI will pause for a moment while the interface is brought up.
6.
After the interface is initialized, enter the subnet mask for the private interface:
Waiting for Network Initialization...
Using the CLI for Initial Configuration
389
> Enter Subnet Mask
Quick Ethernet 1 -> [ 255.0.0.0 ]
7.
Set the interface speed:
1) Ethernet Speed 10 Mbps
2) Ethernet Speed 100 Mbps
3) Ethernet Speed 10/100 Mbps Auto Detect
Quick Ethernet 1 -> [ 3 ]
8.
Select the interface duplex:
1) Enter Duplex - Half/Full/Auto
2) Enter Duplex - Full Duplex
3) Enter Duplex - Half Duplex
Quick Ethernet 1 -> [ 1 ]
9.
Set the interface maximum transmission unit:
> MTU (68 - 1500)
Quick Ethernet 1 -> [ 1500 ]
At this point, enough of the configuration has been entered to allow a user to configure the
VPN Concentrator from the local subnet using the Web interface. The entire VPN Concentrator can be configured from the CLI. You could select option 4 in step # 10 to configure
the entire VPN Concentrator from the wizard. However, we will concentrate on the Web
interface. Administrators should not have great difficulty moving from the CLI to the Web
and back since Altiga and Cisco took great care to ensure that the main structures of the
CLI and Web interfaces are identical.
10. To save the configuration, select 3, then select 5 to exit and log off:
1)
2)
3)
4)
5)
Modify Ethernet 1 IP Address (Private)
Modify Ethernet 2 IP Address (Public)
Save changes to Config file
Continue
Exit
Quick -> 3
1) Modify Ethernet 1 IP Address (Private)
2) Modify Ethernet 2 IP Address (Public)
3) Save changes to Config file
Chapter 9
390
Configuring the VPN Concentrator
4) Continue
5) Exit
Quick -> 5
11. Sometimes it is not possible to connect the VPN Concentrator and the configuration PC to
the same IP subnet. In this case, you might need to configure a static route to permit Web
access. To do this, log back on to the CLI. You will no longer be in the CLI Quick Configuration Wizard:
Login: admin
Password:
In the standard CLI, each menu has a title associated with it. The title of the
opening menu is Main, as you can see at the command prompt at the very bottom of the menu screen. The cursor will be sitting next to the text-based arrow
(->), waiting for a number to be entered.
12. From the main menu, select option 1:
Welcome to
Cisco Systems
VPN 3000 Concentrator Series
Command Line Interface
Copyright (C) 1998-2003 Cisco Systems, Inc.
1)
2)
3)
4)
5)
6)
Configuration
Administration
Monitoring
Save changes to Config file
Help Information
Exit
Main ->
13. From the Configuration menu, select option 2:
1)
2)
3)
4)
Interface Configuration
System Management
User Management
Policy Management
Using the CLI for Initial Configuration
5) Back
Config ->
14. From the System Management menu, select option 4:
1) Servers (Authentication, Authorization, Accounting, DNS, DHCP, etc.)
2) Address Management
3) Tunneling Protocols (PPTP, L2TP, etc.)
4) IP Routing (static routes, OSPF, etc.)
5) Management Protocols (Telnet, TFTP, FTP, etc.)
6) Event Configuration
7) General Config (system name, time, etc.)
8) Client Update
9) Load Balancing Configuration
10) Back
System ->
15. From the Routing menu, select option 1:
1)
2)
3)
4)
5)
6)
7)
8)
9)
Static Routes
Default Gateways
OSPF
OSPF Areas
DHCP Parameters
Redundancy
Reverse Route Injection
DHCP Relay
Back
Routing ->
16. Select option 1 to add a static route:
Static Routes
------------Destination
Mask
Metric Destination
-----------------------------------------------------------No Static Routes Configured
1) Add Static Route
2) Modify Static Route
3) Delete Static Route
391
392
Chapter 9
Configuring the VPN Concentrator
4) Back
Don’t overthink the routing at this point. You need only one route to the configuration PC’s local subnet so you can log on to the Web interface. Point the
next hop to the nearest router in the PC’s direction.
17. Enter the network address and subnet mask:
> Net Address
Routing -> 10.0.11.0
> Subnet Mask
Routing -> 255.255.255.0
18. Select option 1 to set the next hop as an address:
1) Destination is Router
2) Destination is Interface
Routing ->
19. Set the next hop address and metric:
> Router Address
Routing -> 10.0.10.1
> Route Metric (1 - 16)
Routing -> [ 1 ]
20. The new static route is displayed. Select the Back option several times until you reach the
Main menu. The options will be numbered 4, 9, 10, and 5:
Static Routes
------------Destination
Mask
Metric Destination
-----------------------------------------------------------10.0.11.0
255.255.255.0
1 10.0.10.1
1) Add Static Route
Using Web Quick Configuration Mode
393
2) Modify Static Route
3) Delete Static Route
4) Back
Routing ->
21. Select option 4 to save the configuration, then option 6 to log off:
1)
2)
3)
4)
5)
6)
Configuration
Administration
Monitoring
Save changes to Config file
Help Information
Exit
Main -> 4
1)
2)
3)
4)
5)
6)
Configuration
Administration
Monitoring
Save changes to Config file
Help Information
Exit
Main -> 6
Done
.The public interface filters HTTP (Web browser) traffic by default. This prevents
someone from administering the VPN Concentrator from the Internet. If administration from outside the network is necessary to initially configure the Concentrator, the filter on the public interface will need to be modified to allow this access.
Using Web Quick Configuration Mode
Once the Concentrator has been configured with an IP address and routing using the CLI Quick
Configuration Wizard, as described in the previous section, you can log in to it via a Web browser
on a PC or laptop. The login is the same as it is for the CLI—the username and password are both
394
Chapter 9
Configuring the VPN Concentrator
admin. (The login screen is similar to the one that was used by the Hardware Client, discussed in
Chapter 8.
When you access a VPN Concentrator with a basic configuration, it recognizes that more
needs to be configured before it is fully functional. Just as an IOS router goes into Setup mode
when you start it, the Concentrator will offer to go into Quick Configuration mode:
After you’ve made configuration changes and saved them, the only way to go back
into Quick Configuration mode again is to wipe the configuration and reboot.
Click the Quick Configuration mode link to configure the minimal parameters to make the
Concentrator functional. (Initial configuration via Quick Configuration mode is optional; it is not
Using Web Quick Configuration Mode
395
required.) As described in the following sections, the utility will guide you through configuring
physical interfaces, system information, tunnel-creation method, address assignments, authentication, and the admin password.
Configuring Physical Interfaces
The first Quick Configuration screen—the Quick Configuration Interfaces screen—allows you
to configure Concentrator interfaces, as shown in Figure 9.1. A VPN Concentrator can have
three physical interfaces, although the example shown is from a model 3005, which has two
interfaces. (WAN interfaces are referenced in the figure but are no longer sold by Cisco.)
FIGURE 9.1
The Quick Configuration Interfaces screen
Each interface is shown with its current status and any IP configuration. Click an interface
to make changes to it.
Be careful when making changes to the interface to which you are currently
connected. You might inadvertently disconnect yourself from the Concentrator
and be forced back to the CLI interface for configuration.
Setting System Information
The System Info screen, shown in Figure 9.2, is extremely important if you will be using digital
certificates. Here, you set the time, a system name, domain information, and the address of the
device serving as the default gateway.
If you’re using certificates, it is very important that the correct time is set. Also, establishing
system and domain information is required for the certificate process.
396
Chapter 9
FIGURE 9.2
Configuring the VPN Concentrator
The Quick Configuration System Info screen
The certificate process will be explained in the “Configuring the Use of IPSec
Digital Certificates” section later in this chapter.
Setting the Tunnel-Creation Method
The Quick Configuration screen presents three methods of creating tunnels. The VPN Concentrator supports tunnels made with PPTP and L2TP. If one or both of these are enabled, you must
decide if encryption is required or optional. MS-CHAP will be required to establish an
encrypted tunnel with either of these methods. The third option is to use IPSec to build tunnels.
Any or all of the protocols may be enabled at this time.
Setting Address Assignment
When a client creates a tunnel to the VPN Concentrator, it needs an address for the tunnel. The
Quick Configuration Address Assignment screen, shown in Figure 9.3, allows you to select the
way in which the client gets the address.
The first method listed, Client Specified, is usually the least desirable because it gives the
administrator no control over the addressing on the local network. Also, client-specified
addressing doesn’t work with most implementations of IPSec and is usually reserved for tunnels
using Microsoft technologies.
The remaining three methods are all valid methods for use with IPSec and are easy to configure. If you are using an authentication, authorization, and accounting (AAA) server, IP
addresses to be used can be configured on a user-by-user basis.
Using Web Quick Configuration Mode
FIGURE 9.3
397
The Quick Configuration Address Assignment screen
Cisco uses AAA to standardize the security service configuration, regardless of
which type of security is implemented.
You can also use DHCP to provide addressing. If a DHCP server is used in the organization,
select the pool option and specify the IP address of the DHCP server. If a pool server is not in
use, you can configure a local pool on the Concentrator.
On this screen, you can choose multiple address-assignment methods. Then the Concentrator will apply the rules from the top down. If the preferred method of providing addresses is to
use the per-user or DHCP methods, it is advisable to also create a local DHCP pool, just in case
the first method is unreachable or unavailable. Make sure that the IP addresses of the two or
three methods don’t overlap.
Configuring Authentication
If your organization has an AAA server, such as CiscoSecure Access Control Server (ACS), you
can configure the Concentrator to talk to the server to authenticate incoming tunnel requests.
Figure 9.4 shows the Quick Configuration Authentication screen.
FIGURE 9.4
The Quick Configuration Authentication screen
398
Chapter 9
Configuring the VPN Concentrator
If there are many users, using an AAA server is highly recommended. It helps
reduce the number of passwords users are required to remember and it
doesn’t require administrative intervention when a user changes a password.
If you specify an external server for authentication, more options will appear so that you can
configure necessary attributes, such as the server IP address, hostname, timeout length, and
number of retries. If a computer running Windows NT will be used for authentication, be sure
to specify the computer name in the Domain Controller Name field.
The Concentrator GUI offers RADIUS communication, but only the more recent
versions offer TACACS+. If you want to use TACACS+ but the Concentrator
doesn’t list it as an option, you will need to upgrade to the latest version of the
software.
If you are not using an AAA server, you can configure the Concentrator with a local authentication database (just as a router can have a local database). You will need to populate the database
with appropriate user and group information so users can establish tunnels. When you are creating
user and group information, Quick Configuration will prompt you for a group name and password.
Note that the internal database is limited to a maximum of 100 users and groups. If you need more
than 100 users and/or groups, you will have to establish an external authentication method. When
configuring the group and password, a group name fulfills the same function as a username.
FIGURE 9.5
IPSec Group Configuration screen
Configuring User and Policy Management
399
Setting a Group Name
For IPSec to work, a group and group password must be selected. This group ties a user to a particular set of parameters including encryption options, IP addressing, and access times. The
quick configuration prompts you for this information, as shown in Figure 9.5. It is not necessary
to configure at group as part of the quick configuration, and is therefore recommend that you
leave the group blank until the quick configuration is complete.
Changing the Admin Password
The last screen in Quick Configuration—the Quick Admin Password screen—deals with the
admin password, as shown in Figure 9.6. Anyone who has set up a VPN Concentrator knows
what the default username and password are. For security purposes, it is strongly recommended
that a Concentrator not be placed into production until this password has been changed.
FIGURE 9.6
The Quick Configuration Admin Password screen
Along with admin, other insecure passwords for a piece of Cisco equipment include cisco,
sanfran, and sanjose. (Of course, any passwords that use all letters and form a word, as well
as static passwords, are insecure.)
While versions 3.0 and later of the Concentrator software allow for password
recovery, older versions do not, requiring that the Concentrator be shipped to
the factory for it to be reset.
Configuring User and Policy Management
Once the bare-bones configuration is set up through Quick Configuration, the VPN Concentrator may be accessed but it isn’t fully utilized. To fully utilize the Concentrator, you need to
tell it who can create tunnels. The most efficient way of doing this is by configuring groups and
users from the Main mode, rather than the Quick Configuration mode. In this mode, you can
choose administration options by clicking hyperlinks in the GUI (Web browser–based) window.
400
Chapter 9
Configuring the VPN Concentrator
In the following sections, we will discuss the basic configuration details of the VPN Concentrator. We will look at the setup of users and groups, some of the rules for access and how they
are set up and applied, and system load balancing for redundancy. Larger networks will certainly benefit from our discussion of updating clients automatically, and no network can be considered complete unless we implement the proper security, thus we will cover the basics of the
integrated stateful firewall feature set.
Navigating the GUI
The VPN Concentrator Manager window has three main frames:
Menu choices In the left frame, you’ll see a menu with three main choices: Configuration,
Administration, and Monitoring. Clicking Configuration expands the Configuration menu to
show additional options. Clicking User Management shows the options in that category:
The structure here is identical to the structure found inside the CLI. The difference is that rather
than typing numbers to change from one menu to another, you just click the mouse.
Settings and information The bottom-right frame—the largest one—is where you set configuration options and view information. At the very top of the frame, you can see the path taken
to get to this location, like this:
If there has been a material change to the configuration, the Concentrator will remind you that a
save is needed by displaying the following message and icon at the top of this frame (a material
change is one that will severely affect how the Concentrator operates if it reboots, such as changing
an IP address):
Toolbar The toolbar is in the top frame in the browser window. It shows the name of the management application, VPN 3000 Concentrator Series Manager, and who you are currently
logged in as. There are also quick selections for Help, Logout, and the three main menu choices.
While the GUI is where most people prefer to configure the Concentrator, it is
possible to configure it from the CLI. This book will focus on using the GUI
(after initial configuration). If you’re interested in the corresponding CLI techniques, when a task is done in the GUI in the Configuration section, then it will
be done in the same section in the CLI.
Configuring User and Policy Management
401
Setting Up Groups
The VPN Concentrator comes with a default group called the base group. A group is used to
gather users into a single entity for administration. It is a lot easier for an administrator to change
the properties of a group and have the changes apply to all the users in the group than it is to
change the properties of multiple users.
You can add groups to the Concentrator to suit the needs of your organization. Each
administrator-created group is placed as a member of the system-wide base group. If you create users and do not place them into an administrator-created group, those users are members
of the base group directly. If you delete an administrator-created group, all that group’s users
will be placed in the base group (their member profiles are not deleted).
In the following sections, we’ll see how to create groups, set general group properties, and
configure IPSec properties for a group.
Creating Groups
To add a group, from the main VPN Concentrator Manager window, select Configuration User Management Groups. You’ll see the list of existing groups and actions you can take, as
shown in Figure 9.7.
FIGURE 9.7
The Groups screen
If you click the Add Group button under the Actions heading, the form shown in Figure 9.8
appears. On the Identity tab, supply a group name, specify a password (which is entered twice
for verification), and choose the authentication type. The name of the group is important if you
are using digital certificates because the group name on the Concentrator must match the Organizational Unit (OU) name on the client’s identity certificate. For the authentication type, internal authentication is always acceptable, assuming the database isn’t full. Other options include
Windows NT authentication and a RADIUS server. TACACS+ is supported on newer versions
of Concentrator software.
402
Chapter 9
FIGURE 9.8
Configuring the VPN Concentrator
Adding a Concentrator group
To modify an existing group, click the group you wish to modify on the Groups
screen to highlight it, and then click the Modify Group button.
You can continue to configure the group by setting properties on the other tabs of the group
configuration form, as described in the following sections.
Setting General Group Properties
When you create a group, by default, it inherits the properties of the base group. Usually, you
will want to customize some of the properties to suit the members of the group. For example,
telecommuters working normal business hours in customer service might have restrictions
placed on their access hours, but traveling salespeople might need to be able to access their
e-mail at all hours.
To customize group properties, click the General tab on the group form. You’ll see the General Parameters options, as shown in Figure 9.9.
You can configure the following options:
Access hour restrictions (choices are No Restriction, Never, Business Hours, and any custom policies you have defined).
Number of simultaneous logins (three is the default).
Minimum number of characters in the password.
Whether the password requires non-alphabetic characters (deselecting Alphabetic Only
will require at least one non-alphabetic character in each password).
Configuring User and Policy Management
An idle timeout, in minutes (30 is the default).
Maximum connect time, also in minutes
Traffic filter
WINS information
DNS information
Strip authentication realm
DHCP Network Scope for address assignment
403
The Access Hours and Filter parameters can be configured through the Configuration | Policy Management section, as described in the “Configuring Access Hours and Filters” section
later in this chapter.
FIGURE 9.9
General group properties
404
Chapter 9
Configuring the VPN Concentrator
Configuring IPSec and Remote Access Properties for a Group
The IPSec tab on the group form allows you to configure IPSec and Remote Access properties
on a group-by-group basis.
To customize group properties, click the IPSec tab on the group form. You’ll see the IPSec
Parameters and Remote Access Parameters page, as shown in Figure 9.10.
FIGURE 9.10
IPSec and Remote Access group properties
Seven options are available for configuration on this tab. All of them deal directly with the
IPSec tunnel parameters or the authentication and authorization of the tunnel. Table 9.1 outlines the use of some of the attributes.
Configuring User and Policy Management
TABLE 9.1
405
Important IPSec Group Attributes
Attribute
Description
IPSec SA
Assigns a Security Association (SA) to the group.
IKE Peer Identity
Validation
The VPN Concentrator can use an identity certificate to validate the
user in addition to normal passwords. Three options are available:
Required, in which the client must have a proper ID certificate; If
Supported By Certificate, in which the client is authenticated if it presents appropriate certificate information; and Do Not Check, which
means ignore all ID certificate information.
Tunnel Type
This allows you to chose the tunnel type. There are two options:
Remote Access, which is the typical setting for hardware and software VPN clients; and LAN-to-LAN, which is reserved for whole network type connections and is typically used between two VPN 3000
Concentrators. If you select LAN-to-LAN, the IPSec SA attribute
described above is ignored. LAN-to-LAN tunnels are discussed in
greater detail in the “Configuring LAN-to-LAN IPSec” section later in
this chapter.
Group Lock
If this attribute is unchecked, the Concentrator will not enforce the
association between an authenticated user and their membership in
this group. Any authenticated user will be able to use these IPSec
group parameters even if they are not specifically configured as a
member of this group.
Authentication
This selects the destination server type for authentication of users
who attach using this group.
Authorization Type
This selects the destination server type for authorization of users
who attach using this group.
DN Field
This tells the Concentrator which certificate field to use as the username when authenticating and authorizing clients.
Configuring Client Properties for a Group
The Client Config tab is an extension of the attributes of the IPSec tab. In fact, previous versions
of the Concentrator grouped the Client Config and IPSec attributes together under one tab.
To customize client properties, click the Client Config tab on the group form. You’ll see the
Client Configuration Parameters options page, as shown in Figure 9.11.
406
Chapter 9
FIGURE 9.11
Configuring the VPN Concentrator
Client Config group properties
Six options are available on this tab. The tab is broken down based on the type of client. The
top section deals with the Cisco Client, the middle section sets information for the Microsoft
Client, and the bottom section has attributes that apply to both. Table 9.2 outlines the use of
some of the attributes
TABLE 9.2
Important Client Configuration Group Attributes
Attribute
Description
Allow Password Storage
on Client
This attribute forces the client to destroy any saved client passwords.
IPSec over UDP
Allows the client to connect by encapsulating the ESP data into a UDP
packet. This method is often used when operating through NAT.
IPSec over UDP Port
Sets the IPSec over UDP port number.
Configuring User and Policy Management
TABLE 9.2
407
Important Client Configuration Group Attributes (continued)
Attribute
Description
Split Tunneling Policy
This attribute has two basic settings: Tunnel Everything, which sends
all data via the tunnel, and Only Tunnel Networks In List, which sends
only specific networks via the tunnel. Allow The Networks In List To
Bypass The Tunnel is a suboption of the Tunnel Everything attributes.
It is the opposite of the Only Tunnel Networks In List option.
Split Tunneling
Network List
Selects a preconfigured list of networks for evaluation by the Split
Tunneling policy. These lists are configured from the Configuration
| Policy Management | Traffic Management | Network Lists menu.
Split DNS Names
When using split tunneling, you might wish to use the tunnel to
resolve certain domain names while allowing others to be resolved
normally. This attribute is a comma-separated list of domain names
that will use the tunnel.
Newer versions of the Concentrator software support a feature called local LAN
access. This allows split tunneling to the point that the client can access local
LAN objects so that a user can be connected remotely and print locally to a network printer.
How and when should I configure split tunneling?
Like many features, the use and configuration of split tunneling varies widely. If you ask 10 system administrators if and how you should configure split tunneling, you’re likely to get 10 different answers. Here are some things to consider:
Security
split tunneling is always a security issue. By default, split tunneling is disabled and all network
traffic is delivered via the tunnel. Using split tunneling opens the door for bypassing security
measures. Two primary issues arise. First, most corporate network infrastructures include
security features such as firewalls and Web filtering. Use of split tunneling might allow a user
to circumvent the protections of the firewall and the restrictions of the Web filters. Second, if
the client is permitted to contact other network devices independently of the tunnel, it becomes
a potential entry point for hackers or worms to piggyback their data on the client’s tunnel to
gain access to a network that is otherwise very secure.
408
Chapter 9
Configuring the VPN Concentrator
Cisco has addressed the second issue to some extent with the addition of support for thirdparty and built-in firewalls in the VPN client.
Performance
On the other side of the coin is the performance trade-off. Forcing traffic that is not ultimately
destined for the other end of the tunnel wastes both bandwidth and encryption capacity.
Assume a telecommuting client takes a lunch break and starts surfing the Web at an average
rate of 56Kbps. Further assume that the client’s company is using the same service for both
VPN traffic and general Web access. That user will waste about 114Kbps (56K in + 2.5% IPSec
overhead + 56K out) of Internet access bandwidth that could be avoided with split tunneling.
Additionally, VPN Concentrators have a limited encryption capacity. This user’s Web surfing
would have consumed about 1 percent of the capacity of a 3005 only to have the 3005 tear
down the traffic and send it back out unencrypted anyhow.
Politics and Support
A third factor that rarely gets considered is the political and support issues of split tunneling.
Often VPN clients are not just internal corporate employees. Many times, VPN access is opened
to business partners and independent contractors. In this case, consider if it is appropriate for
the client to be sending personal or unrelated data via the tunnel. Where will the support
responsibilities fall when the VPN configuration causes problems with other services? Does the
administrator have the legal or political right to enforce firewall and security configurations on
a PC system that their company does not own?
For example, I recently visited a customer that was doing independent transcription work for
a local hospital. The hospital had installed a Cisco VPN 3030 and expected the client to use the
tunnel to pick up and drop off materials. Most of the hospital’s contractors were individuals
who worked from home on a single PC. However, this customer was a small company with an
internal network and server. The hospital had decided to disable split tunneling since the VPN
tunnel was used only to pick up and drop off data. The hospital had the expectation that the
contractors would connect and disconnect as needed. Since split tunneling was disabled, the
customer lost access to their file server every time they tried to connect to the hospital. Should
I send the bill to my customer or to the hospital?
Suggestions
Try to classify users into groups based on the concerns listed above. Balance your need for
security with the costs of supporting the client and providing additional hardware and network
capacity. Consult your company’s computer usage and security policies. Often third-party computer users are bound by a security policy as part of a contract. This might authorize the administrator to install and enforce rules on the contractor’s system. Have a clear understanding of
the political ramifications for support and security issues with each of these groups of users.
Configuring User and Policy Management
409
Setting Up Users
In addition to adding and configuring groups to the Concentrator, you can also add and configure users. To add a user, from the main VPN Concentrator Manager window, choose Configuration | User Management | Users. On the Users screen, click the Add button to create a new
user. You can also select an existing user and click the Modify button to change that user’s properties or click the Delete button to remove that user.
After you click the Add or Modify button, you’ll see the user form, as shown in Figure 9.12.
The username and password configured here are what the user will need to enter into the
VPN client when the user wants to create a tunnel. This username and password function the
same as a shared secret key for IPSec (discussed in Chapter 7).
In addition to forcing the change of a password, you can change which group the user
belongs to. (As noted earlier, users belong to the base group by default.) You can also assign a
static IP address for this user whenever a tunnel is created.
Remember that there is a limit of 100 total objects that can be placed in the internal authentication database. If you set up more than 100 users and/or groups, you’ll need to establish an
external authentication method, as described in the next section.
FIGURE 9.12
Configuring a user
Configuring an Authentication Server
Rather than configuring the internal user database, you can configure the VPN Concentrator to
use an external authentication server. To set up an authentication server, from the main VPN
410
Chapter 9
Configuring the VPN Concentrator
Concentrator Manager window, select Configuration | System | Servers | Authentication. You’ll
see a list of currently configured authentication servers and the actions you can perform:
The order that the servers are shown is the order in which they will be tried. It is a good idea to
configure the internal database with administration logins. That way, if the authentication server is
unavailable for some reason, an administrator will still be able to authenticate. Because the order is
important, there are two buttons that allow a server to be moved up or down in the list.
To add an authentication server, click the Add button. You can modify the properties of an
existing authentication server or delete one by clicking the appropriate button.
The Test button allows you to verify that communications exist between the VPN Concentrator and the authentication server, and that the authentication server is correctly configured.
Use this testing method before putting the Concentrator into production. When you click the
Test button, you’ll be prompted to enter a username and a password. Then click OK to perform
the test. If communication between the Concentrator and the authentication server is set up correctly and the authentication server can validate the authentication request, you will see the
response “Authentication Successful,” as shown below.
Configuring Access Hours and Filters
The IT department often needs to work with the Human Resources department to determine
what users can and can’t do with their computers. Telecommuting, traveling users, and users
taking laptops home bring up new issues. How can you extend corporate policies to remote connections? Setting access hours policies and filtering traffic don’t provide total solutions, but they
do help.
Configuring User and Policy Management
411
Setting Access Hours
Configuring an access hours policy simply determines the hours that a user can create a tunnel.
A user may be authorized to create a tunnel between the hours of 6 a.m. to 7 p.m., Monday
through Friday, but not during any other time.
To set access hours, from the main VPN Concentrator Manager window, select Configuration Policy Management Access Hours then click the Add button. You’ll see the Access
Hours screen, shown in Figure 9.13.
FIGURE 9.13
Setting access hours
Access Hours Restriction Considerations
Determining the hours that a user can connect is a task best left to management. It is not
unusual for one department to want very restrictive access, while another department wants
wide-open access.
To get an initial feeling for how things can pan out, look around your company. Salespeople
tend to have a lot of flexibility, and their managers will probably request the same for access
to network resources. Customer service agents generally don’t have much flexibility, and their
managers will usually want to give them access hours that approach regular working hours
plus expected overtime.
Be careful when making recommendations regarding hours of access. It is not unusual for the
administrator to get calls on weekends and evenings to extend access for a user that needs it.
412
Chapter 9
Configuring the VPN Concentrator
Specify a name for this policy profile. Then set whether the user can or cannot access the network during the given time span and specify the starting and stopping time for each day.
After you’ve configured the access hours policy, you can assign it to users and groups by
choosing it on the General tab of the configuration form (as described in the “Setting Up
Groups” and “Setting Up Users” sections earlier in this chapter). An access hour policy will not
be put into effect automatically.
Filtering Traffic
A rule is a single statement that will allow something to be done or prevent it from happening. A rule
is what is responsible for traffic headed to UDP port 500 (ISAKMP) being permitted to enter the
Concentrator. A rule can be compared to a single line in an ACL.
The Concentrator uses rules to build filters. A filter is just a big set of permit statements. If
the traffic trying to come into the Concentrator matches one of the types of traffic that is permitted, then the packet may continue on its way. You can configure filters and place them on
physical interfaces to prevent undesirable traffic from entering the Concentrator.
You can place filters on any of the physical interfaces that the Concentrator has.
Just be careful not to filter out administrative traffic on the appropriate interface!
To add a filter, from the main VPN Concentrator Manager window, select Configuration Policy Management Traffic Management Filters, then click the Add button. You’ll see the
screen shown in Figure 9.14. Specify a name for your filter and enter a description. You can
change the settings for the Default Action, Source Routing, and Fragments options, but the
defaults are acceptable in most cases.
FIGURE 9.14
Creating a filter
Configuring User and Policy Management
FIGURE 9.15
413
Adding rules to a filter
Because the default for a filter is to drop packets, a filter with no rules in it would not allow
any traffic through. Click the Add button to add rules to the filter. You’ll see the Assign Rules
to Filter screen, as shown in Figure 9.15.
Select the available rules that you wish to include in the filter and click on the Add button. The
traffic represented here is the type that will be hitting the interface itself. For the public interface, this
will be some management traffic but mainly tunnel protocols. While the private interface can have
tunnels, it usually deals with basic traffic.
The default filter for the private interface allows HTTP traffic; the default filter for the public
interface does not. If it is necessary to configure the Concentrator from outside the trusted network, either HTTP must be allowed (which is not recommended) or a tunnel must be created
to permit this access.
Configuring Backup on the Hardware Client
The purpose of the backup server is for the VPN 3002 Hardware Clients to have an alternative location in the event that the site configured as the primary fails. Backups can be configured either by the
group on the Concentrator or in the case of a the 3002 Hardware Client, on an individual basis.
A company can have two locations that their remote users can attach to. In Figure 9.16, the
primary connection point has been configured as 192.170.1.1. If, for whatever reason, the primary is not available for default 8-second timeout period, the client will automatically switch
over to the second site 192.168.1.12. Up to 10 backup servers can be listed, and the Concentrator will try each one in succession, but only one time through, if no connections are made.
414
Chapter 9
FIGURE 9.16
Configuring the VPN Concentrator
The Backup Config
As you would expect, the backup list must be configured prior to the client connection as it
is downloaded at connection, therefore a backup server list cannot be downloaded from a
backup on the primary upon connection. Any changes made to the server will not take effect
until the next time the client connects to the primary.
Configuring Load Balancing
There’s a difference between setting up a Concentrator to back up another Concentrator and
setting up two Concentrators to share the load. Configuring a backup, or hot spare, Concentrator is accomplished with the Virtual Router Redundancy Protocol (VRRP). Configuring load
balancing involves setting up Concentrator clusters. Concentrators can do both backup and
load balancing, but not at the same time.
This section covers cluster configuration for load balancing. For information
about configuring VRRP, refer to www.cisco.com/univercd/cc/td/doc/product/vpn/vpn3000/3_6/config/iprout.htm#xtocid42.
Configuring User and Policy Management
415
Understanding Clusters
Routers, firewalls, and other static devices that support a large number of clients through a single
tunnel will attach to a specific Concentrator. This way, the administrator can distribute the processing load. This is helpful because the load varies: At a certain time, a LAN tunnel might be supporting just a few packets per second, and then a minute later, supporting thousands of packets.
Software and hardware clients also connect to Concentrators. Because of the dynamic nature
of client tunneling and the relatively small number of packets crossing the tunnel, it is advantageous to make attaching to Concentrators flexible as possible.
To recap, remote access sessions and clients can be load balanced while LAN-to-LAN connections, routers, firewalls, and other Concentrators cannot.
A cluster works as follows:
1.
Clients attach to a virtual cluster master using a virtual cluster IP address. This address
must be on the same IP network as the IP address on the cluster members’ public interfaces.
2.
The master device forwards the real IP address of a secondary cluster member, which is the
Concentrator that is currently carrying the least load.
3.
The client requests a VPN session with that device.
Redundancy rules require that devices in the cluster be able to take over for the master if it fails.
When setting up a cluster, the faster device is the one that will most likely become the cluster master. Each Concentrator model has a default priority, ranging from 1 through 10, as shown in
Table 9.3. The priority is used to determine which device will become the master when a master
is not present. For example, if a 3015 Concentrator (default priority 3) comes on line 5 minutes
before a 3080 Concentrator (default priority 9), the 3015 will remain the master; there is no
forced election. If they came up at the same time, the 3080 would become the master because it
has the higher priority. You can change the priorities as part of cluster configuration, as described
in the next section. If there is a tie, the device with the lowest IP address becomes the master.
TABLE 9.3
Load Balancing Default Priorities
Concentrator Model
Default Priority
3005
1
3015
3
3030
5
3060
7
3080
9
416
Chapter 9
Configuring the VPN Concentrator
Concentrators use the Virtual Cluster Agent (VCA) protocol to communicate with other
cluster members. Because VCA communications aren’t designed to be routed, each member of
the cluster must belong to the same IP network as every other cluster member, on both the public and private interface. For cluster communications to work, each member must allow the
VCA packets in and out. Because each interface has a filter set, you need to ensure that VCA is
allowed in and out of the Concentrator on both the public and private interfaces. Figure 9.12
(shown earlier) gives an example of changing the rules for a filter.
Configuring the Cluster
Cluster configuration is fairly easy for each member. The main point to remember is that the
configurations for the members need to support the same clients because these devices will be
doing load sharing.
To configure a cluster for load balancing, from the main VPN Concentrator Manager window, select Configuration System Load Balancing. Here, you configure several items:
Cluster IP Address This is the virtual IP address that clients initially talk to. Each cluster member needs to know this IP address in case it becomes the master.
Cluster UDP Port This is the port used for cluster communication. This port is used in the filter when VCA has been allowed. If the wrong port is specified, no communication occurs.
Encryption Should IPSec be used to encrypt the VCA communication among cluster members? All devices should have the same setting with this enabled or disabled.
IPSec Shared Secret This is the shared secret that will be used for IPSec encryption of the VCA.
You will need to enter the shared secret twice.
Enable Load Balancing
the device.
This is a check box for enabling and disabling load balancing on
Priority You can change the default priority (based on the hardware model) by changing the
number in this field.
After you’ve configured the Load Balancing screen options, click the Apply button, and load
balancing can begin. Don’t forget to save the configuration.
Configuring LAN-to-LAN IPSec
A LAN-to-LAN IPSec tunnel exists when two Concentrators are serving as the ends of a tunnel
and there is a separate IP network on each side of the tunnel. Setting up LAN-to-LAN IPSec on
routers and PIX Firewalls is part of the overall IOS IPSec configuration, however, the Concentrator deals with this setup a bit differently.
To configure LAN-to-LAN IPSec on a Concentrator, from the VPN Manager window,
choose Configuration System Tunneling Protocols IPSec IPSec LAN-to-LAN. You will
see the IPSec LAN-to-LAN screen, as shown in Figure 9.17.
Configuring User and Policy Management
FIGURE 9.17
417
The VPN Manager IPSec LAN-to-LAN screen
To add a LAN-to-LAN connection, click the Add button. You will see the screen shown in
Figure 9.18.
FIGURE 9.18
LAN-to-LAN configuration
418
Chapter 9
Configuring the VPN Concentrator
Specify the information for the new connection, as follows:
1.
In the Name field, give the configuration a name.
2.
From the Interface drop-down list, select the interface that the tunnel terminates on.
3.
In the Peer field, enter the public IP address of the peer on the other end.
4.
Choose the authentication method: digital certificate or preshared key.
5.
Configure IKE by selecting an authentication method from the Authentication drop-down list.
6.
Configure IPSec by selecting the encryption method from the Encryption drop-down list.
7.
Select the IKE proposal from the drop-down list.
8.
Check the Network Auto-Discovery box if you are unsure of the networks available locally
or remotely.
9.
Configure what type of traffic needs to be protected for the local network. Choose a network list or select the Use IP Address/Wildcard Mask Below option, then set a network in
the fields below. Take care to use a wildcard mask instead of a normal network mask.
10. Configure what type of traffic needs to be protected on the remote network by specifying
its network list or IP address and wildcard mask.
11. When each section has been configured, click Add to add the LAN-to-LAN IPSec connection.
In the next section, we will look at and some basic troubleshooting for LAN-to-LAN
connections.
Troubleshooting LAN-to-LAN Connections
Any LAN-to-LAN tunnel can have problems during setup like any other tunnel can. Check in
Administration Sessions to see if the tunnel has come up. Remember that LAN-to-LAN sessions are listed separately from administrative and remote access sessions.
If the tunnel has not come up, the issue might be related to a configuration issue. One side
might be set to use a preshared key while the other uses certificates; this would be an authentication issue. If preshared keys are used, one might have been entered incorrectly. There could
also be a routing issue, or the policies or proposals might be different. Make sure that configuration items are identical where needed.
Updating Clients Automatically
If you are responsible for the VPN connections for many users, and you discover that their VPN
software is flawed or outdated, what do you do? The correct answer is to update it. What if
those people are scattered around the country, or even around the world? No, you don’t e-mail
them a file; instead, you automatically update the client.
Understanding Automatic Client Updates
You can automatically update both software and hardware clients. When an update is sent out,
it is an IKE packet with an encrypted message detailing the update information.
Configuring User and Policy Management
419
If the update is being sent to a hardware client, the update will include the location of a TFTP
server where the client can automatically update its software. The hardware client stores images
in two locations: one is the active image, and one is the backup. The client will run a check to
ensure that the file is a valid image before marking it active and rebooting. In the event there is
a problem, an administrator can mark the backup file as active and reboot.
If you are sending the update to software clients, things get a bit tricky because users are
involved. If the client needs updating, users are told where they need to get the file. The update
location will be a Web server where you have placed the file. How does this differ from your
e-mailing the file? The IKE packet will check to see if the person is using an acceptable version
(which you specify when you configure the client update process, as described in the next section) and inform the user of the update and its location only if the version in use is not acceptable. This is easier for an administrator than keeping records of exactly which software version
is running on every remote computer.
Configuring Automatic Client Updates
There are two steps to configuring automatic client updates: enabling the process and configuring client update properties. These steps begin from the Client Update screen, accessed from
the main VPN Concentrator Manager window by selecting Configuration System Client
Update, as seen in Figure 9.19.
FIGURE 9.19
The Client Update screen
To enable the process, click the Enable link on the Client Update screen. The Enable Client
Update screen contains an Enabled checkbox. Put a checkmark in this box, and then click Apply
(see Figure 9.20).
FIGURE 9.20
The Enable screen
420
Chapter 9
Configuring the VPN Concentrator
To configure the client update process, click the Entries link on the Client Update screen. On
the Entries screen, as seen in Figure 9.21, you can start configuring the process. If there are
already client update entries listed, you will see the type of client and the acceptable version.
Click the Add button to create a new entry. This brings up the Add screen, as seen in Figure 9.22
FIGURE 9.21
The Entries screen
FIGURE 9.22
The Add Screen
There are three properties that need to be configured for client updates to work properly:
Client Type Configuring the client type is simple but exacting. You have a choice of four
options: Windows, Win9x, WinNT, or vpn3002. You must use the correct case and spelling for
the type of client you want. Using Windows as the client type means that the update will go to
both types of Windows clients—those designed for Windows 95/98/Me and those designed for
Windows NT/2000/XP. The Win9x client type is used if you want to send an update only to clients using Windows 95/98/Me. The WinNT client type is used if you want to send an update
only to clients using Windows NT/2000/XP. The vpn3002 client type is used to send update
messages to the hardware client.
Configuring User and Policy Management
421
URL The URL is the path to the update file. To activate the Launch button for the software
client notification, the path must be an HTTP or HTTPS URL. For the hardware client to get
its update, the file must be found on a TFTP server, so the URL must be a TFTP path.
Revisions When you configure the Concentrator for updating, you state which software versions are available and which versions are acceptable for current use. You might decide that 3.6
is the only version available, but one of the versions listed must match the version of the file
accessed by the path in the URL field.
Monitoring Auto-Updates
Client auto-update notifications can be tracked using the event log. The event log keeps two
types of entries that are useful for tracking updates and versions. Below is an example of two
such entries:
20 09/30/2003 04:33:52.010 SEV=5 IKE/184 RPT=1 10.0.30.99
Group [sybex] User [testuser]
Client OS: WinNT
Client Application Version: 4.0.2 (D)
37 09/30/2003 04:33:53.030 SEV=4 AUTOUPDATE/19 RPT=1
Sending IKE Notify: Autoupdating clients in group [sybex]
Client delay: 0, instID: 000003EA
The top entry is from the IKE event class. It identifies the version of the client as 4.0.2 (D)
with an OS of WinNT. The second entry is from the AUTOUPDATE event class. This log entry
explains that a client has connected and has been notified that an update is available.
Since the update process involves downloading the software from another system, there is
not a good way to determine if the client actually updated without manually associating the client with another IKE message showing a newer client version. Many syslog servers can relay statistical information to the administrator. It might be useful to forward the number of AUTOUPDATE notifications that are sent. This would be a good indication of the number of unupdated
clients still out there.
Setting Up the Stateful Firewall
The VPN client has an integrated Zone Labs firewall, which is part of the Cisco Integrated Client (CIC). CIC is a combination of the Unified Client with a firewall. This firewall can be used
to filter Internet traffic when the VPN is active.
The stateful firewall feature is a setting on the VPN client that the user might or might not
be able to turn off and on. If the firewall is on, it is on for all types of traffic. By default, it will
allow all types of traffic out but only DHCP and ESP traffic in. It is convenient but rather inflexible in its most basic form.
Another way to set up the stateful firewall is through the Concentrator and its centralized
protection policy (CPP). The CPP allows an administrator to define a set of rules for permitting
422
Chapter 9
Configuring the VPN Concentrator
and denying Internet traffic. A policy for the CPP is defined on the Concentrator, and then the
policy is pushed down to the CIC for use during the VPN connection. This allows for dynamic
settings for each firewall. Not all firewalls that can be used support this particular feature.
The Concentrator has the flexibility to require a firewall, require no firewall, or make it
optional. When the VPN tunnel is first set up, the client notifies the Concentrator which firewalls are available for use. If the optional setting is used and the client doesn’t have the correct
type of firewall, the tunnel will remain up. If a specific type of firewall is required and the client
doesn’t have it, the tunnel will be shut down.
Consider making firewalls optional during a major upgrade. This will avoid
problems if the newly installed client is unable to correctly negotiate parameters with the Concentrator.
Next, let’s have a closer look at the setup of the CIC and the CPP.
Using the CIC
The easiest way to provide firewall-based protection is to use the CIC included in the VPN client. It filters most inbound connections, excluding the VPN tunnel itself. It’s easy to set up, since
the user can just turn it on. Also, as explained in Chapter 8, you can preconfigure the client with
this setting and force it on by placing this entry in the vpnclient.ini file:
!StatefulFirewall=1
The user will not be able to change the setting from inside the VPN client.
The client PC can use regular firewall software as a firewall, and each can be configured as
necessary to keep out certain types of traffic. There are three types of external firewalls supported: ZoneAlarm, ZoneAlarm Pro, and BlackICE Defender. (The CPP currently doesn’t work
with BlackICE Defender.) Each of these may be configured to provide more flexibility to the filter than the CIC’s “always on” feature offers.
Using the CIC isn’t a popular option for security-conscious companies because the administrator does not have much control over it. One way you can retain control is to use the Zone
Labs Integrity Agent and Integrity server. You can configure the server with the policies, and the
agent on each PC will grab the policies and configure the local firewall. (For more information
about using Zone Labs products, visit the company’s Web site at http://www.zonelabs.com.)
Configuring CPP
To use the Concentrator’s CPP to set up the firewall, you must first configure the policy you
want enabled on your clients. You configure this policy in the same way that you configure policies for interface traffic, as shown earlier in Figures 9.14 and 9.15. You need to define a rule,
create a policy, link the rule to the policy and assign the policy to the CPP.
Once you have configured a new policy for the clients, you need to configure the CPP. To
configure the CPP, go to the appropriate group. Begin by selecting Configuration | Settings. On
the Settings screen, select Base Group to specify settings for the base group or select a specific
Configuring User and Policy Management
423
group to set up. Modify the group and click the tab for Client FW. In the firewall configuration
pane, select if the firewall is to be required or optional, the type of firewall, and the policy.
Among your choices for the policy are Policy Pushed, which requires you to select the filter
policy you just configured, and Policy from Server, which uses a centralized protection server
(a Zone Labs Integrity server) to provide policies to the client. If you are using a centralized protection server, you will need to tell the Concentrator where the server is located. Choose Configuration System Servers Firewall and enter the IP address of the server and the port
number for communication (see Figure 9.23).
FIGURE 9.23
The Firewall screen
As of Concentrator version 3.6, all supported firewall types are listed in the drop-down list.
For future expansion, there are also vendor and product codes that can be used. The codes for
the currently supported CIC software are shown in Table 9.4.
TABLE 9.4
Currently Supported Vendor and Firewall Codes
Vendor
Vendor Code
Product
Product Code
Cisco
1
Cisco Integrated Client
1
Zone Labs
2
ZoneAlarm
1
ZoneAlarm Pro
2
Zone Labs Integrity
3
BlackICE Defender
1
NetworkICE
3
Remember, BlackICE Defender currently does not accept information from a CPP.
424
Chapter 9
Configuring the VPN Concentrator
Configuring the Use of IPSec
Digital Certificates
IPSec is one of the methods that can be used to create tunnels between the VPN Concentrator
and the client, in addition to L2TP and PPTP. IPSec has two methods of authenticating the ends
of the tunnel: preshared keys and digital certificates.
Setting up the VPN Concentrator to use a preshared key is simple because all that is required
is the user’s password. Setting up the Concentrator to use a digital certificate is a bit more complicated because the Concentrator does not have a way to talk directly to the CA (certificate
authority). All communications must be done via a third party—a PC that has access to the CA.
In the following sections, we will have a closer look at Public Key Infrastructure. We must
have a good understanding of how to request, install, and configure a certificate as well as the
management of the user tunnels.
Introducing the Public Key Infrastructure
One of the most important concepts for certificates is the Public Key Infrastructure (PKI). The
word public here is a misnomer, however, because the infrastructure does not need to be public
at all. The PKI refers to the directory of objects linked together via certificates.
At the core of the PKI is the CA. Although there can be more than one server that is responsible
for generating certificates, there is only one root CA, which is in charge of the entire system. The
other servers that generate certificates are known as subordinate CAs or registration authorities
(RAs). So, the PKI includes the root CA, any RAs, and any users that have received a certificate from
any of the servers. An RA acts as a proxy for the CA. Figure 9.24 illustrates the PKI hierarchy.
FIGURE 9.24
The Public Key Infrastructure (PKI) hierarchy
Hierarchical
Root CA
Subordinate CA
Jane
Phil
Joe
Configuring the Use of IPSec Digital Certificates
425
When configuring a Concentrator to use certificates, the IKE authentication
needs to specify RSA Keys instead of a preshared key.
If a device gets a certificate from an RA, then it will get an identity certificate for the RA, as
well as one for the root CA. Every device in the PKI will have a copy of the root CA’s public key
so it can decrypt certificates from other devices in the PKI.
When attempting to get a certificate from a PKI, the request can often be directed only to the
CA. If there are any RAs, they will often forward the request to the CA, but this usually defeats
the purpose of placing RAs in the PKI in the first place. If the CA is handling all the requests,
there will be significant delay in large networks. Many certificate server implementations allow
the server administrator to specify that if a request states it is to be handled only by the CA, that
request will be dropped.
Requesting and Installing Concentrator Certificates
You would choose to use digital certificates because you need to verify both ends of the tunnel,
but there are too many devices to make using preshared keys a viable option. The CA fills the
role of a trusted third party and can be hosted in house, or the service can be bought on a
certificate-by-certificate basis. The standard for certificates is X.509.
Several vendors have CA products that can provide certificates to Cisco networking devices
as well as to PCs. The CA that comes with Windows 2000 Server instantly became one of the
most popular products of this type when Windows 2000 was released. In addition, Entrust,
Verisign, and Baltimore Technologies offer CA products.
Each device that wishes to communicate securely will need to have a certificate installed on
it. Each device will need to transfer information to the CA to request the certificate. The standard for the method of communication to the CA is called Public Key Cryptography Standard
#10 (PKCS #10).
Once the PKCS #10 certificate request is sent to the CA, the CA needs to run through several
steps before a certificate can be sent back to the requesting device. The first thing the CA needs
to do is determine that the request came from a source that should be receiving a certificate.
There are a couple of ways to do this:
The administrator of the CA will often set the CA up so that requests are approved manually. CAs have an area where pending certificate requests reside until they are approved
or discarded.
The CA might require a password before generating the certificate. This method works well
with routers and firewalls.
Once the request has been authenticated, the PKCS #10 is turned into an identity certificate.
An identity certificate identifies a particular device. The PKCS #10 is combined with some information about the CA, and a hash is generated. The hash is then encrypted using the CA’s private
key, and the hash is added to the identity certificate. Finally, the certificate is sent to the
requestor. This process is illustrated in Figure 9.25.
426
Chapter 9
FIGURE 9.25
Configuring the VPN Concentrator
Generating the certificate
PKCS#10
Certificate
Authority Info
Hash
Algorithm
JH54G63U
Private
Key
Encryption
Algorithm
Certificate: 123456
Bob
K2345678
4ehIDx67NMop9
Once the Concentrator gets the certificate, it extracts the CA’s public key from the CA ID
certificate, assuming it has a copy of the certificate for the CA. It then decrypts the two certificate hashes and verifies their authenticity.
Now that we’ve taken a look at the overall process, let’s see how to actually configure certificate requests and installations for the VPN Concentrator.
Configuring the Request for a Concentrator Certificate
To configure the request for a certificate for the Concentrator, from the main VPN Concentrator
Manager window, select Administration Certificate Management Enrollment. You’ll see the
form shown in Figure 9.26. This form can be used to generate certificates for both IPSec and SSL.
You must fill in the information needed by the CA before it can generate the certificate:
Common Name (CN) The CN of an object is what it is known as. A user might be known by
the username, and a computer might be known by a serial number or asset tag number.
Organizational Unit (OU) An OU is normally a subdivision of the Organization. If the Organization is large, the OU might be a division. If the Organization is small, the OU might be a
department.
Organization (O) An O refers to the entire organizational entity. Cisco would be an O, while
Sales would be an OU under Cisco.
Locality (L) The L is normally the city the device resides in, but it could be a county, township,
or some other method of identifying a geographic location.
Configuring the Use of IPSec Digital Certificates
FIGURE 9.26
427
Creating a certificate request
State/Province (SP) The SP is usually used to define the state, province, county, or other political division.
Country (C) The C is the name of the country in which this device resides.
Fully Qualified Domain Name (FQDN) The FQDN refers to the name of the device. An
example of a server name would be testbox.sales.cisco.com.
Key Size Sets the key size for the generated RSA/DSA key pair. Realize that while most
PKI implementations support RSA keys, many do not support another option offered here:
Directory System Agent (DSA). Verify with the administrator of the CA what type of key
should be used.
The key that is generated is actually a set of keys. There will be a public key and a private
key. The private key doesn’t go anywhere; it resides on the Concentrator. The public key is
included with the information that was entered into the fields and sent to the CA. The keys
are used to encrypt traffic to the other device, using that device’s public key. If a public key
is used to encrypt traffic, only the linked private key may decrypt it. This is called asymmetric encryption.
428
Chapter 9
Configuring the VPN Concentrator
After you’ve filled in the certificate request form and clicked OK, the VPN Concentrator
Manager will open another browser window that contains the information that the CA needs
to create a new certificate, as in the example here:
Highlight all of the information shown in this window and copy it. You will paste it into
another browser window shortly. For safety’s sake, you might want to paste it into a text file
for temporary storage.
Generating the Concentrator Certificate
After you’ve copied the certificate request information generated by the Concentrator management utility, point the browser to the CA’s URL. The CA used in this example is the one
that comes with Windows 2000 Server. Figure 9.27 shows the Microsoft Certificate Services Welcome screen and choices. Select the Request a Certificate radio button and click
Next to continue.
FIGURE 9.27
Choosing to request a certificate from the CA
The next page asks how the request should be input. You’ll use this form to generate the certificate for the PC.
Since the data was copied from the Concentrator, choose to use a Base64 Encoded PKCS
#10 file. Then paste the PKCS #10 information that the VPN Concentrator Manager generated when you configured the request (as described in the previous section) into the Saved
Request box, as shown in Figure 9.28. There is also the option to browse for a text file that
contains the necessary information. Other options allow enrollment using a form and
smart-card enrollment.
Configuring the Use of IPSec Digital Certificates
FIGURE 9.28
429
Pasting the PKCS #10 into the CA’s certificate request form
In addition to starting the certificate request process, the CA’s certificate request screen
is also used to request a Certificate Revocation List (CRL). Occasionally, it is necessary to
terminate a certificate before it would naturally expire. A CRL is a file generated by the CA
that states which certificates are no longer valid, using the serial number of the certificate
to uniquely identify the certificate in question. While updating the CRL is not a required
action, it should be done. How often the CRL should be updated depends on your organization’s security requirements.
When a connection is first made, the peers will request a new copy of the CRL from the CA.
Each peer then makes sure that the certificate it was just given isn’t on the CRL. Some equipment is capable of ignoring an unavailable CRL while others must have a new CRL for the connection to continue. This reduces the chance that a stolen certificate and denial of service attack
on the CA can allow someone into your network. CRL requesting is on by default and requires
HTTP access to the CA. The CRL distribution point is usually included in the certificate
received from the CA, eliminating some configuration steps.
Downloading the Concentrator Certificate
Once the CA has generated the certificate, it must be downloaded. The next page has two
options for certificate retrieval: DER encoded or Base64 encoded. Choose Base64 encoded for
the Concentrator.
At this point, the certificate for the Concentrator must be downloaded to the PC. Make sure
that it is placed in a secure location; there is no sense in placing it in a directory that everyone
in the company can access.
Each certificate is a separate download, so be sure to collect the identity certificate, the root
CA certificate, and the CRL. When using the Windows 2000 CA, collect the Concentrator ID
certificate first and then click the hyperlink marked Home in the upper-right corner of the
screen to continue downloading the remaining files.
430
Chapter 9
Configuring the VPN Concentrator
Installing the Concentrator Certificate
After the certificate has been downloaded, it must be installed on the Concentrator. From the
main VPN Concentrator Manager window, choose Administration Certificate Management Install. You’ll see the screen shown in Figure 9.29.
FIGURE 9.29
Installing the certificate on the Concentrator
Choose the type of certificate downloaded, enter any required password, and tell the browser
where the certificate can be found.
Viewing the Concentrator Certificate
Once the certificate has been installed, it is occasionally useful to be able to check something on
the certificate, such as verifying the expiration date. It might also be necessary to install a new
CRL or even delete the certificate.
To view Concentrator certificates, from the main VPN Concentrator Manager window,
choose Administration Certificate Management Certificates. As shown in Figure 9.30,
there are different certificate types listed on this screen:
Certificate Authorities The Certificate Authorities section shows the CAs for which the Concentrator has an ID certificate.
Identity Certificates The Identity Certificates section shows information regarding the ID certificates for the Concentrator. These are certificates that are traded to authenticate.
SSL Certificates The SSL Certificate section shows the certificate that will be used in the event
an SSL session is requested when administering the VPN Concentrator.
In each case, the screen shows issuer and expiration information. You can also delete the certificate or view details. To view a certificate, click the View link under Actions. Figure 9.31 shows
an example of the details displayed. The View screen shows ownership and registration information. It includes subject and issuer information (Common Name, Country, and so on), the serial
number that identifies the individual certificate, the hashing algorithm, the key size, and the type
of key used. The Validity line at the bottom shows the period during which the certificate is valid.
Configuring the Use of IPSec Digital Certificates
FIGURE 9.30
Checking installed certificates
FIGURE 9.31
Viewing certificate details
431
432
Chapter 9
Configuring the VPN Concentrator
If you’ve successfully requested and installed a certificate, but receive an error
message about the certificate not being valid yet, compare the validity time to
the clock on the VPN Concentrator. Time zone offset is usually the cause of a
certificate not being valid for a few more hours.
When certificates are exchanged, the peers make sure the certificates are good. The certificates must be valid, falling in the time range between issuance and expiration, the certificate
must have been signed by a trusted CA, and the certificate serial number must not be listed in
the CRL. The receiving device extracts the public key from the certificate for use in encryption.
Managing User Tunnels
The Unified Client (discussed in Chapter 8) doesn’t provide a way for users to build their own
tunnel attributes (the SafeNet client does allow this). Since the user connecting to the VPN Concentrator will not have a way to specify how the tunnel is to be built, the Concentrator must provide this information. The administrator needs to make sure that the policies in effect recognize
how the tunnel should be built and configure the group for digital certificate support.
There are three tasks that the administrator must complete for user tunnel management:
1.
From the main VPN Concentrator Manager window, select Configuration System Tunneling Protocols IPSec IKE Proposals. Make sure that the desired IKE proposal is
the active one. Proposals are grouped together by encryption and hash method.
Configuring the Use of IPSec Digital Certificates
433
2.
Choose Configuration Policy Management Traffic Management SAs. Select the
IPSec SA that will be used, such as ESP-DES-MD5. Click Modify and select the correct digital certificate for the VPN Concentrator.
3.
Choose Configuration User Management Groups and select the group that needs to
be modified for digital certificate support. As mentioned previously, make sure that the
group name on the Identity tab matches the OU field on the ID certificate for the Concentrator. On the General tab, make sure IPSec is checked under Tunneling Protocols. On the
IPSec tab, make sure that the IPSec SA is set to the SA type that is to be used.
The tasks for creating a tunnel from one Concentrator to another Concentrator,
router, or firewall in a LAN-to-LAN configuration are the same as those for creating a tunnel to a client PC. Make sure that the device on the far side supports
the IKE proposal used on the Concentrator.
Requesting and Installing Client Certificates
Requesting and installing a certificate for a PC are simple tasks. Each starts the same way it did
to request a certificate for a Concentrator. Begin by opening a Web browser to the correct URL.
From the browser, select Request A Certificate Advanced Request Submit a Certificate To
This CA Using A Form. Figure 9.32 shows an example of the Microsoft Certificate Services
Advanced Certificate Request form.
The name and department are very important. The Department field entry must match the
name of the user’s group on the Concentrator. Also, make sure to supply the appropriate key
size, as well as the appropriate policy information. These need to match the settings used for the
Concentrator certificate. For example, if MD5 is used on the Concentrator, SHA should not be
used on the PC.
434
Chapter 9
Configuring the VPN Concentrator
It is usually a good idea to set the Key Usage to Both and to choose the Mark Keys As Exportable option. This will allow the keys to be saved in a PKS #12 file, which means that the keys
can be moved to a different PC, if necessary. Otherwise, you would need to generate a new certificate for the PC.
FIGURE 9.32
The client certificate request form
After you’ve filled in the form, click Submit. The CA will generate the certificate and display
a message indicating that the certificate was issued.
Click the Install This Certificate hyperlink to start the process of installing the certificate on
the PC. Next, you’ll see a verification message.
Configuring the Use of IPSec Digital Certificates
435
This message includes information about the certificate that you should examine before
clicking the Yes button to install the certificate. Check the thumbprint against what the administrator of the CA says it should have generated. Make sure that the certificate is valid for a correct amount of time. If this information is correct, click Yes to install the certificate.
Each operating system will have its own place to store certificates and its own method of
viewing them. To view the certificates currently installed on a Windows-based PC, open Internet Explorer and select Tools Internet Options Content Certificates. There are several
types of certificates that can be installed in the PC. If no custom certificates have been installed,
the Personal tab of the Certificate Manager dialog box will be blank. If the certificate installation was successful, there should be a certificate listed.
Double-click the certificate to see some information about it. The General tab of the Certificate
dialog box shows to whom the certificate was issued (this is the same name as the one in the Name
field on the certificate request form), the identity of the device that generated the certificate, the
period that the certificate is valid, and that there is a private key associated with this certificate.
Selecting the Details tab of the Certificate dialog box provides more specific information
about the certificate, as shown in Figure 9.33. Any of the fields on this tab can be selected, and
if there is additional information, as there would be for the key fields, it will be displayed in the
text box at the bottom of the dialog box.
The final verification that the certificate is installed correctly is to activate the VPN client,
open the Properties window, and select the Authentication tab. If the certificate is installed
properly, the radio button next to Certificate should be selectable. If multiple certificates are
installed, you will be able to select the one to use from the drop-down menu. Each certificate is
identified by the name used when filling out the form on the CA.
FIGURE 9.33
Viewing certificate details
436
Chapter 9
Configuring the VPN Concentrator
Firewall Feature Set for the IPSec
Software Client
Every Cisco VPN Concentrator comes with the VPN Client software, or you may download
Cisco VPN Client version 3.6 from the Cisco Web site. This software-based client is available
for Windows versions 95, 98, Me, 4.0 2000, and XP. Additionally, versions are available for
Intel-based Linux, 32- and 64-bit Solaris UltraSparc, as well as Mac OS X 10.1. The client will
enable you to use secure tunnels from any of the above-mentioned workstations to any Cisco
Easy VPN Server such as the PIX Firewall (6.0 or newer), any Cisco IOS–based system newer
than 12.2(8)T, or any of the Cisco VPN 3000 Concentrators.
The VPN Concentrator may be configured to require a specific configuration. When a client
attempts to connect the internal rule base will be reviewed. The configuration is required, and
if it does not match, then no tunnel will be established. If the VPN Concentrator is configured
to use the optional mode, it allows the client to connect and download the desired firewall with
the correct configuration onto the client’s PC. Additionally, the Concentrator will not permit a
VPN tunnel to be set up if a firewall is required by the Concentrator and there is none. However,
if a firewall is not required and one exists, a tunnel may still be established. In this section, we
will discuss the following:
The “Are You There” feature
The Stateful Firewall feature
The Central Policy Protection feature
Client firewall statistics
Customizing firewall policies
Software Client’s “Are You There” Feature
Rather than defining policies on the personal firewall, you might want to use a simple, albeit less
secure, method of ensuring that the software client is running. With the client’s “Are You
There” (AYT) feature, the VPN client polls the firewall installed on the client PC once every 30
seconds. If there is no answer to the polls, the VPN client will drop the tunnel. Only the polling
traffic is passed between the Concentrator and the firewall. AYT will work with ZoneAlarm,
ZoneAlarm Pro, and BlackICE.
Software Client’s Stateful Firewall Feature
You can configure the Stateful Firewall feature on the VPN client to prevent inbound connections from other networks without consideration of encryption type or tunneling configuration.
All connection requests will be denied with only a few exceptions:
Firewall Feature Set for the IPSec Software Client
Traffic from the head-end network
DHCP requests
Encapsulating Security Payload (ESP) traffic
437
ESP rules are packet filters–based, not session-based filters. Using ESP will allow split tunneling. This will enable both secured, encrypted traffic to the head-end network while still being
able to communicate via nonsecured connections to other outside networks such as the Internet.
You enable this feature by turning off the Always On option by clearing the checkbox.
Software Client’s Central Policy Protection Feature
If you require a more versatile and scalable solution for managing your firewall policies, you
might want to consider the Central Policy Protection (CPP) feature. The CPP can be set to deny
or allow specific ports and protocols. The Concentrator acts as the distribution point for the
configured policies and will push the rule base down to the client at connection during the negotiation process. Once the predefined policies are received from the Concentrator, they will be
passed to the CIC for enforcement. As with the Stateful Firewall, the Always On option will give
more flexibility with restrictions on external or Internet bound traffic. The CPP can use CIC,
ZoneAlarm, and ZoneAlarm Pro.
Client Firewall Statistics
To view the firewall statistics from the VPN client you simply need to double-click the yellow
padlock in the system tray to open the general information screen. Select Status Statistics Firewall (see Figure 9.34). The Firewall tab identifies the type of firewall and firewall policy as
well as provides details about the firewall filter rules. These rules are configured from the CPP,
as described in the previous section.
FIGURE 9.34
The Firewall tab of the VPN Client Connection Status dialog box
438
Chapter 9
FIGURE 9.35
Configuring the VPN Concentrator
The Tunnel Details tab of the VPN Client Status dialog box
The Tunnel Details tab (Figure 9.35) will show you the IP addresses of the client and server
as well as the encryption method and authentication for these connections.
On the Tunnel Details tab of the Statistics screen, you can see more of the details about your
connection including:
Bytes Received: The count of total bytes of secure data received
Bytes Sent: The count of total bytes of secure data transmitted
Packets Decrypted: The count of total encrypted packets received and decrypted on the port
Packet Encrypted: The count of total encrypted packets transmitted from the port
Packets Bypassed: The count of total data packets not processed because no encryption
was necessary
Packets Discarded: The count of total data packets that the VPN client rejected due to not
originating from the gateway
The Route Details tab, shown in Figure 9.36, shows the local LAN and secured routes. In the
figure shown, the VPN client is configured to use the tunnel only for traffic destined for the
172.16.0.0/16 private network. All other traffic is unprotected.
FIGURE 9.36
The Router Details tab of the VPN Client Status dialog box
Configure the VPN 3000 Concentrator for IPSec over UDP and IPSec over TCP
439
Customizing Firewall Policy
As with most default configurations, the overall security of yours network would be inadequate
if the defaults were left in place. Realistically, these default rules are there to supply some security and aid you in the process in setting up the rules that will be specific to your environment.
These rules can be applied to a specific interface or to a VPN group.
The Filter Rules selection list on the Rules screen, shown in Figure 9.37, contains the default
rules, which can be modified as you see fit. However, you will likely want to create your own rules
that will be more specific to your environment. The text in the parentheses describes the action of
the rule and the direction of the traffic that will be affected. The buttons on the side enable you
to add, modify, copy, and delete your rules.
FIGURE 9.37
The Rules screen
To modify the filter rules, simply highlight a rule and press the Modify button. Doing so will
bring you to the Modify window, as shown in Figure 9.38.
You might notice that the norm for the default rules is to forward traffic to Use IP Address/
Wildcard mask, which carries a default value of 0.0.0.0 255.255.255.255, the equivalent to any
address. One exception to the rule is the VRRP Out, which uses the multicast address
224.0.0.18/0.0.0.0, as assigned by the Internet Assigned Numbers Authority (IANA)
Configure the VPN 3000 Concentrator for
IPSec over UDP and IPSec over TCP
As we discussed in Chapter 7, Internet Protocol Security (IPSec) is the standard that enables a
secure connection from the client the VPN Concentrator. IPSec allows address data privacy,
authentication, integrity, key management, and tunneling. There are two options for IPSec:
IPSec over TCP and IPSec over UDP. Only one of these options can be used at a time, as when
you pick one the other will automatically be disabled. The next sections will describe each of the
methods as well as some of their companion configurations in more detail.
440
Chapter 9
FIGURE 9.38
Configuring the VPN Concentrator
The Rules | Modify screen
Overview of Port Address Translation
Port Address Translation (PAT) is similar in nature to Network Address Translation (NAT). In
PAT, the TCP or UDP port is translated in addition to the IP source or destination address.
Using PAT will allow you to use one IP Address for multiple machines. The distinguishing feature between them becomes the unique port and not the unique IP address. NAT is a one-to-one
translation whereas PAT is a one-to-many translation. Additionally, PAT translates TCP and
UDP ports as well as the source or destination address. Version 3.x of the software must be running to use PAT and Network Extension mode.
Some applications expect to use specific ports. Because PAT changes the ports
used, this can cause problems with this type of application.
You will likely come across some old DOS applications that embed the workstation address
with the data instead of depending on IP to carry the address. These applications probably predate
Configure the VPN 3000 Concentrator for IPSec over UDP and IPSec over TCP
441
even the OSI seven-layer model. Needless to say, the applications will not work with NAT or PAT
as data payload itself will not have been involved in the translation process and will retain the original addresses.
Configuring IPSec over UDP
The VPN 3002 Hardware Client fully supports User Datagram Protocol Network Address
Translation Transparent IPSec (UDP NAT Transparent IPSec). There are three requirements for
running UDP NAT IPSec:
You must be running version 3.0.3 or later software.
The client and Concentrator must be configured for the same port.
The VPN Concentrator must be configured with IPSec over UDP for the group.
With this configuration, the effects of NAT and PAT will be completely bypassed due to the
encapsulation of the data traffic within the new UDP packets. Rather, NAT mappings are kept
intact through the use of keepalive packets being sent on a regular basis.
UDP Transparent IPSec bypasses the effects of NAT and PAT by encapsulating
the data traffic within new UDP packets
Of course, this additional traffic does cause overhead, but it’s necessary as UDP is connectionless by definition, which causes some limitations, one of which is that only a single VPN
device may be behind the NAT device.
IPSec over UDP will not work if you are using PAT and you attempt to have
more than one VPN 3002 Hardware Client behind the firewall.
The device and the client must both be configured for the same port for the connection to work,
and the default port is 10000, although the acceptable range is from 4001 to 49,151. On the outbound side, the IPSec process encrypts, encapsulates, and then adds a new UDP header if required.
From the inbound side, the UDP traffic goes directly to the IPSec processing for decryption and deencapsulation before being routed. These rules may be removed from the filter under one of three
conditions: when a group is deleted, when the last active IPSec over UDP Security Association (SA)
for that group is deleted, or when IPSec over UDP is disabled for the group
To configure IPSec over UDP, go to the Configuration | System | Tunneling Protocols | IPSec
screen, shown in Figure 9.39, and enter the remote server IP address and whether to use IPSec
over TCP. If you wish to use something other than the default, you may take the default of using
IPSec over UDP and change the port number. With this type of setup, you need to use preshared
keys, so make certain the Use Certificate box is cleared. Next, you need to enter the group,
group password, user, and user password to complete the configuration.
442
Chapter 9
FIGURE 9.39
Configuring the VPN Concentrator
The IPSec screen
Configuring NAT-Transversal
As previously mentioned, you will inevitably run across an older DOS application that does not
work over NAT or PAT due to embedding the IP address inside the payload. The solution for
such a dilemma is to configure NAT-Transversal. In this configuration, the client encapsulates
the data traffic with the new UDP packet, thus bypassing the effects of the NAT or PAT translation. Since this method is also UDP connectionless–based, it incurs the overhead of periodic
keepalive packets to make sure that the tunnels stay up. It also has similar limitations to the
IPSec over UDP in that there can be only a single VPN device behind the NAT device.
UDP Transparent IPSec bypasses the effects of NAT and PAT by encapsulating
the data traffic within new UDP packets.
NAT-Transversal is configured in the same way as the IPSec over UDP.
Summary
443
Configuring IPSec over TCP
IPSec over TCP is fully supported on the Cisco VPN Client and the Cisco VPN 3002 Hardware
Client running version 3.5 or later software. With IPSec over TCP, the data is fully encrypted
and encapsulated within the TCP packet and will work through NAT and PAT devices whereas
ESP or Internet Key Exchange (IKE) will not. Because of this encapsulation, the encryption will
not work with a proxy server. As with the others, the same port numbers must be configured
on both ends when IPSec over TCP is enabled.
IPSec over TCP/IP is configured simply by placing a check in the box to enable IPSec over
TCP and selecting the TCP port to use. The default port is 10000, but any port between 1 and
65635 may be used. Take caution not to select a well-known port number such as 25 (SMTP)
or 80 (HTTP), and expect a system warning message if you do, letting you know that the port
you have chosen will no longer be available for that service. The VPN 3002 Hardware client will
allow only one TCP port; however, on the VPN Client, you may separate even up to 10 port
numbers in the configuration if you separate them with commas to use a different port for each
hardware client.
To configure IPSec over TCP on the VPN 3002 Hardware Client, look under the Configuration | System | Tunneling Protocols | IPSec screen. On the VPN Concentrator, configuration
settings for IPSec over TCP are made on the Configuration | System | Tunneling Protocols | IPSec
| NAT Transparency screen, as in Figure 9.40.
FIGURE 9.40
The NAT Transparency screen
Summary
This chapter explained how to allow users to create tunnels and terminate them at the Concentrator. First, we covered how to get the VPN Concentrator up and running. You use the CLI for
initial configuration, and then you can use the management utility’s Quick Configuration mode
to configure minimal parameters.
444
Chapter 9
Configuring the VPN Concentrator
Next, we described how to configure groups, users, and authentication (either locally or on
a remote authentication server). We also showed how policies can be implemented to allow
user access only during certain times and to prevent certain types of traffic from entering the
Concentrator.
We covered the use of digital certificates. Configuration for digital certificates requires that
both the Concentrator and the user PC request and install certificates.
Finally, Configuring the VPN Concentrator might seem overwhelming when you look at all
the tasks involved, but if you take one task at a time, it is fairly easy. Remember that there are
distinct phases of configuration, just as there are on a router.
Exam Essentials
Understand the relationship between users and groups. The VPN Concentrator has a default
group called base, but you can add other groups. When a user is created, that user will be a
member of the base group unless the user is placed in a different group. You can configure a
group with a policy, and that policy will then apply to all users who are members of the group.
If a custom group is deleted, all the user members become members of the base group.
Understand the Public Key Infrastructure (PKI). The PKI is the relationship for all devices
receiving certificates from a given CA. CAs can be stand-alone systems; there is no overall CA
for the entire world. Setting up a server with certificate software in a home lab, then configuring
a VPN Concentrator and a client to get certificates and form a VPN tunnel, is an example of a
very small PKI.
Know the steps to requesting and installing a digital certificate. Digital certificates are
the most complex part of IPSec, but they are also the most in demand. Certain pieces of
information, such as host and domain names, are required before a certificate request can
be created. Once the certificate has been requested using a PKCS #10, the certificate will be
issued in a PKCS #7.
Learn the details of the auto-update feature. The auto-update feature requires to the administrator to use several keyword to identify the client types. Memorize the keywords: Windows,
Win9x, WinNT, and vpn3002.
Learn the steps to configure and use filters. The filtering capability is used on both the VPN
Concentrator itself as well as on client firewalls. Get used to using the Web tool to configure the
rules and assign them to interfaces or client groups. Remember that all rules use a wildcard
mask instead of a standard subnet mask.
Written Lab
445
Key Terms
Before you take the exam, be certain you are familiar with the following terms:
access hours policy
public key
centralized protection policy (CPP)
Public Key Cryptography Standard #10 (PKCS #10)
centralized protection server
Public Key Infrastructure (PKI)
Cisco Integrated Client (CIC)
Quick Configuration mode
Concentrator group
registration authority (RA)
Concentrator user
rule
digital certificate
split tunnel
filter
subordinate CA
LAN-to-LAN IPSec
Virtual Cluster Agent (VCA)
private key
Written Lab
1.
What is the default username and password administration for VPN Concentrators?
2.
What is the first thing that happens when you boot up a Cisco VPN 3000 Concentrator
with the default factory configuration?
3.
What information is required in the command-line interface (CLI) portion of Quick
Configuration?
4.
Which interface will be configured from the browser-based VPN Manager?
5.
Where do users inherit their attributes on the VPN Concentrator?
6.
How many combined users and groups can a 3015 Concentrator support?
7.
Which dynamic routing protocols are supported on the VPN 3000 Concentrators?
8.
In what design situation would you be inclined to use unique preshared keys?
9.
From the Group | Add screen, what IPSec protocols are available from the default SA settings?
10. Name the three types of preshared keys.
446
Chapter 9
Configuring the VPN Concentrator
Hands-On Lab
The purpose of this hands-on lab is to set up load balancing on our 3000 VPN Concentrators.
As you learned in this chapter, when you have more than one Concentrator on a single subnet
for remote access, you can group these devices together into a cluster and balance the load
across each of the Concentrators. You will configure your Concentrator as the cluster master
to direct any incoming request to another cluster member with the least amount of load.
Items to remember:
All devices in the cluster must be on the same subnets on each side of the configuration,
public and private.
Cisco release 3.x IPSec VPN Clients-to-LAN connections are required to configure load
balancing. However, clients prior to 3.x may connect their target Ethernet2 or public port
IP address within the cluster.
A filter must be applied to both the public and private interface.
Each Concentrator in the load balancing cluster must have identical settings for the following:
UDP port use
Shared secret
Virtual cluster IP address
The following graphic displays the physical layout of the network and PIX Firewall.
10.10.10.1
255.255.255.0
192.168.12.1
255.255.255.0
VPN 3000
Internal
Network
Internet
10.10.10.0
255.255.255.0
VPN 3000
10.10.10.2
255.255.255.0
This section includes the following labs:
Lab 9.1: Configure the cluster configuration
Lab 9.2: Filter configuration
192.168.12.2
255.255.255.0
Hands-On Lab
LAB 9.1
Configure the cluster configuration.
1.
Use the cluster IP address of 192.168.12.20.
2.
Use a VPN virtual cluster port of 2910.
3.
Enable encryption.
4.
Use the IP shared secret password of S4rg0n1!.
5.
Verify the IP shared secret password by typing it again.
6.
Check the Load Balancing Enable check box to turn on load balancing.
7.
Set the Priority for this device to 1.
8.
Do not configure a NAT IP address.
LAB 9.2
Filter configuration.
1.
Add a new rule in your existing filters for VCA.
2.
Add the VCA in and VCA out in the filter.
Answer to Lab 9.1
1.
Navigate to the Configuration | System | Load Balancing screen.
2.
Configure the Concentrator exactly as configured below:
447
448
Chapter 9
Configuring the VPN Concentrator
Answer to Lab 9.2
1.
Navigate to the Configuration | Policy Management | Traffic Management | Rules to filter screen.
2.
Select Public (Default) and click the Add Filter button.
3.
Add VCA in and VCA out to the filter
Review Questions
449
Review Questions
1.
What does PKCS stand for?
A. Public Key Certification Standard
B. Public Key Cryptography Standard
C. Private Key Certification Standard
D. Private Key Cryptography Standard
2.
What mode is offered the first time the Concentrator’s GUI is accessed?
A. Quick
B. Setup
C. Quick Configuration
D. Install
3.
Which of the following are valid auto-update keywords?
A. Win9x
B. Win2k
C. WinNT
D. Linux2
4.
A group name configured on a Concentrator must match which field in a digital certificate?
A. Common Name
B. Organization
C. Organizational Unit
D. Location
5.
What routing protocols may be configured on an interface via the CLI? (Choose all that apply.)
A. BGP
B. EIGRP
C. OSPF
D. RIP
6.
Which of the following is not a tunneling method supported by the Concentrator?
A. L2TP
B. L2F
C. PPTP
D. IPSec
450
7.
Chapter 9
Configuring the VPN Concentrator
How many split tunneling network lists can be added to a group Client Config?
A. Unlimited
B. 256
C. 1,024
D. 1
8.
In the CLI, for a new Concentrator, what property is preconfigured for an interface?
A. Status
B. IP address
C. Subnet mask
D. MAC address
9.
Where is VPN Concentrator filtering modified?
A. Access List Configuration mode
B. Global Configuration mode
C. Configuration | Policy Management
D. Configuration | Interfaces
10. What method is used by a Cisco VPN3002 hardware client to download the new software
during an auto-update?
A. File Transfer Protocol (FTP)
B. Trivial File Transfer Protocol (TFTP)
C. Hypertext Transfer Protocol (HTTP)
D. Xmodem
Answers to Review Questions
451
Answers to Review Questions
1.
B. The Public Key Cryptography Standard (PKCS) is used to standardize certificate communication.
2.
C. Quick Configuration is offered only when the Concentrator has a minimal configuration.
Once run, it cannot be run again unless the Concentrator has been wiped clean.
3.
A, C. The administrator must configure the auto-update keywords exactly. Cisco has not provided a way to select them from a list.
4.
C. The Organizational Unit (OU) must match the group name.
5.
C, D. OSPF and RIP may be configured on an interface.
6.
B. L2F (Layer 2 Forwarding), the precursor to L2TP, is not a supported tunnel type.
7.
D. The group client configuration can have only one network list assigned to it. However, that
network list can have many networks associated with it.
8.
D. A new Concentrator does not come with an IP address or mask preconfigured, and the interface status is just a toggle. It does come with a burned-in MAC address.
9.
C. You can modify a filter through the Policy Management section of Configuration.
10. B. Unlike the software clients that download their updates from a Web page, the hardware
Client will automatically update itself using TFTP.
452
Chapter 9
Configuring the VPN Concentrator
Answers to the Written Lab
1.
The default VPN Concentrator administrator name and password are both admin.
2.
Booting the Concentrator the first time or with the factory default configuration causes the
VPN Concentrator to boot up in Quick Configuration mode.
3.
The CLI portion of the Quick Configuration requests system time, date, and time zone, as
well as the private interface IP address, subnet mask, speed, and Duplex mode.
4.
You must configure the Private side interface with the CLI portion of the Quick Configuration, after which you will most likely perform the rest of the interface configuration with
the VPN Manager.
5.
Users inherit their attributes from the groups you have configured. If you have not configured any additional groups, then the attributes of the Global group will be inherited.
6.
The 3015 Concentrator can supported 100 combined users and groups.
7.
The Cisco VPN 3000 Concentrators support RIP and OSPF dynamic routing protocols as
well as static routes.
8.
For site-to-site VPNs, you would use preshared keys.
9.
The ESP Protocol is the only IPSec protocol available by default on the IPSec tab of the
Group Add screen. Authentication Header (AH) provides only authentication and is not an
option; however, ESP provides encryption and authentication.
10. The three types of preshared keys are unique, group, and wildcard.
Chapter
10
Managing the VPN
Concentrator
THE FOLLOWING TOPICS ARE COVERED IN
THIS CHAPTER:
Monitor and administer Cisco Secure VPN 3000 for remoteaccess networks.
Monitoring the VPN Concentrator
Administering the VPN Concentrator
Bandwidth management
Once the Cisco VPN Concentrator has been configured and
tested, there is little that needs to be done with it on a day-to-day
basis beyond adding new users and groups when needed. However, an administrator will occasionally need to monitor the Concentrator to make sure that the
network is running smoothly and troubleshoot any problems that occur. Of course, the administrator will need to perform administrative tasks, such as managing access and files.
The VPN Concentrator includes a management utility that makes it easy to access the Concentrator reports and administration functions. This chapter covers the Concentrator’s monitoring and administration tools. This management tool includes statistical and logging information
that can be used to troubleshoot security problems or bandwidth management configurations.
Monitoring the VPN Concentrator
To make sure the network is running properly, network administrators need to keep an eye on
what the equipment is doing. Devices that use VPNs can gather many statistics about the network. There are two main ways to manage network equipment:
Simple Network Management Protocol (SNMP) logs information to a management console in real time. This is the method that CiscoWorks and HP OpenView use to manage
devices.
A syslog server is primarily used for historical logging. Syslog output is saved in tables for
viewing at a later time.
If you already have CiscoWorks, another management option is to use the
Cisco VPN/Security Management Solution product. For more information
about this product, visit www.cisco.com/warp/public/cc/pd/wr2k/vpmnso.
In the following sections, we will take a deep look into the Concentrator. We will learn how
to look at the system status, routing table information, and other general statistics that help
keep the Concentrator in good health.
Monitoring the VPN Concentrator
455
Viewing Concentrator Monitoring Information
The VPN Concentrator tracks several types of statistics. To access the statistics, select Monitoring from the VPN Concentrator Manager window. You will see the main Monitoring screen,
as shown in Figure 10.1. The monitoring options include
Routing Table
Dynamic Filters
Filterable Event Log
System Status
Sessions
Statistics
FIGURE 10.1
The VPN Concentrator’s Monitoring screen
456
Chapter 10
Managing the VPN Concentrator
When you select a hyperlink, the screen displayed contains the most recent data-capture
available. Some screens have a Refresh button, which you can click to show the most up-to-date
information. The following sections describe some of the more common options. We will discuss the Event Log section in greater detail later in this chapter.
Viewing System Status Information
The System Status category provides a way to monitor the physical aspects of the Concentrator,
which is particularly helpful if the box is remote. Click the System Status link on the main Monitoring screen to see the System Status screen, shown in Figure 10.2.
FIGURE 10.2
The System Status screen
This screen shows the type of device that is being examined and the general system status statistics. You can see the fan speed and temperature for the CPU, as well as throughput and processor utilization. This screen provides quick and easy checks of the basic systems operations.
Clicking an interface displays information about that interface, as shown in Figure 10.3. The
interface in this example is using the IP address 10.0.6.5, is physical interface #1, and has a status of UP, so it is active. This interface has had around 1,150 unicast packets flow in each direction, received almost 104,000 broadcasts, and sent out a few broadcasts as well.
Monitoring the power supplies is normally an easy thing to do. If you can access the screen
at all, just click the interface’s power supply on the System Status screen. There often isn’t too
much to worry about as the power supplies are generally quite dependable, but if the Concentrator is in a locale where power is not very stable and is subject to surges and sags, then the
Power screen, shown in Figure 10.4, can be an invaluable addition to a UPS.
Monitoring LEDs is a time-honored tradition in the networking industry. The general rule to follow is that green LEDs are good, and other colors or no LED are bad. Figure 10.5 shows the LED
Monitoring the VPN Concentrator
457
Status screen, which appears when you click the front panel LEDs (on Concentrator models 3015
through 3080) on the System Status screen. Table 10.1 explains what each of the LEDs indicates.
FIGURE 10.3
The Interface Statistics screen
FIGURE 10.4
The Power screen
FIGURE 10.5
The LED Status screen
Chapter 10
458
TABLE 10.1
Managing the VPN Concentrator
LED Status on a VPN Concentrator
Indicator
Green
Amber
Off
System
Normal
System failed
Power off
Ethernet link status
Steady means connected to network;
blinking means connected but disabled.
N/A
Not connected
Expansion module
insertion status
SEP installed
N/A
SEP not installed
Expansion module
run status
SEP operational
N/A
If installed, encryption
disabled or SEP failed
(diagnostics)
Fan status
Normal
Below normal RPMs
N/A
Power supplies
Installed and running
normally
Voltage outside
acceptable range
Power supply not
installed
It is not unusual for a properly working system to have one or more LEDs indicating an error state. For example, if a Concentrator has two power supplies
installed but only one is plugged in, the second would have voltage below the
acceptable limit. Knowing your network is the key to knowing if a warning LED
is an indication of a problem.
Viewing Routing Table Information
The Concentrator can learn routes from several sources. In addition to RIP- and OSPF-derived
routing information, the Concentrator can understand static routes, default routes, and locally
attached networks. To see routing information, select the Routing Table link from the main
Monitoring screen. Figure 10.6 shows an example of the Routing Table screen.
Viewing General Statistics
Click the General Statistics link on the main Monitoring screen to bring up the Statistics screen,
shown in Figure 10.7. There are a number of items that can be tracked via this screen:
PPTP, L2TP, and IPSec tunnels
HTTP exchanges
Event information
Monitoring the VPN Concentrator
Telnet sessions
DNS information
Authentication and accounting information
Filtering information
VRRP information
SSL sessions
DHCP leases and duration
Address pool configurations and allocated addresses
SSH sessions
Load-balancing state
Compression statistics
Administrative AAA requests, authentications, and failures
NAT sessions and statistics
MIB II interfaces and protocols
Bandwidth management statistics
FIGURE 10.6
459
The Routing Table screen
For example, if you click the PPTP link, you will see the screen shown in Figure 10.8. All the
statistics that appear on this screen have been captured since the Concentrator was last booted.
The screen shows three broad types of information:
Tunnels The total number of tunnels is the aggregate number of tunnels created since the Concentrator was last powered on. Active tunnels are the number currently active. You can update
this number by clicking the Refresh icon. The maximum tunnels value is the highest number of
tunnels active at one time since the Concentrator was booted.
Sessions The session information includes the total number of sessions, number of active sessions (which can be updated by clicking the Refresh icon), and maximum number of sessions
active at one time, in the same format as the tunnel information. It is important to remember
that several user sessions can be active through a tunnel.
460
Chapter 10
Managing the VPN Concentrator
Data and Control The data and control information appears below the tunnel and session
information. The information collected is divided into octets and packets transmitted and
received.
FIGURE 10.7
The Statistics screen
FIGURE 10.8
PPTP statistics
Monitoring the VPN Concentrator
461
Table 10.2 describes the statistics collected for the PPTP tunnel type. The statistical information for each type of tunnel varies slightly, however, the PPTP statistics page is fairly representative of what you can expect to find on similar pages for L2TP or IPSec.
TABLE 10.2
Tunnel Statistics
Data Field
Description
Tunnels
Identifies the number of tunnels that have been created since
the VPN concentrator has been rebooted, the number of tunnels that are currently active, and the most that have been
simultaneously connected.
Sessions
Identifies the number of sessions that have been created
since the VPN concentrator has been rebooted, the number of
sessions that are currently active, and the most that have
been simultaneously connected.
Control/Data
These fields describe the total number of PPTP-related bytes
(octets) and packets that have been sent, received, or discarded since the VPN concentrator last rebooted.
Peer IP
The IP address of a currently connected peer. Fields to the
right of the IP address identify specifics about the session
related to this address.
Username
Username used to authenticate this session.
Octets/Packets
The number of bytes (octets) and packets sent or received
since the session was started.
ZLB
Zero Length Body (ZLB) increments when the tunnel needs to
acknowledge reception of a packet, but no return packet is
available to piggyback the acknowledgement on.
Discards
The total number of packets discarded.
ACK Timeouts
The number of times that the tunnel has exceeded its timer
for sending an acknowledgement because no data was
available for it to piggyback on. This should trigger a ZLB.
Under normal circumstances, ZLB and ACK timeouts
should be the same.
462
Chapter 10
TABLE 10.2
Managing the VPN Concentrator
Tunnel Statistics (continued)
Data Field
Description
Flow
The flow column shows the flow-control status of this tunnel. The value can be one of four states: Local, which means
the number of unacknowledged packets that have been
received equals the window size for the tunnel, so the remote
client is holding data; Peer, which means the number of unacknowledged packets that have been sent equals the window
size for the tunnel, so the VPN concentrator is holding data;
Both, which means the Windows in both directions are full, so
both sides are holding data; and None, which means the tunnel has available window space in both directions and is able
to send data. This is the normal condition.
Another section of the Statistics menu, the Bandwidth Management screen, shown below in
Figure 10.9, provides important information on bandwidth controls.
FIGURE 10.9
The Bandwidth Management screen
Monitoring the VPN Concentrator
463
Table 10.3 describes the information available on the Bandwidth Management screen.
TABLE 10.3
Bandwidth Management Statistics
Data Field
Description
Group
This option is contained in a drop-down menu and can be the
Base Group, an administrator-defined user group, or the keyword All, which is used to select statistics for all groups.
Username
This column identifies the username associated with the tunnel statistics listed to the right. Each tunnel is displayed once
for each direction that the bandwidth policy is applied. In current versions, the bandwidth policy cannot be applied unidirectionally.
Interface
The inbound or outbound interface that the policy is being
enforced on.
Conformed Rate/Volume
The conforming speed or number of bytes sent or received
for this tunnel.
Throttled Rate/Volume
The nonconforming speed or number of bytes for this tunnel.
Other screens from the Management menu provide similar information in a similar tablebased format. Each screen might or might not provide useful information depending on how
your concentrator is configured and how you use it. At a minimum, you should be familiar with
the PPTP, L2TP, IPSec, Authentication, Filtering, and Bandwidth Management sections.
Viewing Session Monitoring
The Sessions screen, shown in Figure 10.10, appears when you click the Sessions link on the
main Monitoring screen. There are several types of sessions supported on the Concentrator. At
the top of the screen is a summary of the sessions, including totals of each type and all sessions.
Further down the screen is detailed information on each type of session as well as information
regarding each particular session. The different session types include
LAN-to-LAN Sessions In a LAN-to-LAN session, two network devices form a tunnel between
each other. The purpose of the tunnel is to protect information generated by the VPN clients. A
Concentrator-to-firewall VPN protecting data flowing from one LAN to another is an example of
a LAN-to-LAN connection.
Remote-Access Sessions A remote-access session is started by a client machine that has data
it wants protected by a VPN. A user dialing up an ISP, then using a VPN client to talk to the
Concentrator is an example of a remote-access session.
464
Chapter 10
Managing the VPN Concentrator
Management Sessions A management session is used to manage the Concentrator. An example would be an administrator using a Web browser to monitor or administer the Concentrator.
FIGURE 10.10
The Sessions screen
Each of the three is displayed with a number of statistics that are relevant to that type of session. For example, the Remote Access Sessions section is the only one that identifies the assigned
tunnel IP address. All the information on this screen is available in different sections of the statistics screen found under the main Monitoring menu. However, this screen provides a concise,
single-page source for current usage information.
In addition to the information shown on the Monitoring | Sessions screen, you can display
the Monitoring | Sessions | Protocols screen to see a breakdown of a session on a protocol-byprotocol basis. The Protocols screen shows sessions for just IPSec or another tunnel type as well
as encryption information. Clicking the connection itself provides detail about the connection,
including the username and IP address assigned to the connection.
Another option, not shown in Figure 10.10, is the ability to access “top 10” session information. If you go to the Monitoring | Sessions | Top Ten Lists screen, you can see which connections are the top 10 for connection time or bandwidth usage. To see the top-10 sessions in
bytes per second, select Throughput.
Monitoring the VPN Concentrator
465
Configuring Logging and SNMP Traps
Remote management takes two forms on the Concentrator:
The Concentrator can use Management Information Bases (SNMP MIBs) and traps. This
allows you to collect and parse information into a real-time format that can be used to
make decisions when monitoring the network.
You can use a syslog server to collect data so someone can go through it at a later date.
Both methods are configured by choosing Configuration from the VPN Concentrator Manager window, then System Events. You will see the Events screen, shown in Figure 10.11.
FIGURE 10.11
Choosing a method of logging
In the following sections, we will illustrate how to configure event logging by configuring the
event classes on the Concentrator as well as the configurations required for SNMP for management and syslog server for additional logging. We will also look at viewing the local log.
Configuring the Events to Log
To begin logging events, select the General link on the Events screen to set up default event-handling. Figure 10.12 shows the General screen, which is used for configuring the types of events
to be logged.
This screen is very flexible. You can have one type of event logged to a syslog server, another
type of event sent to SNMP, and a third e-mailed to a pager that is carried by whoever is on call.
If you check the Save Log on Wrap checkbox, the log file will be saved when it is about to
wrap after 2,048 on the 3015–3080 models. The 3005, however, is limited to only 256 events.
Each save consumes approximately 334KB. If the space available on the flash drops below
2.56MB, the Concentrator will delete the oldest logs.
There are three choices for the log format:
Multiline breaks up the event entry into multiple lines of 80 characters each.
Comma Delimited separates event-entry fields by commas.
Tab Delimited separates event-entry fields by tabs.
466
Chapter 10
FIGURE 10.12
Managing the VPN Concentrator
The General screen
If desired, you can enter an e-mail source address and select the format of syslog messages.
In the remaining fields, you can set severity levels for logging, displaying on the console, sending
to a syslog server, sending to an e-mail recipient list, and trapping.
You can view the log residing in memory anytime from the administration console. Simply access
the log by choosing Event Log from the main Monitoring screen. You can filter the log by choosing
specific classes and priorities to view (hold down the Ctrl key to make multiple selections).
Creating Custom Event Classes
If the preconfigured events are not sufficient for your needs, the Concentrator also gives you the
opportunity to create custom event classes that can log information. Figure 10.13 shows the
first screen of this process, the Classes screen. To open this screen, click the Classes link on the
Events screen. If you want to change an existing custom event, select it and click Modify. To create a new custom event, click Add.
Each custom event can log events from severity values 1 (critical) to 13 (low-level hex dump).
Levels 1 through 6 are normal alarms, levels 7 through 9 are debug alarms, and levels 10
through 13 are hex-dump events.
Configuring SNMP
The VPN Concentrator must be configured before trap information can be sent to an SNMP management station. To configure SNMP, select Trap Destinations from the Events screen. Through the
Trap Destinations screen, shown in Figure 10.14, you can add or modify trap destinations.
Monitoring the VPN Concentrator
FIGURE 10.13
Selecting event classes
FIGURE 10.14
Configuring SNMP traps
467
When you click the Add button on the Trap Destinations screen, you will see the Add screen,
shown in Figure 10.15. Entering the correct destination IP address is very important when configuring a trap. Choose the SNMP version of the trap and enter the community string for this device.
The default community string, public, is a popular SNMP community string. It
is strongly recommended that default community strings not be used.
468
Chapter 10
FIGURE 10.15
Managing the VPN Concentrator
Configuring a specific entry
Logging On to a Syslog Server
A syslog server is another type of network device that can capture and store logs generated by a Concentrator. Before those logs can be sent out, you must set up a syslog server and point the Concentrator in the right direction. To configure a syslog server, click the Syslog Servers link on the Events
screen. Using the Syslog Servers screen, shown in Figure 10.16, you’ll notice that setting up the syslog
server is similar to setting up SNMP. If there isn’t an existing entry, click Add to create a new one.
FIGURE 10.16
Creating a syslog entry
Clicking Add brings up the Add screen, shown in Figure 10.17. Here, you need to specify the
correct IP address. A syslog server will install on UDP port 514 by default. If the syslog application was installed with a different port or facility tag, you must enter the correct values.
Navigating to the Monitoring | Filterable Event Log | Live Event Log screen displays events
as they are logged in almost real time. The screen is updated every five seconds and displays logs
of events that occur on the Concentrator. Leaving this screen open is one way to avoid having
an administrative session terminated due to an idle timer. The refresh requests that occur every
five seconds reset the idle timer.
Monitoring the VPN Concentrator
FIGURE 10.17
469
Configuring a syslog server
Viewing the Local Log
In addition to being able to send logging information to SNMP and syslog servers, the VPN concentrator can store a small number of log entries locally. To view the local log, select the Monitoring screen from the main menu. From there, select the Event Log option. Note that older
version of the concentrator had a single Event Log option.
The new version, shown earlier in Figure 10.1, has two options. The Live Event Log is an appletbased log that is not filterable, but automatically updates and includes a scrolling interface. The live
event log has no configurable parameters. The Filterable Event Log, shown in Figure 10.18, has a
number of options to allow the administrator to narrow the information displayed.
FIGURE 10.18
The Monitoring | Filterable Event Log screen
470
Chapter 10
Managing the VPN Concentrator
Table 10.4 describes the options available on the Filterable Event Log screen.
TABLE 10.4
Filterable Event Log Options
Option
Description
Event Class
Filter based on the class of the event.
Severities
Allows filtering based on specific severity levels.
Client IP Address
Allows filtering based on the address of the client. This
applies only to events that are tagged with the information.
Events/Page
Number of events displayed per page. The Tape/VCR Type
buttons allow movement between the pages.
Group
Allows filtering based on user group.
Direction
Changes the direction of listing from oldest to newest or newest to oldest.
Get/Save/Clear Log
Updates, saves, or erases the internal log.
Using the Internal Logging Tools
When working on this book, I tried to simulate every possible scenario that was discussed. One
of the things that we covered in Chapter 8 was the auto-initiation feature and its usage in a
WLAN environment.
When simulating the WLAN environment, I didn’t have a DHCP server on the WLAN side of the
concentrator, so I configured the DHCP forwarding feature. I spent about 3 hours trying to get
my laptop to pick up a DHCP address and eventually tracked the problem to a configuration
problem. Here is the process I used to find the issue:
Setting up logging
By default, detailed DHCP and IP packet information is not logged to the syslog server, the console, or to the internal log. The first step was to reconfigure the logging settings to track the
information I wanted. Since I didn’t have a computer handy to act as a syslog server, I used the
internal log.
Administering the VPN Concentrator
471
First I navigated to the Configuration | System | Events | General page. I selected the drop-down
menu for the Events to Log. By default, you can log only event levels 5 or higher. I needed to
see detailed debugging level events, so I needed to select the Use Event List option.
To create the event list, you need to know the event class names. Unfortunately, I don’t have
all these memorized, and Cisco has been nice enough to make us type them in by hand without
a reference. Fortunately, you can click to the Filterable Event Log page and cheat by looking at
the drop-down options under the filters.
I created an event list that included the DHCP, DHCPDBG, and DHCPDECODE event classes.
Viewing the log
From the Live Event Log page, I was able to watch the DHCP related events occur when I
released/renewed my address on my laptop. The logs showed the DHCP request coming into
the concentrator, the concentrator forwarding the request, and the DHCP server sending a
reply. However, the laptop never received the reply because the VPN concentrator was not
sending it back on the WLAN side.
Curing the problem
Once I knew that the problem was centered at the VPN concentrator and I had narrowed the
locations where the packet could be lost, I was able to find the source of the issue. In my haste
to reconfigure the concentrator, I had neglected to properly update the outbound filter on the
public-side interface. I updated my filter, saved my configuration, and was able to successfully
simulate the WLAN scenario.
Administering the VPN Concentrator
In addition to monitoring the Concentrator, there are many miscellaneous administrative functions that administrators need to perform from time to time. All these functions are accessed
through the Administration screen, shown in Figure 10.19. To access this screen, simply choose
Administration from the VPN Concentrator Manager window. In Chapter 9, we used the Certificate Management link on this screen to request and install digital certificates. Here, we’ll
look at the other options.
Configuring Access Rights
Access control is an important part of any security policy. The Concentrator allows the network
administrator to have fairly detailed control over many access characteristics. You can configure Access Control Lists, set idle timeouts, and allow additional administrators access to the
device. Overall, the purpose of an administrator is to determine access and rights in the Concentrator software functional areas.
472
Chapter 10
FIGURE 10.19
Managing the VPN Concentrator
The main Administration screen
Adding Administrators
You can create multiple administrator accounts for the Concentrator. In fact, the Concentrator
comes with five preinstalled administrator accounts, as shown in the Administrators screen in Figure 10.20. (To get to this screen, select Access Rights from the main Administration screen, then
select Administrators.) The default accounts and the default rights assigned to each account are
listed in Table 10.5.
TABLE 10.5
Default Concentrator Administrator Accounts
Group
Username
Description
1
admin
System administrator with access to and rights to change all
areas. This is the only administrator enabled by default and the
only one who can log in to and use the VPN Concentrator Manager as supplied by Cisco.
2
config
Configuration administrator with all rights except SNMP access.
3
isp
ISP administrator with limited general configuration rights.
4
mis
Management information systems administrator with the same
rights as config.
5
user
User administrator with rights to view only system statistics.
Fortunately, only one of these accounts is enabled by default (but it is not impossible for an organization to accidentally get a configured Concentrator that was used by another company and then
returned). If two administrators are logged in at the same time, the first one gets read-and-write
access and all subsequent logins get read-only access.
Administering the VPN Concentrator
FIGURE 10.20
473
Configuring administrators
Notice that the administrator account names are in text boxes. This means that these account
names can be changed. In the example shown in Figure 10.20, the account name for the group
5 user was changed from its default of user to student2. The default password for each of
these accounts is its username (for example, admin for the admin account and config for the
config account, etc.). There can be only one super administrator (Administrator) account, but
you can enable each of the accounts by simply checking the box in the column labeled Enabled.
Modifying Administrator Access Rights
If you have multiple administrators in a department and they should not have the same level of
ability on the Concentrator, you can modify their access rights. Click the corresponding Modify
button on the Administrators screen to modify the properties of the accounts, as illustrated on
the screen shown in Figure 10.21.
FIGURE 10.21
Modifying access rights
474
Chapter 10
Managing the VPN Concentrator
On this screen, you can change the properties of a particular administrator account as well
as the username and password. For the Authentication, General, and SNMP access rights, the
possible settings include the following:
Setting
Description
None
The administrator has no authority.
Stats Only
The administrator has access to only the Monitoring section of the
Concentrator.
View Config
The administrator is able to view some items but not make changes
(such as User mode on a router).
Modify Config
The administrator is able to view and change the configuration.
For files, rights can be assigned as follows:
Setting
Description
None
Administrator has no access.
List Files
Administrator can list files residing in flash.
Read Files
Administrator can read files residing in flash.
Read/Write Files
Administrator can read and write files to and from flash and save log files.
Adding an ACL
For security, you want to make sure that only those devices that are permitted to administer the
Concentrator are able to access it. When the ACL is empty, the Concentrator does not block any
device from sending HTTP packets to it in an attempt to do administration. To allow only certain machines to have this access, you need to filter out other devices.
To create a new ACL, select Access Rights from the main Administration screen, select
Access Control List, and click Add. On the Add screen, shown in Figure 10.22, specify the IP
address that can access the Concentrator and the subnet mask. Then assign this device to a particular administrative group. Make sure that the group is enabled (as described previously, in
the “Adding Administrators” section), if you want the user to be able to perform any administrative tasks.
After you’ve created a new list, you can make changes to it by highlighting it on the Access
Control List screen and clicking Modify.
Managing Access Settings
Generally, you will not need to worry about the settings for administrative sessions. To see the
session idle timeout and session limit settings, select Access Rights from the main Administration screen, and then choose Access Settings.
Administering the VPN Concentrator
475
As shown in Figure 10.23, each administrative session has a default timeout of 10 minutes
(600 seconds) and there can be no more than 10 administrative sessions at a time, by default.
If necessary, you can change these values. This screen also has a check box for configuration file
encryption. By default, sensitive items inside the configuration file are encrypted. If necessary,
you can deselect this setting to disable encryption.
FIGURE 10.22
Creating a new ACL
FIGURE 10.23
The Access Settings screen
Administering Sessions
The Administer Sessions screen, displayed by choosing Administer Sessions from the main
Administration screen, is very similar to the Sessions screen accessed from the main Monitoring
screen (shown earlier in Figure 10.10). There is only one small difference: the Management Sessions section of the Administer Sessions screen allows you to ping the device accessing the management console as well as log that user out, as shown in Figure 10.24.
476
Chapter 10
FIGURE 10.24
Managing the VPN Concentrator
The Management Sessions screen
Administering File Management
The File Management screen provides options for managing files, swapping the configuration
files, and transferring files via TFTP. To open the File Management screen, click File Management
on the main Administration screen. We will look at each of these in detail in the following sections.
Managing Files
When you click the Files link on the File Management screen, you see the screen shown in
Figure 10.25, with each file’s name, size, and creation date and time. You can view, delete,
or copy these files by selecting the appropriate action.
Two files that are commonly found here are the CONFIG and CONFIG.BAK files. The
CONFIG file is the latest saved version of the configuration. The CONFIG.BAK file is the prior
saved version of the configuration.
FIGURE 10.25
The Files screen
Swapping Configuration Files
If someone makes a configuration mistake and saves the changes, you can go back to the previous version of the configuration file (CONFIG.BAK). To do this, choose Swap Configuration
Files from the File Management screen. You will see the screen shown in Figure 10.26.
When you click OK, the System Reboot screen appears, as shown in Figure 10.27. (You can also
access this screen directly by choosing System Reboot from the main Administration screen.) From
here, you can make several choices about the reboot, including when the reboot will happen, if the
Administering the VPN Concentrator
477
configuration will be saved beforehand or not, and so on. All in all, a reboot normally takes a bit
over a minute. If you do not save the current configuration, any changes you make will be lost.
FIGURE 10.26
The Swap Configuration Files screen
FIGURE 10.27
The System Reboot screen
Transferring Files using TFTP
Trivial File Transport Protocol (TFTP) is one way of getting files from another network device
to the Concentrator. Choosing TFTP Transfer from the File Management screen displays the
screen shown in Figure 10.28.
The TFTP Transfer screen accepts four options:
Concentrator File The file name as shown on the concentrator.
Action The direction of the transfer as viewed from the perspective of the concentrator.
TFTP Server The name or IP address of the server the file will be copied to or from.
478
Chapter 10
Managing the VPN Concentrator
TFTP Server File The filename as shown on the TFTP server. This name need not be the same
as the name on the concentrator.
Note that the TFTP Transfer menu is not used to upgrade the operating system on the Concentrator. TFTP is appropriate for copying the configuration to a TFTP server and back.
FIGURE 10.28
The TFTP Transfer screen
Updating Software
Upgrading the software on the Concentrator is easy. Select Administration Software Update
Concentrator from the main menu. The Software Update | Concentrator screen, shown in Figure 10.29, shows what type of software is currently loaded and provides an option to upgrade.
FIGURE 10.29
The Software Update screen
Administering the VPN Concentrator
479
If you want to upgrade software, simply place the updated version of the software on the
local PC or on a network drive the PC can access. Then click the Browse button to find the correct file and place the path in the box next to the Browse button. With the correct path specified,
click the Update button to upgrade the software. Once the software has been updated, the Concentrator will need to reboot. Be sure to save the configuration, else any changes will be lost.
You can also use the software update feature to notify users of available updates to the client.
This will tell them the location to go to download the update files. To do so, navigate to the Clients screen under the Software Update menu and select the group you wish to notify.
Pinging Devices
The Concentrator can ping another device to ensure it exists on the network. One way to do this
is by selecting Ping from the main Administration screen, which brings up the Ping screen, shown
in Figure 10.30. Enter the IP address of the device to test and click the Ping button to generate a
response. The desired response is that the destination “is alive.”
FIGURE 10.30
The Ping screen
480
Chapter 10
Managing the VPN Concentrator
Summary
This chapter covered two areas of the VPN Concentrator’s management utility: monitoring and
administering.
Typically, you won’t need to check the Monitoring section on a daily basis, but you should
check it occasionally. Remember that both SNMP and system logging (through a syslog server)
allow for the Concentrator to inform other network devices of what is going on. Some form of
semipermanent storage of the logs is always a good idea, in case you need to refer to those logs.
The Administration section is a large catchall area for items that don’t easily fit under Configuration and are often directly related to administration of the Concentrator. The two broad
items covered here are administrator configuration and file management.
Exam Essentials
Know that there are three primary sections for managing the VPN Concentrator. The three
modes are Monitoring, Configuration, and Administration. Configuration is where the Concentrator configuration occurs. Administration is where policy-related items are configured and
tested. Monitoring is used to see what is going on with the Concentrator and network.
Understand that while the VPN Concentrator Manager is a Cisco product, some Cisco features are
not enabled on it. The CVPN 3000 series product line provides many common features using
methods that differ from a router or firewall. For example, a router typically uses Cisco’s proprietary
Hot Standby Router Protocol (HSRP) for redundancy. The VPN concentrator uses Virtual Router
Redundancy Protocol (VRRP), which is an equivalent IETF draft-standard protocol. Terminology
can also differ. An Access Control List (ACL) is used to control access to the web or virtual console
on a VPN concentrator and a Filter Rule is used to control traffic through the VPN concentrator. An
ACL on a Cisco router is used to identify traffic for filtering, security, or traffic prioritization.
Know how to manage the Concentrator. There are four different ways to manage the Concentrator. Telnet and console access allow you to manage it via a command line. HTTP (or
HTTPS) is required to use the GUI. SNMP management is available. A part of CiscoWorks also
works well as a management tool.
Understand the meaning of each of the bandwidth management statistics. The bandwidth
management statistics provide important information on both permitted and filtered bandwidth usage for users and groups. Make sure you can verify correct bandwidth management
configurations by using these statistics.
Understand how configuration files are stored on the Concentrator. The configuration
instructions are stored in CONFIG and CONFIG.BAK. The CONFIG file is the most recent save.
The CONFIG.BAK file is the second most recent save.
Know how to upgrade Concentrator software. To upgrade the software, you store the software where your PC can access it, and then give the path to the Concentrator. The Concentrator
then downloads the files through your PC.
Written Lab
481
Key Terms
Before you take the exam, be certain you are familiar with the following terms:
access rights
remote-access session
CONFIG file
SNMP (Simple Network Management Protocol)
CONFIG.BAK file
syslog server
LAN-to-LAN session
TFTP (Trivial File Transfer Protocol)
management session
Written Lab
1.
What screen do you need to be in to clear routes?
2.
The current software version can be viewed from two different locations. Name each of them.
3.
What screen do you need to be in to check the CPU utilization on the Cisco 3000 Concentrator?
4.
What screen do you need to be in to set the password for the administrator?
5.
How do you limit the number of concurrent management connections?
6.
What is the fastest way to resolve a misconfiguration that has not been saved?
7.
What screen displays information that can be used to troubleshoot an IPSec connection?
8.
What are the meanings of the ZLB and ACK Timeouts statistics for PPTP and L2TP? How
are they related?
9.
How do the Administration | Administer Sessions screen and the Monitoring | Sessions
screen differ?
10. What information is available from the Monitoring | Statistics | Bandwidth Manage-
ment screen?
482
Chapter 10
Managing the VPN Concentrator
Review Questions
1.
What is the default port for a syslog server?
A. TCP 540
B. UDP 54
C. TCP 541
D. UDP 514
2.
How many VPN Concentrator administration accounts exist by default?
A. One
B. Two
C. Three
D. Four
E. Five
3.
What is the default maximum number of VPN Concentrator administrative sessions?
A. 5
B. 10
C. 15
D. 20
4.
The VPN Concentrator System LED has how many possible states?
A. One
B. Two
C. Three
D. Four
5.
How many VPN Concentrator log file entries can be held before wrapping takes place?
A. 512
B. 1,024
C. 2,048
D. 4,096
Review Questions
6.
The VPN Concentrator Swap Configuration Files function exchanges which two files? (Choose
all that apply.)
A. CONFIG
B. CONFIG.001
C. CONFIG.SAV
D. CONFIG.BAK
7.
What range of event levels can be logged for the VPN Concentrator?
A. 1–3
B. 3–5
C. 7–13
D. 10–256
E. 1–13
8.
How many VPN Concentrator administration accounts are enabled by default?
A. One
B. Two
C. Three
D. Four
E. Five
9.
483
What size are VPN Concentrator saved log files typically?
A. 127KB
B. 334KB
C. 862KB
D. 1024KB
10. How is a VPN Concentrator software upgrade uploaded?
A. Via the PC, from a directory accessible from the PC
B. Via TFTP
C. Via a locally accessible FTP server
D. Via the PC, from a directory accessible from the Concentrator
484
Chapter 10
Managing the VPN Concentrator
Answers to the Written Lab
To clear routes, navigate to the Monitoring | Routing Table screen.
1.
The current software in use can be viewed as follows:
2.
From the Monitoring | System Status Screen
From the Administration | Software Update | Concentrator screen
3.
To check the CPU utilization, navigate to the Monitoring | System Status screen
4.
To set the password for the Administrator account, navigate to the Administration | Access
Rights | Administrators
5.
To limit the number of concurrent management connections, go to the Administration |
Access Rights | Access Settings screen.
6.
The fastest way to resolve this situation is to navigate to the Administration | File Management | Swap Config File screen and swap the backup configuration with the current configuration. Once the files have been swapped, navigate to the Administration | System
Reboot screen and reboot.
7.
To trouble shoot an IPSec connection, navigate to the Monitoring | Statistics | IPSec screen.
8.
The ZLB and ACK Timeout statistics indicate when a null packet was generated to carry
an acknowledgement because there was no data to piggyback the acknowledgement on. If
the tunnel is working properly, they should be the same number since an ACK timeout will
trigger a ZLB.
9.
The two sessions screens under Administration and Monitoring differ only in that the
Administration version allows you to log off connected users.
10. The Bandwidth Management screen displays the connected users for a particular group
along with byte and rate conformed and throttled information for the bandwidth policy.
Answers to Review Questions
485
Answers to Review Questions
1.
D. A syslog server installs on port UDP 514 by default.
2.
E. There are five slots for accounts and five default accounts.
3.
B. The default maximum number of administrative sessions is 10.
4.
C. The System LED has a total of three possible states: green, amber, and off.
5.
C. The log file can hold 2,048 individual log entries before it wraps.
6.
A, D. The swap function exchanges the two files named CONFIG and CONFIG.BAK.
7.
E. The event levels that can be logged range from 1 through 13.
8.
A. There is only one administrator account enabled by default, admin. All others must be
enabled before they can be used.
9.
B. Each saved log file is about 334KB. Once free space on flash drops below 2.56MB, the older
log files are deleted.
10. A. The upload of new software takes place from the PC through the Web browser window. This
means that the software must reside somewhere where the PC can access it.
Glossary
488
Glossary
A
access concentrator (AC) The PPPoE server used by a service provider to authenticate and
process packets for the PPPoE client.
access control list (ACL) A set of entries that collectively define network traffic to permit or
deny based on information in each packet.
access hours The time of day when users are allowed to create new tunnels.
access hours policy An administrative policy that defines when users are and are not allowed to
access network or computing resources. Usually defined as part of a larger computer-usage policy.
access rights A list of privileges assigned to a user that controls what configuration settings
and files that user can create, modify, or delete.
access VPN A style of VPN design where the VPN is used by individual users in a fashion similar to a dial-up connection. The access VPN provides as-needed access to a secure network
from a remote, possibly mobile location. See also extranet VPN and intranet VPN.
accounting Sending information regarding usage of network resources.
active A firewall in a failover pair that is inspecting and passing traffic.
Active mode FTP The standard way FTP is implemented: Using the PORT command, the
client tells the server which TCP port to use for the file transfer.
Adaptive Security Algorithm (ASA) The software algorithm used to maintain security
between interfaces on a PIX Firewall.
Altiga Client The common name given to the original VPN 3000 client. This client was a
direct descendent of the Altiga product line and worked only with the VPN 3000 Concentrator.
anti-replay A characteristic of secure communication that ensures that captured data cannot
be used to impersonate the original sender.
application proxies A system that acts on behalf of a client application(s) to ensure the client's
security. See also proxy server.
attack guards The software mechanisms used on the PIX Firewall to guard against the more
popular Denial of Service attacks.
audit policy The actions that will be taken when the audit process detects one or more signatures have been detected.
authentication Verifying a user’s identity using their username and password.
Authentication Header (AH) One of two types of headers that may be prepended to the data
payload in an IPSec connection. The Authentication Header provides features such as message
integrity, nonrepudiation, and anti-replay, however, it does not provide data confidentiality.
Glossary
489
authorization Determining which network resources can be accessed by a network user.
auto-initiation A method of automatically starting a VPN connection in response to a partic-
ular network configuration. Usually used in a WLAN environment.
B
back-channel connections An application design technique that uses different ports for commands and data communications (i.e., FTP and RSH).
bootstrapping Configuring a device with enough information to allow it to download the full
configuration.
C
centralized protection policy (CPP) A set of rules defined on the centralized protection server
that controls the security policy of a remote firewall. The CPP is pushed to a remote firewall as
part of the VPN negotiation process. Currently only the Zone Labs–style firewalls support CPP.
centralized protection server A server acting as the central depository for remote security
policies. Currently the only supported version of centralized protection server is the Zone Labs
Integrity server.
certificate authority (CA) An organization or computer system that is responsible for acting
as a trusted third party in a secure or authenticated connection. In addition to biographical
information, a CA will generate or store cryptographic keying material that can later be used to
identify a user or system with a high degree of reliability.
Challenge Handshake Authentication Protocol (CHAP) The password authentication method
used for PPP that uses a hash of the password so it is not transmitted over the connection.
Cisco Encryption Technology (CET) A proprietary encapsulation technique developed by
Cisco Systems prior to the standardization of IPSec. CET uses well-known encryption mechanisms to provide features similar to static IPSec tunnels.
Cisco Integrated Client (CIC) An updated firewall included in versions 3.5 and newer of the
Cisco Unity Client. The CIC accepts policy updates from the head-end VPN 3000 concentrator
and enforces them at the user side of the tunnel. At this time, the CIC policy feature works only
with the VPN 3000 series. PIX- and IOS-based tunnels are not supported.
Cisco PIX Device Manager A Java-based application used to configure a PIX Firewall.
Cisco Secure for Windows NT (CSNT) An AAA server that provides TACACS+ and
RADIUS services.
490
Glossary
Cisco Secure Policy Manager (CSPM) Software used to configure the security policy on net-
work devices.
concentrator group An administrative designation assigned to a user or users that allows a
common configuration template to be assigned to them. In a VPN 3000 environment, all users
are part of the BASE_GROUP unless they are moved to another, administrator-defined group.
concentrator user A VPN user defined in the internal VPN database or a designated external
database. See also concentrator group.
CONFIG file The VPN 3000 file in which the most current saved configuration is stored.
Erasing the CONFIG file will reset the concentrator to factory defaults.
The VPN 3000 file in which the backup configuration is stored. The
concentrator permits swapping the CONFIG and CONFIG.BAK files to provide “undo”
type functionality.
CONFIG.BAK file
connection slots An entry in memory used to keep track of stateful information for a given
traffic flow that consists of TCP and UDP ports.
D
data confidentiality A characteristic of secure communication that ensures that the clear text
version of the protected data is available only to the sender and receiver.
Data Encryption Standard (DES) A standard encryption mechanism that uses a 56-bit keying
system. DES is no longer considered secure since computing power allows the 56-bit key to be
easily defeated by brute force. See also 3DES.
data integrity A characteristic of secure communication that ensures that the protected data
has not been modified in transit.
data-origin authentication A feature of secure communication that ensures the accuracy of
the source of data. This is usually done either through a password, a cryptographic signature,
or both.
defense-in-depth Providing the best defense by using a combination of firewall technologies.
Diffie-Hellman (DH) A key exchange mechanism that is used in IPSec to allow two endpoints
to agree on a key over an insecure channel.
digital certificate A unique key that is usually derived from a cryptographic function. This
key is shared with a trusted third party, such as a certificate authority, to provide authentication
services.
DMZ The network referred to as the demilitarized zone that is accessible to the outside world
but is still protected by the firewall. Usually the DMZ is where Web, DNS, and proxy servers
reside. See also screened subnet.
Glossary
491
E
Encapsulating Security Payload (ESP) One of two types of headers that may be prepended
to the data payload in an IPSec connection. The Encapsulating Security Payload provides features such as message integrity, nonrepudiation, anti-replay, and data confidentiality.
encryption A reversible encoding mechanism based on a mathematical formula that uses a
single or set of keys known only to the sender and receiver. Encryption is used in IPSec to provide data confidentiality.
Extended Authentication (Xauth) Used to authenticate a VPN user to an AAA server.
extranet VPN A type of site-to-site VPN where a group of business partners connect to a cor-
porate network through a common, usually hardware-based, VPN connection. This connection
is usually transparent to the end user. See also access VPN and intranet VPN.
F
fault A failure of a component.
fault tolerance Being able to withstand one or more component failures without affecting
system operation. See also highly reliable.
filter A set of rules that permit or deny network traffic based on content such as source or des-
tination address, protocol type, or direction of packet movement. See also rule.
firewall A device that enforces an access control policy between two or more networks.
fragmentation Splitting a packet into smaller packets for transmission over a medium that
cannot support the size of the packet.
fully qualified domain name (FQDN) The hostname and domain name used to identify a par-
ticular system or server.
G
global profile The information used to configure the global parameters for a VPN Client.
H
Hashed Message Authentication Code (HMAC) A feature of IPSec that provides message
integrity through the use of a checksum that is hashed by MD5 or SHA hashing mechanisms.
492
Glossary
hashing A form of mathematical authentication where a random-length input string always
results in a unique, fixed-length number or code. This code can be used for authentication or
integrity checking.
highly reliable Being able to withstand one or more component failures without affecting
system operation. See also fault tolerance.
I
ICMP-type object group A set of ICMP types that is treated as a single entity.
identity NAT Used to create a translation slot in the translation table. No address translation
occurs because the PIX Firewall will not forward traffic that does not have a translation slot.
IKE policy A set of security parameters used to establish a secure session between two devices.
See also protection suite.
individual profiles Used to store information used for specific connection parameters.
inside global An Internet-routable IP address that represents one or more inside local IP
addresses to the outside world.
inside interface The interface on the firewall where the inbound traffic is the most trusted.
Traffic from this interface is allowed by default.
inside local The IP address that is assigned to a device on the inside network and is most likely
not an Internet-routable IP address.
Internet Key Exchange (IKE) An optional step in the IPSec negotiation process where tunnel
endpoints exchange keying data prior to establishing the actual security associations. The IKE
phase can also be used to negotiate other portions of the connection such as user authentication
and client configuration.
Internet Protocol Security (IPSec) A set of standards that define how IP-based endpoints can
communicate securely over an insecure infrastructure. The standard defines policies that allow
for sender authentication, data integrity, and data confidentiality.
Internet Security Association and Key Management Protocol (ISAKMP) The IPSec protocol by which the Internet Key Exchange phase is accomplished. The terms ISAKMP and IKE
are often used interchangeably in Cisco documentation.
intranet VPN A type of site-to-site VPN where a remote office connects to a corporate network through a common, usually hardware-based, VPN connection. This connection is usually
transparent to the end user. See also access VPN and extranet VPN.
intrusion detection system (IDS) Software used to watch traffic for patterns of attack or
malicious behavior.
Glossary
493
L
LAN-to-LAN IPSec An IPSec tunnel created for the purpose of connecting two LANs over an
unsecure network.
LAN-to-LAN session A VPN connection that is terminated on a VPN 3000 Concentrator on
one end and a VPN 3002 hardware client, PIX Firewall, IOS Router, or another VPN 3000
Concentrator on the remote end. LAN-to-LAN sessions are managed separately from ordinary
access VPN connections.
load balancing Being able to use more than one resource to increase system performance.
M
management session A connection to a VPN 3000 Concentrator via the Web interface, telnet,
or console. Limited management-session control is provided via the management interfaces.
N
Network Address Translation (NAT) Substituting one IP address in the header of a packet for
another IP address.
network management processor The processor on the supervisor engine that controls the
operations on the switch.
network object group A set of network IP addresses that is treated as a single entity.
Network Time Protocol (NTP) The protocol used to synchronize a device’s clock to a
common network time.
O
object group A set of objects that is treated as a single entity.
outside global The IP address that is assigned to a device on the outside network and is usu-
ally an Internet routable IP address.
outside interface The interface on the firewall where the inbound traffic is the least trusted.
Traffic from this interface is dropped by default.
outside local The IP address of a device on the outside network as it appears to the inside
network.
494
Glossary
P
packet-filtering firewalls A device that permits or denies traffic based on a static set of rules
and that processes packets at layers 2 through 4.
Passive mode FTP The FTP protocol in which the client informs the server to transfer data
using the passive method using the PASV command. The server then informs the client which
port to open for the file transfer using the PORT command.
Password Authentication Protocol (PAP) A password-authentication method for PPP that is
not very secure because it transmits the password over the connection for authentication.
.pcf extension A file used to store the connection-specific VPN Client information.
PIX Management Center (MC) Software used to maintain and manage the configuration and
files on a PIX Firewall.
point of failure The specific component or subsystem that has failed and caused a fault.
Point-to-Point Protocol over Ethernet (PPPoE) A protocol used to encapsulate and trans-
port PPP frames over Ethernet.
Port Address Translation (PAT) Substituting one IP address and port in the header of a
packet for another IP address and port.
port redirection Changing the TCP or UDP port number of inbound traffic to a different port
number for the outbound traffic.
preshared key A common key used for endpoint identification and encryption. The key is
exchanged prior to the secure session through manual mechanisms, usually out of band.
primary The device in a firewall failover pair that acts as the active firewall during normal
operations. See also secondary.
private interface The VPN concentrator interface that is usually connected to the more- or
most-trusted network. This would generally be the side opposite the WLAN or Internet interface.
private key An encryption key known only to the receiver of a message. In public key cryp-
tography, the private key is one half of a two-key set where messages encrypted with one key
can be decrypted only with the other.
profile configuration file The file used to store configuration information for a particular
connection.
protection suite A set of security parameters used to establish a secure session between two
devices. See also IKE policy.
protocol object group A set of protocols that is treated as a single entity.
Glossary
495
proxy server A system that is usually dual-homed and provides security to network clients at
the application level. See also application proxies.
public interface The VPN Concentrator interface that is usually connected to the less- or
least-trusted network. This would generally be the side connected to the WLAN or Internet.
public key An encryption key known to the sender of a message. The key works only for
encrypting data for a particular destination. In public key cryptography, the public key is one half
of a two-key set where messages encrypted with one key can be decrypted only with the other.
Public Key Cryptography Standard #10 (PKCS #10) A standard format for requesting certi-
fication of a public key from a CA.
Public Key Infrastructure (PKI) A set of standards and interoperability rules that allow secu-
rity devices to authenticate, authorize, and secure data communications with minimal user and
administrative interaction. The PKI includes certificate authorities, security devices, and standard procedures for the request, authorization, and negotiation of security related information
such as digital certificates.
Q
Quick Configuration A configuration tool that is automatically launched by the VPN 3000
series of products when the device is new or restored to new configuration. The Quick Configuration tool prompts the administrator for just enough information to get the concentrator or hardware client to a basic functioning configuration. Also referred to as Quick Configuration mode.
Quick Configuration mode See also Quick Configuration.
R
registration authority (RA) The person or group responsible for authorizing a CA to issue a
certificate.
remote-access session A VPN connection that is terminated on a VPN 3000 Concentrator
on one end and a single user software or hardware client on the remote end. Remote-access sessions are managed separately from ordinary-access LAN-to-LAN connections.
RSA signature An authentication mechanism based on RSA public key cryptography tech-
nology where one party presents half the key material as the signature and another party, such
as a CA, holds the reciprocal half for the purpose of authenticating the first party.
rule An individually defined policy that identifies a particular type of frame or packet. A set
of rules makes up a filter. See also filter.
496
Glossary
S
SafeNet Client The original Cisco VPN client that was used only on PIX firewalls and IOSbased VPN connections. The SafeNet client is now obsolete due to the introduction of the Unified Client and updated PIX and IOS software.
Scalable Encryption Processing (SEP) A hardware-based encryption process where the
encryption work is offloaded to a dedicated processor to allow the VPN concentrator to scale
to several thousand active connections. Most VPN 3000 models support up to four fieldinstallable SEP modules.
screened subnet A protected network connected to a firewall. See also DMZ.
secondary The device in a firewall failover pair that acts as the standby firewall during
normal operations. See also primary.
secure sockets layer A protocol used to ensure secured communication between two end
devices.
secure VLAN interface The VLAN interface used for communications between the Firewall
Module and the supervisor engine.
Security Association (SA) A negotiated, unidirectional connection between two tunnel end-
points. IPSec negotiates authentication and encryption policies in each direction and ties those
policies to an SA.
service object group A group of TCP or UDP port numbers that is treated as a single entity.
shared secret A common code or password used to authenticate a Radius or TACACS+ client
and server. The secret may be sent in clear text or as a hash of the original text, depending on
server type.
shunning Blocking some or all traffic from an IP address.
signature The traffic pattern used to identify an attack.
Simple Network Management Protocol (SNMP) A network management standard that
allows data to be collected from a hierarchal database called the Management Information Base
(MIB). SNMP can also issue event-triggered “traps” to immediately notify a management station of errors.
single point of failure The component or subsystem that would allow a system or group of
systems to fail completely.
split tunnel A VPN configuration in which only data that needs to be protected is sent
through a tunnel. All other traffic is sent directly.
standby The firewall in a failover pair that is not inspecting and passing traffic and is moni-
toring the active firewall.
Glossary
497
stateful failover Transferring all session information to a standby system so no active com-
munications will be affected.
stateful firewalls A device that permits or denies traffic based on the state of connections,
which are permitted or denied based on a set of rules.
Stub Multicast Routing (SMR) Allows the PIX Firewall to act as an IGMP proxy agent to
forward IGMP messages from multicast hosts to the upstream multicast router.
subordinate CA A certificate authority that acts on behalf of another CA to issue certificates
for a subset of users or devices.
SYN flood Using many packets with the TCP/IP SYN flag set to deny access to a network
resource. This usually occurs from randomly generated IP addresses.
syslog A server that can receive and log remote logging information using the syslog protocol.
The syslog server often can retain logging information longer than the internal device log.
T
3DES Triple Data Encryption Standard. An enhanced version of the original DES standard that
uses three separate passes to produce a 168-bit key length. See also Data Encryption Standard (DES).
transform A combination of encryption, authentication, and negotiation parameters for an
acceptable security association (SA).
transform set A prioritized list of transforms from which two IPSec endpoints select one commonly acceptable transform to use as the basis of their security associations.
translation slot An entry that is created in the translation table to ensure proper handling of
return traffic for an outbound connection.
Transport mode One of two methods of building an IPSec packet. Transport mode inserts the
IPSec header information into an existing packet between the IP header and the IP data.
Trivial File Transfer Protocol (TFTP) A simple UDP based protocol used to transfer data across
an IP network. Many Cisco products use TFTP to upgrade software and backup configurations.
tunnel A method of hiding the original source and final destination of data by placing the
entire IP packet inside another IP packet.
Tunnel mode One of two methods of building an IPSec packet. Tunnel mode creates a new
IP packet and IPSec header, then places the entire original packet, including IP header information, into the data section of the new packet. See also tunnel.
498
Glossary
U
U Slang for a rack unit, which is a unit of measure equal to 1.75 inches. The rack unit is the
basic measurement by which the height of rack-mounted equipment is defined.
Unified Client The newest version of the Cisco VPN client. The Unified client is the only VPN
client compatible with VPN 3000–, PIX-, and IOS-based VPN servers.
user An account assigned to a person or group of persons. The account is associated with a
group or individual rights.
V
Virtual Cluster Agent (VCA) A VPN 3000 specific protocol that allows remote VPN clients to
be redirected to the cluster member that has the most available resources.
virtual private network (VPN) Any technology that simulates a private network over an
unsecured or public network.
vpnclient.ini The file used to store the global profile for a VPN Client.
VPN Concentrator A device that terminates a large number of VPN connections. This device
is usually dedicated for this purpose.
VPN/Security Management Solution (VMS) A set of applications used under the
CiscoWorks2000 framework to manage and maintain security device on an enterprise network.
X
Xlate table A table in memory that maintains information for the translation of packets on
the firewall. Also referred to as a translation table.
Index
Note to the reader: Throughout this index boldfaced page numbers indicate primary discussions of
a topic. Italicized page numbers indicate illustrations.
Symbols and Numbers
! (exclamation mark), for profile
read-only parameters, 255
# (pound symbol), for Privileged
mode, 29
@ symbol, for username and password,
130
3DES (Triple Data Encryption
Standard), 309, 497
license, 18, 300
A
AAA. See Authentication, Authorization
and Accounting (AAA) services
aaa accounting command, 129–130
aaa authentication command, 127–128
aaa authorization command, 128–129
AAA Flood Guard, 159–160
aaa-server command, 125–126
aaa-server radius-acctport command,
126
aaa-server radius-authport command,
126
access concentrator (AC), 111, 488
access-control lists (ACLs), 104–107,
488
access blocking with, 70–72
applying, 106
converting conduits to, 106–107, 107
creating, 105–106
crypto, creating, 237–238
downloadable, 132–133
exam essentials, 134
group objects in, 119
and inbound packet processing, 21
and interesting traffic, 317
for packet-filtering FTP, 153
symmetric, 238
troubleshooting, 323
viewing, 245–246
for VPN concentrators, 474
creating, 475
access-control policy, firewall to enforce,
4, 5
access-group command, 104, 106
access hours, 488
restriction, real-world scenario, 411
VPN concentrator configuration for,
410–413, 411
access interface, configuration, 84–85
access-list block permit command, 72
access-list command, 105
for RealPlayer support, 157
access-list compiled command, 105
access-list permit command, 317
access methods, for command-line
interface, 28
access rights, 488
for VPN concentrators, 471–475
access VPN, 298, 488
accounting, 129–130, 488. See also
Authentication, Authorization and
Accounting (AAA) services
ACK timeouts, statistics, 461
ACLs. See access-control lists (ACLs)
activation-key command, 18
activation key, for PIX Firewall, 18
500
active – Authentication
active, 488
Active Discovery Phase in PPoE, 111
Active-mode FTP, 152, 488
Active Service Monitoring window, 122
active unit for PIX Firewall failover,
198–199
ActiveX, blocking, 110
Adaptive Security Algorithm (ASA),
21–22, 104, 229, 488
address translation, 59–62
consequences, 62
admin account, 472
admin password
changing
Quick Configuration utility for,
348
for VPN 3002 hardware client,
340–341
for VPN concentrator configuration,
399
administratively down interface, 199
administrator accounts for VPN
concentrators, 472–473, 473
modifying rights, 373–374
Advanced Encryption Standard (AES),
239, 309
Aggressive mode communication for IKE
phase 1, 319
aliases for IP addresses, 50
Altiga client, 301, 488
Altiga concentrator, 331. See also Cisco
VPN Concentrators
anti-replay, 488
AH field to enable, 305
IPSec and, 237, 303
anti-spoofing filters, 68
application-aware proxy, 7
with packet-filtering router and
stateful firewall, 9–11, 10
application proxies, 6–7, 488
"are you there" feature for firewall, 436
ASA (Adaptive Security Algorithm),
21–22, 104, 229, 488
asymmetric key encryption, 310, 427
attack guards, 159–168, 488
AAA Flood Guard, 159–160
DNS Guard, 168
IP Fragmentation Guard, 165–168
Mail Guard, 161–163
SYN Flood Guard, 160–161
attack signature class for IP audit, 169
attacks
from dual-homed gateways, 7
shunning to stop, 175
speed of response, 72
audit policy, 488
applying, 170
creating, 169
AUS. See Auto Update Server (AUS)
authentication, 127–128, 488
CSNT through user databases, 123
interactive, Cisco Hardware client
for, 352–354
properties in Unified Client, 357–358,
358
for VPN concentrator configuration,
397–398
Authentication, Authorization and
Accounting (AAA) services,
119–133
CiscoSecure ACS for
Windows 2000/NT
administration, 123
how it works, 123–125
installation, 120–125
system requirements, 122–123
Downloadable PIX ACLs, 132–133
implementation on PIX Firewall,
125–132
accounting, 129–130
authentication, 127–128
Authentication Database Configuration window – Certificate Revocation List (CRL)
authorization, 128–129
virtual HTTP and telnet, 130–132
Authentication Database
Configuration window
(CiscoSecure ACS install), 121
Authentication Header (AH), 488
Authentication Header protocol,
303–305, 303–305, 304
authentication server, configuration for
VPN concentrator, 409–410
authorization, 128–129, 489. See also
Authentication, Authorization and
Accounting (AAA) services
auto-initiation, 489
for Cisco VPN software client,
365–367
auto-update poll period command, 279
Auto Update Server (AUS), 277–281,
278
auto-update server command, 278
B
back-channel connections, 154, 489
backup, configuration on Hardware
Client, 413–414, 414
backup firewall, license for, 18
backup servers, configuration on VPN
3002, 351
Baltimore Technologies, 425
base group
property inheritance from, 402
in VPN Concentrator, 401
Base64 encoding for certificate retrieval,
429
bastion hosts, 6
BIOS in PIX Firewall, 15
black holes, 192
BlackICE, 436
501
boot process, interrupting, 29
bootstrap configuration for PIX
Firewall, 276–277, 280
bootstrapping, 489
breach of integrity, 6
C
CA. See certificate authorities (CAs)
ca authenticate command, 234
ca configure command, 233
ca enroll command, 234
ca generate rsa key command, 47, 233,
251
ca identity command, 233
ca save all command, 47, 235
ca zeroize rsa command, 236
cable for PIX Firewall failover
connection, 196
unplugged, 202
cable-modem routers, 63
caches, resetting, 30–31
CatOS switch, configuration for FWSM,
25–26
Central Protection Policy (CPP),
421–422, 437, 489
configuration, 422–423
centralized protection server, 423, 489
certificate authorities (CAs), 311, 313,
424, 489
configuration, 232–236
enrolling firewall, 232–235
preparation, 232
deleting related items, 236
identifying, 233
showing information, 235–236
for VPN client, 254–255
Certificate Revocation List (CRL), 233,
429
downloading, 234
502
certificates – Cisco PIX Device Manager (PDM)
certificates, 428, 490
client request and install, 433–435
installing in Unified Client, 359–362
for IPSec, 424–435
Concentrator request, 426–428
downloading, 429
generating, 428–429
installing, 430
validity, 432
viewing, 430–432, 431
CET (Cisco Encryption Technology),
299, 489
Challenge Handshake Authentication
Protocol (CHAP), 111, 307, 489
checksum, displaying for PIX Firewall
configuration, 34
Choose Destination Location window
(CiscoSecure ACS install), 121
CIC (Cisco Integrated Client), 421, 422,
489
Cisco 3002 VPN Hardware client,
253–261, 336, 336–356
additional features, 349–356
interactive authentication,
352–354
IPSec over TCP and backup
servers, 351
load balancing, 354–356
Reverse Route Injection (RRI), 350
CLI quick configuration utility,
337–341
Admin password changes,
340–341
hardware client configuration,
341–348
interface configuration, 337–338
IP addresses configuration,
339–340
IPSec group configuration, 340
saving and exiting, 341
system information configuration,
338
tunneling protocol configuration,
338–339
connection profiles, 259–261
deployment, 255–261
global profile, 256–258
Quick Configuration utility, 341–348
admin password, 348
DNS configuration, 346–348, 347
enabling users, 348
IPSec configuration, 344, 344–345
PAT or LAN Extension mode,
345–346
private interface configuration,
343, 343
public interface configuration,
344, 344
static routing, 348, 348
system time, 342, 343
using existing configuration file,
343
Cisco Encryption Technology (CET),
299, 489
Cisco Integrated Client (CIC), 421, 422,
489
Cisco Intrusion Detection System, 169
Cisco PIX Device Manager (PDM),
208–219, 214, 489
operating requirements, 209–210
overview, 208–209
for PIX Firewall configuration,
212–219
Access Rules tab, 213, 214
Hosts/Networks tab, 215, 216,
217
Information window, 213
Memory Utilization graph, 219
Monitoring tab, 218
System Properties tab, 217, 217
Cisco routers – cloning VPN concentrator configurations
Translation Rules tab, 215, 215
VPN tab, 261, 261–272
preparing for, 210–212
for virtual private network creation,
261–272
remote access VPN, 268, 268–272,
269, 270, 272
site-to-site VPN, 263, 263–266,
264, 265, 266
Cisco routers, 299–300
Cisco Secure for Windows NT (CSNT),
489
Cisco Secure Policy Manager, 273,
273–274, 299
FWSM and, 23
Cisco Secure Policy Manager (CSPM),
490
Cisco VPN Concentrators, 300
3000 series, 330–335
3005 overview, 331–332, 332
3015 front panel, 335
3015 rear panel, 334
3015 through 3080, 333–335
5000 series, 330
client support, 335, 335
Cisco's IP/TV, Real-Time Streaming
Protocol (RTSP) and, 157
CiscoSecure ACS for Windows 2000/NT
administration, 123
how it works, 123–125
installation, 120–122
system requirements, 122–123
user database, 124
CiscoSecure ACS Service Initiation
window, 122
CiscoSecure User Database, 124
CiscoWorks2000 Server system
Auto Update Server (AUS), 277–281,
278
503
Management Center for PIX
Firewalls, 276, 276
VPN/Security management Solution,
275, 275
clear command, 30–31
clear dhcpd command, 52
clear fragment command, 168
clear igmp command, 91
clear shun command, 175
CLI. See command line interface (CLI)
CLI quick configuration utility
hardware client configuration,
341–348
admin password, 348
DNS configuration, 346–348, 347
enabling users, 348
IPSec configuration, 344, 344–345
PAT or LAN Extension mode,
345–346
private interface configuration,
343, 343
public interface configuration,
344, 344
static routing, 348, 348
system time, 342, 343
using existing configuration file,
343
clients. See also Cisco 3002 VPN
Hardware client
for VPN concentrators
automatic update, 418–421
group setup, 405–408, 406
monitoring updates, 421
support, 335, 335
clock command, 47–48
clock set command, 31, 47, 232
clock summer-time command, 47–48
cloning VPN concentrator
configurations, 364–365
504
clusters – Database Import utility
clusters, 415–416
command authorization, 129
command line interface (CLI), 28–37
access methods, 28
basic commands, 30–37
editing in, 30
for FWSM switch configuration,
25–26
modes, 28–30
starting, 386
for VPN Concentrator configuration,
386–393
comments, in profile file, 255
concentrator group, 490
concentrator user, 490
concentrators. See Cisco VPN
Concentrators
conduit command, 104
conduits, converting to access control
lists, 106–107, 107
confidentiality of data
in IPSec, 303
risk of exposure, 6
config account, 472
CONFIG file, 476, 490
CONFIG.BAK file, 476, 490
configuration files, swapping, 476–477
Configuration mode, 29–30
configure terminal command, 29
CONNECT keyword, for directly
connected routes, 89
connection profiles, features controlled
by, 259–261
connection slots, 19, 490
connections, properties in Unified Client,
358, 359
console
for command-line interface access, 28
configuring telnet access to, 45–46
displaying logs on, 52
copy command, 31
counters, resetting, 30–31
CPP (Central Protection Policy),
421–422, 437, 489
configuration, 422–423
CPU in PIX Firewall, 14
CPU Utilization graph, in PDM, 218,
220
CRL (Certificate Revocation List), 233,
429
downloading, 234
crypto ACLs, creating, 237–238
crypto dynamic map command, 252
crypto ipsec security-association lifetime
command, 240
crypto ipsec transform-set command,
238, 240, 252
crypto map client authentication
command, 248
crypto maps, creating, 241
CSPM (Cisco Secure Policy Manager),
273, 273–274, 299
FWSM and, 23
CSUtil.exe, 124
CU-SeeMe, 158
cut-through proxy, 120
D
DATA command, Mail Guard and, 162
data confidentiality, 490
Data Encryption Standard (DES), 309,
490
free key for, 300
license for, 18
data integrity, 490
IPSec and, 237, 303
data-origin authentication, 490
IPSec and, 303
Database Import utility, 124
Database Replication utility – enable command
Database Replication utility, 124
databases, CiscoSecure User Database,
124
daylight saving time, 47
DB15 (failover connector) port, 16
debug commands, 31–32
debug crypto command, 248
debug igmp command, 92
debug mfwd command, 92
debug rip command, 86–87
default gateway, as point of failure, 193
default route for PIX Firewall, 85
generating, 86–87
defense in depth, 11, 490
deleting
CA-related items, 236
configuration on flash, 36
demilitarized zone (DMZ). See DMZ
(demilitarized zone)
Denial of Service (DoS) attacks, 6
protection against, 160–161
stateful firewall for preventing, 9
DER encoding for certificate retrieval,
429
DES (Data Encryption Standard), 309,
490
free key for, 300
license for, 18
description command, 115
device drivers, as point of failure, 191
DHCP (Dynamic Host Configuration
Protocol), FWSM and, 23
dhcpd address command, 51
dhcpd auto config command, 51
dhcpd command, 50–52
dhcpd domain command, 51
dhcpd enable inside command, 51
dhcpd lease command, 52
dhcpd option command, 51
505
dhcpd wins command, 51
Diffie-Hellman (DH) key exchange,
309–310, 490
digital certificate, 490. See also
certificates
disable command, 29
discarded packets, statistics, 461
distance-vector protocols, 87
distributed denial of service (DoS)
attack, 6
DMZ (demilitarized zone), 9, 490
configuration, 84
NAT configuration between inside
interface and, 79
NAT configuration between outside
interface and, 80
outbound connections from, 80
DNS Guard, 168
DNS, Quick Configuration utility for,
346–348, 347
domain-name command, 47, 49, 232
Downloadable PIX ACLs, 132–133
dual-homed gateways, 6–7
dynamic addressing, IKE Mode Config
for, 249–250
Dynamic Host Configuration Protocol
(DHCP), FWSM and, 23
dynamic Network Address Translation
(NAT), 61–62
and security, 63
dynamic translations with NAT, 19
E
editing, in command-line interface, 30
EHLO command, Mail Guard and, 161
embryonic state, 159–160
setting limits of connections in, 161
enable command, 29, 32–33
506
enable password – filter url command
enable password, 16, 29
for PDM login, 212
enable password command, 33
Encapsulating Security Payload (ESP),
305–306, 306, 491
encryption, 309, 491
Enhanced SMTP (ESMTP), 162
Entrust, 425
erasing
CA-related items, 236
configuration on flash, 36
error statistics for interface, displaying,
35
ESP. See Encapsulating Security Payload
(ESP)
/etc/services file, 149
Ethernet, for PIX Firewall, 55
exam essentials
access-control lists (ACLs), 134
IKE (Internet Key Exchange), 281
intrusion detection, 176
IPSec, 323–324
PIX Firewall, 37–38
configuration, 92–93
failover, 221
protocols, advanced handling, 176
virtual private networks (VPNs),
281–282, 367–368
VPN concentrator monitoring, 444,
480
exclamation mark (!), for profile
read-only parameters, 255
exit command, 30
EXPN command, Mail Guard and, 162
extended authentication (Xauth),
248–249, 491
external network, internal host access
to, 76
extranet VPN, 299, 491
F
failover command, 204–205
Failover license, 18
failover link command, 206
failover of PIX Firewall, 195–208
configuration replication, 202–203
exam essentials, 221
features, 195
how it works, 196–203, 197, 198
monitoring, 199–202
nonstateful, 206
poll interval configuration, 206–207
requirements, 195–196
role configuration, 207–208
stateful, 203, 204
basic configuration, 204–208
logical, 205
testing, 194
failover poll command, 207
failover standby server, copying current
configuration onto, 36
Fast Ethernet, 16
for PIX Firewall, 55
fault, 491
fault tolerance, 190–194, 491
points of failure, 190–192
strategies, 194
file management, administration, 476,
476–478
file system, for Cisco's IOS, 14
File Transfer Protocol (FTP), 15,
151–154
inbound traffic, 75
setting restrictions, 153–154
filter, 491
filter activex command, 109–110
filter java command, 110
filter url command, 109
filter url except command – Generic Routing Encapsulation (GRE)
filter url except command, 110
filtering
problems, 322
VPN concentrator configuration for,
410–413, 412
Finesse, 12
firewall, 4–11, 491. See also PIX Firewall
basics, 4–5
combinations, 9–11
packet-filtering router, stateful
firewall with application
proxy, 9–11, 10
stateful firewall with multiple
interfaces, 11, 11
dual-homed gateways, 6–7
feature set for IPSec software,
436–439
"are you there" feature, 436
central policy protection, 437
client firewall statistics, 437–438
customizing policy, 439
stateful firewalls, 436–437
location, 5
packet-filtering firewalls, 7–8
split tunneling and, 407
stateful, 8–9, 497
with multiple interfaces, 11, 11
with packet-filtering router and
application proxy, 9–11, 10
setup, 421–423
as system, 5
Firewall Services Module (FWSM),
22–28
CatOS switch configuration, 25–26
configuration, 27–28
configuration overview, 23–24
connecting to module, 26–27
IOS switch configuration, 24–25
firewall vlan-group command, 24
fixup protocol command, 149–151
507
fixup protocol ftp command, 153–154
fixup protocol sqlnet command, 155
fixup protocol stsp command, 156–157
flash
certificate storage, 232
copying current configuration onto,
36
copying image or PDM file onto, 31
erasing configuration on, 36
saving running configuration to, 219
flash file system in PIX Firewall, 14–15
flash partitions, 15
floodguard command, 160
floppy disk, copying current
configuration onto, 36
FQDN (fully qualified domain name),
491
specifying, 49
fragment chain command, 168
fragment size command, 168
fragment timeout command, 168
fragmentation, 491
IP feature, preventing attacks using,
165–168
FTP (File Transfer Protocol), 15,
151–154
inbound traffic, 75
setting restrictions, 153–154
ftpd daemon, 151
fully qualified domain name (FQDN),
491
specifying, 49
FWSM. See Firewall Services Module
(FWSM)
G
Generic Routing Encapsulation (GRE),
299
508
global command – IKE (Internet Key Exchange)
global command, 64–68
for PAT configuration, 73
global IP address
in NAT, 19
redirecting packets to different local
address, 74–75
global profile, 491
for remote users on VPN, 255
features controlled by, 256–258
group name, for VPN concentrator
configuration, 399
group-object command, 118
guard. See attack guards
hosts on inside network, access to
outside network, 67
Hot Standby Router Protocol (HSRP),
194
HTTP (Hypertext Transfer Protocol)
inbound traffic, 75
virtual, 130–132
http server enable command, 212
hw-module module slot-number reset
cf:4 command, 27
HyperTerminal, 28
I
H
H.323 conferencing protocol, 158
hardening system, 194. See also fault
tolerance
hardware
for PDM, 209
as point of failure, 191–192
Hardware client. See Cisco 3002 VPN
Hardware client
Hardware Client Manager, 349, 349
Hashed Message Authentication Code
(HMAC), 308, 491
hashing, 307–308, 492
by Authentication Header protocol,
303
hello packets, missing, 201–202
HELO command, Mail Guard and, 161
HELP command, Mail Guard and, 162
hierarchical object grouping, 118–119
highly reliable, 492
highly reliable system, 191
HMAC (Hashed Message
Authentication Code), 308, 491
hostname command, 47, 49
ICMP-type object group, 492
ICMP Type Object Group mode,
116–117
identity certificate, 425
identity NAT, 69–70, 492
idle timeout, default for telnet, 46
IDS signatures, FWSM and, 23
IGMP (Internet Group Management
Protocol), 12
igmp access-group command, 91
igmp commands, 91
igmp forward interface command, 91
igmp join-group command, 91
igmp max-groups command, 92
igmp query-max-response-time
command, 92
igmp version command, 92
IKE (Internet Key Exchange), 302,
311–313, 492
certificate authorities, 313
configuration on firewall, 229–236
certificate authorities on firewall,
232–236
certificate information display,
235–236
IKE Mode Config – intranet VPN
enabling, 229
policy configuration, 230–231
preshared keys, 231
error messages, 247
exam essentials, 281
policy creation, 251
preshared keys, 311–312
RSA-encrypted nonces, 312
RSA signatures, 312
tunnel details, 230
viewing policies, 244–245
IKE Mode Config, for dynamic
addressing, 249–250
IKE policy, 492
image, copying onto flash, 31
inbound FTP traffic, 75
inbound HTTP traffic, 75
inbound packets, PIX Firewall
processing of, 20–21
inbound telnet traffic, 75
individual profiles, 492
for remote users on VPN, 255
inetd program, 151
informational signature class for IP
audit, 169
inside global, 492
inside global address in NAT, 60
inside interface, 17, 54, 492
configuration, 85
NAT and, 19
NAT configuration between outside
interface and, 79
inside local, 492
inside local address in NAT, 60
InstallShield, 364
integrity of data, 490
IPSec and, 237, 303
Intel Pentium processors, for PIX
Firewall, 14
interactive authentication, Cisco
Hardware client for, 352–354
509
interesting traffic, 317–318
and tunnel creation, 318
interface cards, slots for, 17
interface command, 56–57
interface ethernet0 shutdown command,
56
interface vlan command, 24
interfaces, 16–17
configuration, 53–59
IP address assignment, 57–58
maximum transfer unit, 58–59
naming and security level
assignment, 53–55
NAT on multiple, 77–85, 78, 82
setting properties and shutting
down, 56–57
for VPN 3002 hardware client,
337–338
crypto maps for, 241
displaying information about, 34–35,
456, 457
setting, 389
traffic flow between, 27
for VPN concentrators, Web Quick
Configuration mode for, 395
Internet Assigned Number Authority,
149
Internet Group Management Protocol
(IGMP), 12
Internet Key Exchange (IKE). See IKE
(Internet Key Exchange)
Internet Protocol Security (IPSec), 492.
See also IPSec (Internet Protocol
Security)
Internet Security Association and Key
Management Protocol (ISAKMP),
229, 311, 492
Internetwork Packet Exchange (IPX)
addresses, packet-filtering firewall
use of, 7
intranet VPN, 298–299, 492
510
intranet WAN networking – IPSec (Internet Protocol Security)
intranet WAN networking, 301
intrusion detection, 92, 169–175
exam essentials, 176
IP audit, 169–174
intrusion detection system (IDS), 492
IOS switch, configuration for FWSM,
24–25
ip address command, 57
to enable PPPoE, 112–113
IP addresses
aliases for, 50
assignment for VPN concentrator
tunnel, 396–397
configuration, for VPN 3002
hardware client, 339–340
excluding range from URL filtering,
110
of interface, displaying, 35
packet-filtering firewall use of, 7
ping to test, 479, 479
as point of failure, 193
pool for clients, 51, 249
of private network interface, 388
private reserved, 59
of telnet sessions, 36
translation, 59–62. See also address
translation
ip audit attack action command, 169
ip audit info action command, 169
ip audit interface command, 170
ip audit name command, 169
IP Fragmentation Guard, 165–168
IP header, fields, 166
IP in IP encapsulation, 299
ip local pool command, 249
IPSec group, configuration, for VPN
3002 hardware client, 340
IPSec (Internet Protocol Security), 299,
302, 302–317
Authentication Header protocol,
303–305, 304
configuration, 237–244
crypto ACL creation, 237–238
crypto maps, 241
transform set creation and
configuration, 238–240
tunnel lifetime, 240
verifying and troubleshooting,
244–248
Diffie-Hellman key exchange,
309–310
digital certificate configuration,
424–435
public key infrastructure, 424,
424–425
requesting and installing client
certificates, 433–435
requesting and installing
concentrator certificates,
425–433
Encapsulating Security Payload,
305–306, 306
encryption, 309
error messages, 247
exam essentials, 323–324
hashing, 307–308
how it works, 317–321
defining interesting traffic,
317–318
IKE phase 1, 318–319
IKE phase 2, 320
task flow, 320–321, 321
Internet Key Exchange (IKE),
311–313. See also IKE (Internet
Key Exchange)
license for encryption, 18
and NAT, 62
Quick Configuration utility for, 344,
344–345
security associations (SAs), 315–317
services, 303
IPSec over TCP – "man-in-the-middle" attack
for telnet session to outside interface,
46
transform sets, 313–315
troubleshooting, 322–323
tunnel mode or transport mode, 307,
307, 308
for VPN concentrator groups, 404,
404–405
for VPN concentrators, 396
IPSec over TCP, 439, 443
Cisco Hardware client for, 351
IPSec over UDP, 406, 439, 441–442
IPSecdlr.ini file, 362
isakmp client configuration address-pool
local name command, 249
isakmp enable command, 229
isakmp identity command, 231
ISAKMP (Internet Security Association
and Key Management Protocol),
229, 311, 492
isakmp key command, 249
no-xauth parameter, 248
isakmp peer fqdn command, 249
no-xauth parameter, 248
isakmp policy command, 230, 251
isp account, 472
511
Layer 2 Forwarding (L2F), 299
Layer 2 Tunneling Protocol (L2TP), 299,
396
lease time for DHCP, 52
LEDs, monitoring, 456–458, 457
licensed features in PIX Firewall, 18
and failover, 196
load balancing, 194, 493
Cisco Hardware client for, 354–356
VPN concentrator configuration for,
414–416
local address in NAT, 19
location of firewall, 5
logging
concentrator events
configuration, 465–466, 466
custom event classes, 466
internal tools, real-world scenario,
470–471
local, on VPN concentrator, 469,
469–470
logging command, 52–53
logging console command, 52
logging timestamp feature, 47
Login authentication for PDM, 212
login password, 16
longurl-deny command, 110
longurl-truncate command, 110
J
Java applets, blocking, 110
jobs in PIX MC, 277
L
LAN-to-LAN IPSec, 493
configuration, 416–418, 417
LAN-to-LAN session, 493
statistics, 463, 464
troubleshooting, 418
M
MAC addresses, packet-filtering firewall
use of, 7
MAIL command, Mail Guard and, 161
Mail Guard, 161–163
Main mode communication for IKE
phase 1, 319
"man-in-the-middle" attack, 6
512
management session – networks
management session, 493
statistics, 464, 464
maximum query response time, for
multicast routing, 92
maximum transfer unit, setting, 389
MC (PIX Management Center), 275,
275–277, 276, 494
memory in PIX Firewall, 14
Memory Utilization graph, in PDM,
218, 220
menus in VPN Concentrator Manager,
400
Message Digest 5 (MD5), 308
Microsoft Point-to-Point Encryption
(MPPE), 331
mis account, 472
Monitor mode, 29
monitoring
for failover, 199–202
PIX Firewall, 217
mroute command, 12, 91–92
MSI, 364
mtu command, 58
Multicast Configuration mode, 91
multicast interface command, 91
multicast routing, 12
configuration, 90–92
debugging forwarding events, 92
multicast support, 12
multimedia protocols, 156–158
multimedia support, 156–158
multinetting, 53
N
N2H2, 108
url-server command for, 109
name command, 50
for firewall configuration for
preshared key, 231
nameif command, 27, 53–54
names command, 50
NAS (Network Access Server), 121
NAT. See Network Address Translation
(NAT)
nat 0 access-list command, 72
nat 0 command, 69, 72
nat command, 64–68
for PAT configuration, 73
NAT ID, for interface pairs, 83
NAT-Transversal, 442
nCube, 155
NetMeeting (Microsoft), 158
Network Access Server Configuration
window, 122
Network Access Server (NAS), 121
Network Address Translation (NAT),
12, 18, 19, 493
access blocking with ACLs, 70–72
configuration, 64–72
on multiple interfaces, 77–85, 78,
82
nat and global commands, 64–68
simple example, 65
static command, 68
consequences, 62
global and local addresses, 60
identity NAT, 69–70
Real-Time Streaming Protocol (RTSP)
and, 157
and security, 63
static and dynamic, 61–62
troubleshooting, 323
Network Management Processor
(NMP), 23, 493
network object group, 493
Network Object Group Configuration
mode, 116
network-object host command, 116
Network Time Protocol (NTP), 232, 493
networks, potential threats, 6
Next Header field – Passive-mode FTP
Next Header field, in ESP, 306
NIMDA virus, 80
NMP (Network Management
Processor), 23, 493
no access-list compiled command, 105
no ca identity command, 236
no ca save all command, 236
no shun command, 175
nonstateful failover
configuration, 206
uses, 205
NOOP command, 164
Mail Guard and, 162
ntp authentication command, 48
ntp command, 48–49
NTP (Network Time Protocol), 232
ntp server command, 48
ntp trusted-key command, 49
513
outbound command, 104
outbound packets, PIX Firewall
processing of, 20
outside global, 493
outside global address in NAT, 60
outside interface, 17, 54, 493
configuration, 83–84
IPSec for telnet session to, 46
NAT and, 19
NAT configuration between DMZ
and, 80
NAT configuration between inside
interface and, 79
for PPPoE client, 112
outside local, 493
outside local address in NAT, 60
outside network, access by hosts on
inside network, 67
overengineering, 194
overloading, 61
O
Oakley key exchange protocol, 229
object-group command, 115
Object Group Configuration mode, 115
object groups, 493
configuration, 115–119
nesting, 118–119
oem.ini file, 364
Open Shortest Path First (OSPF)
protocol, 23
operating systems
Cisco VPN client support for,
253–254
default location for profile files, 255
for PDM, 209
as point of failure, 191
standardizing for clients, 365
Oracle, 154–155
OTHER keyword, for static routes, 89
P
packet-filtering firewalls, 7–8, 494
packet-filtering FTP, access control lists
for, 153
packet-filtering router, with stateful
firewall and application proxy,
9–11, 10
packets
debugging, 32
interface traffic, displaying, 35
PIX Firewall configuration to route,
87
PIX Firewall processing of, 20–21
Pad Length field, in ESP, 306
Padding field, in ESP, 306
partner interfaces, configuration, 84
Passive-mode FTP, 152–153, 494
514
passwd command – PKCS (Public Key Cryptography System)
passwd command, 33
Password Authentication Protocol
(PAP), 111, 494
passwords
@ symbol for AAA server and Web
server, 130
for PPPoE client, 111–112
in preconfigured files, 363
security for, 16
PAT. See Port Address Translation
(PAT)
.pcf extension, 255, 258, 494
features controlled by, 259–261
PDM. See Cisco PIX Device Manager
(PDM)
PDM file, copying onto flash, 31
pdm history enable command, 212
Perfect Forward Secrecy (PFS), 320
perfmon command, 33–34
performance
split tunneling and, 408
VPN termination on router, 330
permit statements, 412
pessimistic security model, 12
PFS (Perfect Forward Secrecy), 320
physical interfaces, for VPN
concentrator configuration, 395
pinging devices, 479, 479
PIX (config)# prompt, to configure
interfaces, 53
PIX Firewall. See also failover of PIX
Firewall
AAA implementation, 125–132
accounting, 129–130
authentication, 127–128
authorization, 128–129
virtual HTTP and telnet, 130–132
activation key for, 18
bootstrap configuration for,
276–277, 280
components, 13–17
BIOS, 15
CPU, 14
flash file system, 14–15
interfaces, 16–17
RAM, 14
system image, 15
configuration
exam essentials, 92–93
global commands, 45–53
interfaces, 53–59
NAT and PAT, 59–85
PIX Device Manager for, 212–219
preparation, 44–45
routing, 85–92
for URL filtering, 108–111
enterprise management
Auto Update Server (AUS),
277–281, 278
Cisco Secure Policy Manager, 273,
273–274
PIX Management Center (MC),
275, 275–277, 276, 494
exam essentials, 37–38
features, 12
licensed features, 18
operation, 18–22
Adaptive Security Algorithm
(ASA), 21–22
packet processing, 20–21
points of failure, 192
product line, 17
serial number for, 18
for VPN, 300
PIX Firewall Manager, FWSM and, 23
PIX Management Center (MC), 275,
275–277, 276, 494
PKCS (Public Key Cryptography
System), 234, 425
PKI (Public Key Infrastructure) – protocols
PKI (Public Key Infrastructure), 424,
424–425, 495
point of failure, 494
Point-to-Point Protocol over Ethernet
(PPPoE), 111–115, 494
client username and password
configuration, 111–112
enabling on PIX Firewall, 112–113
verifying operation, 113–115
Point-to-Point Tunneling Protocol
(PPTP), 299, 396
and NAT, 62
statistics, 460, 461–462
policy enforcement point (PEP), firewall
as, 5
poll interval, configuration for failover,
206–207
pool of addresses
for client configuration, 51
for VPN concentrator tunnels, 397
Port Address Translation (PAT), 61–62,
494
configuration, 73–77
checking, 76–77
commands for inside to outside
requirements, 76
Quick Configuration utility for,
345, 345–346
static commands for outside to
inside requirements, 75–76
overview, 440–441
and security, 63
port numbers, 149
assigning multiple to protocol, 150
TCP/UDP, 126
port-object eq command, 118
port-object range command, 118
port redirection, 74–75, 494
ports, for authorization, 129
Postel, Jon, 161
515
power loss, and PIX Firewall failover,
202
power supplies, monitoring, 456, 457
PPP Session phase, 111
PPPoE. See Point-to-Point Protocol over
Ethernet (PPPoE)
PPTP. See Point-to-Point Tunneling
Protocol (PPTP)
preshared keys, 230, 311–312, 494
configuration, 231
for remote access clients, 252
primary, 494
primary unit for PIX Firewall failover,
198–199
privacy violation, 6
private interface, 494
Quick Configuration utility for, 343,
343
for VPN 3002 hardware client, 336
private Internet eXchange (PIX). See PIX
Firewall
private key, 494
private keys, 427
for certificates, generating, 233
in Diffie-Hellman key exchange,
309–310
private reserved IP addresses, 59
Privileged mode, 29
enable command to control access,
32–33
profile configuration file, 494
profile, for remote users on VPN, 255
protection suite, 494
protocol-object command, 115–116
protocol object group, 494
protocols. See also specific names of
protocols
advanced handling, 148–159
alternatives, 158–159
exam essentials, 176
516
proxy server – remote management of VPN concentrator
File Transfer Protocol, 151–154
multimedia support, 156–158
Remote Shell, 154
special protocol support basics,
149–151
SQL*Net, 154–155
assigning multiple ports to, 150
as point of failure, 192
proxy server, 495
public interface, 495
Quick Configuration utility for, 344,
344
for VPN 3002 hardware client, 336
Public Key Cryptography Standard #10
(PKCS #10), 495
Public Key Cryptography System
(PKCS), 234, 425
Public Key Infrastructure (PKI), 424,
424–425, 495
public keys, 427, 495
for certificates, generating, 233
in Diffie-Hellman key exchange,
309–310
Q
queue for storing SYSLOG messages, 52
Quick Configuration, 495
Quick Configuration mode. See Web
Quick Configuration mode
Quick Configuration Wizard, 386–387
QUIT command, Mail Guard and, 162
R
RADIUS, for VPN user authentication,
248
RAM in PIX Firewall, 14
RAS (Remote Access Services), 301
RCP command, Mail Guard and, 161
read-only parameters, in profile file, 255
Real-Time Streaming Protocol (RTSP),
156–157
Real-Time Transport Protocol (RTP),
156
RealPlayer, Real-Time Streaming
Protocol (RTSP) and, 157
redundancy, 194
rules for cluster devices, 415
registration authority (RA), 424, 495
reload command, 34
remote access commands, 45–47
Remote Access Services (RAS), 301
remote-access session, 495
statistics, 463, 464
remote access virtual private networks
(VPNs), 248–253
common commands, 251–253
extended authentication (Xauth),
248–249
IKE mode config for dynamic
addressing, 249–250
pushing additional attributes to client,
250
remote access VPN
PDM to create, 268, 268–272, 269,
270, 272
properties for VPN concentrator
groups, 404–405
Remote Authentication Dial-In User
Service (RADIUS) protocol, for
CiscoSecure ACS for Windows
2000/NT, 123
remote computer, opening shell on, 154
remote host, sending logs to, 52
remote management of VPN
concentrator, 465–470
custom event classes, 466
event configuration for logging,
465–466
Remote Shell (RSH) – screened subnet
logging method, 465
logging on to syslog server, 468
SNMP configuration, 466–467, 467
viewing local log, 469–470
Remote Shell (RSH), 154
replication of PIX Firewall failover units,
202–203
Request for Comments
821 on Simple Mail Transfer
Protocol, 161
1631 on IP address translation, 59
1826 on Authentication Header
protocol, 303
1918 on address ranges for private
use, 59
2058 for TCP/UDP port numbers,
126
2402 on Authentication Header
protocol, 303
2406 on Encapsulating Security
Payload, 305
2409 on Internet Key Exchange, 311
2631 on Diffie-Hellman key exchange
protocol, 309
3022 for IP address translation, 59
Restricted license, 18
connection slot limits, 19
restrictive security model, 12
"return status is IKMP_NO_ERROR"
message, 247
Reverse Route Injection (RRI), Cisco
Hardware client for, 350
Rijndael algorithm, 309
RIP. See Routing Information Protocol
(RIP)
rip command, 86–87
passive keyword, 87
Rivest, Shamir, and Adleman. See RSA
signatures
RJ-45 (console connector) port, 16
517
route command, 87
routing, 21
configuration, 85–92
dynamic routing, 86–87
multicast routing, 90–92
static routing, 87–90, 88
Routing Information Protocol (RIP), 86
debug output for, 32
routing loops, 87, 192
routing protocols, as point of failure,
192
routing table
displaying, 88
displaying information about, 458,
459
RRI. See Reverse Route Injection (RRI)
RSA-encrypted nonces, 312
RSA encryption keys, setup with SSH, 47
RSA signatures, 312, 495
RSET command, Mail Guard and, 162
RSH (Remote Shell), 154
RTP (Real-Time Transport Protocol),
156
RTSP (Real-Time Streaming Protocol),
156–157
rule, 495
for filters, 412
S
SafeNet Client, 301, 496
SAs (security associations), 315–317,
316, 496
viewing, 246
Scalable Encryption Processing (SEP),
496
modules, 334
screened subnet, 9, 496. See also DMZ
(demilitarized zone)
518
secondary – show ip command
secondary, 496
secondary unit for PIX Firewall failover,
198–199
setting as active unit, 207
Secure Hash Algorithm (SHA), 308
Secure Shell Protocol (SSH), 28, 154
Secure Sockets Layer (SSL), 496
PDM and, 208
secure VLAN interface (SVI), 23, 496
secure VLANs, 23
security
address translation and, 63
IPSec and, 237
ISAKMP (Internet Security
Association and Key
Management Protocol) and, 229
for PIX Firewall, 16
potential threats, 6
split tunneling and, 407
static routes vs. RIP, 90
TCP connections and, 152
security associations (SAs), 315–317,
316, 496
viewing, 246
security level
for ASA, 22
assigning to interface, 53–55
interfaces configured with same, 55
and local and global interfaces, 66
serial number, for PIX Firewall, 18
service object group, 118, 496
session command, 26
session slot number processor 1
command, 26
sessions
administration, 475, 476
statistics, 459, 461, 463–464
set vlan vlan-list firewall-vlan command,
25
setroute command, 112
setroute keyword, 58
Setup Wizard in PDM, 208
SHA (Secure Hash Algorithm), 308
shared secret, 309, 496
shell, opening on remote computer, 154
shortcut keys, for command-line
interface editing, 30
show access-list command, 245
show ca certificate command, 235
show ca identity command, 236
show ca mypubkey rsa command, 235
show checksum command, 34
show clock command, 48
show command, to check PAT
configuration, 76–77
show CPU usage command, 14
show crypto ipsec sa command, 246
show crypto ipsec security-association
lifetime command, 246
show crypto ipsec transform-set
command, 245
show crypto map command, 245
show dhcpd command, 52
show firewall module command, 24
show firewall vlan-group command, 24
show fixup command, 150
show flashfs command, 14–15
show fragment command, 168
show igmp command, 91, 92
show interface command, 16, 34–35, 57
for status of interface, 200–201
show interface vlan command, 25
show ip address outside pppoe
command, 113
show ip audit count command, 171–172
show ip audit count global command,
173–174
show ip audit count interface outside
command, 172–173
show ip command, 66
show isakmp policy command – statistics
show isakmp policy command, 244–245
show logging command, 52
show memory command, 14
show mroute command, 92
show multicast command, 92
show nameif command, 66
show ntp associations command, 49
show ntp status command, 49
show route command, 88, 89
show shun command, 175
show tech-support command, 35
show version command, 13
show vlan firewall-vlan command, 26
show vpdn group command, 114
show vpdn pppinterface command, 114
show vpdn session pppoe command, 114
show vpdn tunnel pppoe command,
113–114
show xlate command, 19, 77
shun command, 35–36, 175
shunning, 175, 496
shutting down interface, 56–57
signature, 496
signature classes for IP audit, 169
disabling, 170
Simple Network Management Protocol
(SNMP), 454, 496
configuration for VPN concentrator,
466–467
information gathering from servers,
163–164
logging, 52
and NAT, 62
single point of failure, 191, 496
site-to-site VPN, PDM to create, 263,
263–266, 264, 265, 266
Skeme key exchange protocol, 229
SMR (Stub Multicast Routing), 90–92,
497
519
SNMP. See Simple Network
Management Protocol (SNMP)
Split DNS Names, 407
split tunnel, 496
Split Tunneling Network List, 407
Split Tunneling Policy, 407
real-world scenario, 407–408
SQL*Net, 154–155
ssh command, 46–47
SSH (Secure Shell Protocol), 28, 154
standby, 496
standby unit for PIX Firewall failover,
198–199
stateful failover of PIX Firewall, 203,
204, 497
basic configuration, 204–208
logical, 205
stateful firewalls, 8–9, 497
with multiple interfaces, 11, 11
with packet-filtering router and
application proxy, 9–11, 10
setup, 421–423
on VPN client, 436–437
static command, 67, 68
and conduit command, 106–107
for outside to inside requirements,
75–76
static IP addresses, for interfaces, 58
static Network Address Translation
(NAT), 61–62
static PAT, for inbound traffic, 73–74,
74
static routing, 87–90, 88
Quick Configuration utility for, 348,
348
static translations with NAT, 19
statistics
for client firewall, 437–438
for VPN concentrators, 458–463, 460
520
stderr (standard error) – toolbar
stderr (standard error), 154
stdin (standard in), 154
stdout (standard out), 154
strict keyword, for fixup protocol ftp
command, 154
Stub Multicast Routing (SMR), 90–92,
497
subordinate CAs, 424, 497
SVI (secure VLAN Interface), 23, 496
switchport trunk allowed vlan remov
command, 25
symmetric key encryption, 310
SYN flood, 160, 497
SYN Flood Guard, 160–161
synchronization of clock, 48
syslog, 497
syslog server, 52, 454, 465
logging on to, 468
syslog view in PDM, 209
sysopt connection permit-ipsec
command, 231
sysopt security fragguard command, 167
system clock, setting, 47, 387
system image in PIX Firewall, 15
system information
configuration, for VPN 3002
hardware client, 338
for VPN concentrator configuration,
395–396
System Reboot screen, 477
T
TACACS+ protocol, 128
for CiscoSecure ACS for Windows
2000/NT, 123
for VPN concentrators, 398
for VPN user authentication, 248
TCP Intercept, 160–161
TCP/IP. See Transmission Control
Protocol/Internet Protocol (TCP/IP)
technical support, sending show output
to, 35
telnet
for CSPM, 274
inbound traffic, 75
for information gathering, real world
scenario, 163–164
TTY ID and IP address of session, 36
virtual, 131–132
telnet command, 45–46
telnet timeout command, 46
telphony servers, 158
TeraTerm, 28
Terminal Access Controller Access
Control System Plus (TACACS+).
See TACACS+ protocol
terminal, displaying current
configuration, 36
terminal emulator, for command-line
interface access, 28
testing mode for interface, 201–202
TFTP (Trivial File Transfer Protocol),
15, 16, 477–478, 497
copying current configuration onto
server, 36
time, setting system on hardware client,
342, 343
time zone
and certificate validity, 432
setting, 47, 387–388
timeout, idle, default for telnet, 46
timestamp, for SYSLOG messages, 52
TNS. See Transparent Network
Substrate (TNS)
Token Ring, PIX Firewalls support for,
56
toolbar, in VPN Concentrator Manager,
400
traffic delay problems – user and policy management for VPN concentrators
traffic delay problems, 322
transform, 497
transform sets, 313–315, 497
creation and configuration, 238–240
options, 314
translation slot, 19, 497
NAT process to create, 69
and outbound packet processing, 20
and security, 63
translation table, 19. See also xlate table
Transmission Control Protocol/Internet
Protocol (TCP/IP)
as point of failure, 192
subnet failure, real-world scenario,
193
Transparent Network Substrate (TNS),
155
Transport mode, 497
vs. Tunnel mode, 239, 239, 307, 307,
308
Triple Data Encryption Standard
(3DES), 309, 497
license, 18, 300
Trivial File Transfer Protocol (TFTP),
15, 16, 477–478, 497
copying current configuration onto
server, 36
troubleshooting
IPSec, 322–323
LAN-to-LAN connections, 418
sending show output to technical
support, 35
speed of response, 72
trunks, preventing from carrying secure
VLANs, 25
trusted networks, 5
TTY ID, of telnet sessions, 36
tunnel, 497
creation method for VPN
concentrator configuration, 396
521
statistics, 459
VPN as, 299
tunnel lifetime, 240
Tunnel mode, 497
vs. Transport mode, 239, 239, 307,
307, 308
tunneling protocol, configuration for
VPN 3002 hardware client,
338–339
U
U (measurement unit), 331, 498
Unified Client (Cisco), 302, 356, 498
authentication properties, 357–358,
358
certificate installation, 359–362
connection configuration, 357
connection properties, 358, 359
preconfiguration, 362–364
and user tunnels, 432–433
Unprivileged mode, 29
Unrestricted license, 18
URL buffer size, 110
url-cache command, 110
URL filtering, 108–111
url-server command, 108–109
USB port, 16
user, 498
user account, 472
assigning downloadable PIX ACL to,
133
user and policy management for VPN
concentrators, 399–423
access hours and filters configuration,
410–413, 411
authentication server configuration,
409–410
automatic client update, 418–421
522
user database – remote access
backup on hardware client, 413–414
group setup, 401–408
client properties, 405–408, 406
group creation, 401–402, 402
IPSec and remote access properties,
404, 404–405
property settings, 402–403, 403
GUI, 400
LAN-to-LAN IPSec configuration,
416–418, 417
load balancing configuration,
414–416
stateful firewall setup, 421–423
users setup, 409, 409
user database, for CSNT authentication,
124
User Datagram Protocol Network
Address Translation Transparent
IPSec (UDP NAT Transparent
IPSec), 441
user tunnels, Unified Client and,
432–433
username
@ symbol for AAA server and Web
server, 130
for PPPoE client, 111–112
in preconfigured files, 363
V
Verisign, 425
Virtual Cluster Agent (VCA), 498
Virtual Cluster Agent (VCA) protocol,
416
virtual cluster master (VCM), 354
virtual HTTP, 130–132
virtual http command, 130–131
virtual private dial-up network group,
defining for PPPoE client, 111
virtual private networks (VPNs), 498.
See also IPSec
basics, 298–302
devices, 299–301
major types, 298–299
Cisco client install and configuration,
253–261
connection profiles, 259–261
deployment, 255–261
global profile, 256–258
configuration, preparation, 228–229
exam essentials, 281–282, 367–368
IKE configuration, 229–236
certificate authorities on firewall,
232–236
certificate information display,
235–236
enabling, 229
policy configuration, 230–231
preshared keys, 231
IPSec configuration, 237–244
crypto ACL creation, 237–238
crypto maps, 241
transform set creation and
configuration, 238–240
tunnel lifetime, 240
verifying and troubleshooting,
244–248
PDM to create, 261–272
real-world scenario, 242–244
reasons for using, 301
remote access, 248–253
common commands, 251–253
extended authentication (Xauth),
248–249
IKE mode config for dynamic
addressing, 249–250
pushing additional attributes to
client, 250
Virtual Router Redundancy Protocol (VRRP) – VPN concentrator monitoring
terminating. See also Cisco VPN
Concentrators
on PIX Firewall, 232
wireless network, 365
Virtual Router Redundancy Protocol
(VRRP), 350, 414
virtual telnet command, 131–132
vlan command, 24
vpdn command, 111
VPN Client dialog box, 254
VPN client, pushing additional attributes
to, 250
VPN Concentrator, 498
VPN concentrator monitoring, 454–470
administration, 471–479
access rights configuration,
471–475
file management, 476–478
of sessions, 475, 476
updating software, 478, 478–479
configuration
command line interface (CLI) for
initial, 386–393
information needed, 385
need for, 385
exam essentials, 444, 480
firewall feature set for IPSec software
client, 436–439
"are you there" feature, 436
central policy protection, 437
client firewall statistics, 437–438
customizing policy, 439
stateful firewalls, 436–437
IPSec digital certificate configuration,
424–435
public key infrastructure, 424,
424–425
requesting and installing client
certificates, 433–435
523
requesting and installing
concentrator certificates,
425–433
IPSec over TCP, 439, 443
IPSec over UDP, 439, 441–442
pinging devices, 479, 479
remote management, 465–470
custom event classes, 466
event configuration for logging,
465–466
logging method, 465
logging on to syslog server, 468
SNMP configuration, 466–467,
467
viewing local log, 469–470
rolling out multiple, real-world
scenario, 364–365
user and policy management,
399–423
access hours and filters
configuration, 410–413, 411
authentication server
configuration, 409–410
automatic client update, 418–421
backup on hardware client,
413–414
graphical user interface, 400
group setup, 401–408
LAN-to-LAN IPSec configuration,
416–418, 417
load balancing configuration,
414–416
stateful firewall setup, 421–423
users setup, 409, 409
viewing information, 455, 455–464
Bandwidth Management, 462, 463
general statistics, 458–463, 460
routing table, 458
524
VPN module – write terminal command
session monitoring, 463–464
system status, 456, 456–458
Web Quick Configuration mode,
393–399
address assignment, 396–397
admin password, 399
authentication, 397–398
group name, 399
physical interfaces, 395
system information, 395–396
tunnel-creation method, 396
VPN module, 299–300
VPN/Security Management Solution
(VMS), 275, 498
VPN software client, 300–302, 356–365
authentication properties, 357–358,
358
auto-initiation, 365–367
certificate installation, 359–362
connection configuration, 357
connection properties, 358, 359
preconfiguration, 362–364
vpnclient.ini file, 255, 498
creating, 255–256
features controlled by, 256–258
global configuration parameters in,
362
keys, 367
sample, 257–258, 363
vpngroup command, 250
VRFY command, Mail Guard and, 162
VRRP. See Virtual Router Redundancy
Protocol (VRRP)
W
WANs (wide area networks), VPNs to
replace, real-world scenario,
242–244
web browser, for CiscoSecure ACS
administration, 123
Web Quick Configuration mode for
VPN concentrators, 393–399
address assignment, 396–397
admin password, 399
authentication, 397–398
group name, 399
physical interfaces, 395
system information, 395–396
tunnel-creation method, 396
web resources
on Cisco VPN 3000 client install, 254
on discontinued Cisco modules, 334
on installation automation, 364
PIX Firewall and VPN Configuration
Guide, 45
on Virtual Router Redundancy
Protocol (VRRP) configuration,
414
on VPN client profile file variables,
363
on wireless security protocols, 366
Web server application, as point of
failure, 191
Websense, 108
url-server command for, 109
who command, 36
Windows 2000, certificate authority
(CA), 425
Windows 2000/NT. See CiscoSecure
ACS for Windows 2000/NT
wireless network, with VPN, 365
write command, 36–37
write mem command, 234
write memory command, 203
write standby command, 203
write terminal command, 30, 150
X.509 standard – ZoneAlarm
525
X
Z
X.509 standard, 425
Xauth (extended authentication),
248–249, 491
xlate table, 19, 498
failover and, 203
Zero Length Body (ZLB), 461
Zone Labs Integrity Agent and Integrity
server, 422
ZoneAlarm, 436
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement