PIX Firewall Keys

Y Step-by-Step Guide to Success our With the PIX Firewall

By Eric S. Severson President / Sr. Network Consultant Key IT Consulting Eric S. Severson and Key IT Consulting
You do not have resell rights or giveaway rights to this eBook. Only customers that have purchased this material are authorized to view it. This eBook contains material protected under International and Federal Copyright Laws and Treaties. No part of this publication may be transmitted or reproduced in any way without the prior written permission of the author. Violations of this copyright will be enforced to the full extent of the law. LEGAL NOTICE: The information services and resources provided in this eBook are based upon the current Internet environment as well as the authors experience. The techniques presented have been proven to be successful. Because technologies are constantly changing, the services and examples presented in this eBook may change, cease or expand with time. We hope that the skills and knowledge acquired from this manual will provide you with the ability to adapt to inevitable evolution of technological services. However, we cannot be held responsible for changes that may affect the applicability of these techniques. All product names, logos and artwork are copyrights of their respective owners. None of the owners have sponsored or endorsed this publication. While all attempts have been made to verify information provided, the author assumes no responsibility for errors, omissions, or contrary interpretation of the subject matter herein. Any perceived slights of peoples or organizations are unintentional. The purchaser or reader of this publication assumes responsibility for the use of these materials and information. No guarantees of income are made. The author reserves the right to make changes and assumes no responsibility or liability whatsoever on behalf of any purchaser or reader of these materials.

T ableof Contents
SECTION 1 THE GROUNDWORK ................................................................................................................ 3 INTRODUCTION................................................................................................................................................ 3 THE NEED FOR NETWORK SECURITY ......................................................................................................... 5 NETWORK SECURITY IN BUSINESS ............................................................................................................. 6 NETWORK SECURITY IN THE HOME............................................................................................................. 7 PIX FEATURES AND BENEFITS ..................................................................................................................... 8 CISCO PIX FIREWALL AT-A-GLANCE ...................................................................................................... 11 SECTION 2 THE TECHNICAL STUFF ........................................................................................................ 12 TECHNICAL OBJECTIVES............................................................................................................................. 12 PIX BASICS..................................................................................................................................................... 14 PIX SECURITY ................................................................................................................................................ 33 OUTBOUND COMMUNICATIONS THROUGH THE PIX ............................................................................... 37 INBOUND COMMUNICATIONS THROUGH THE PIX ................................................................................... 48 VIRTUAL PRIVATE NETWORKING (VPN) WITH THE PIX........................................................................... 64 PIX DEVICE MANAGER (PDM) / ADAPTIVE SECURITY DEVICE MANAGER (ASDM) ............................. 98 FIXUPS / INSPECT........................................................................................................................................ 102 PIX QUICK CONFIGURATION GUIDE......................................................................................................... 104 SCENARIO 1 PIX 501 CONFIGURED FOR BASIC INTERNET ACCESS ............................................................... 104 SCENARIO 2 PIX CONFIGURED AS A DHCP CLIENT TO AN ISP..................................................................... 110 SCENARIO 3 PIX WITH PORT REDIRECTION TO AN INTERNAL WEB SERVER AND A REMOTE DESKTOP CLIENT. 114 SCENARIO 4 PIX CONFIGURED AS A DHCP SERVER FOR THE INSIDE NETWORK ........................................... 118 SCENARIO 5 USING ICMP (PING) TO TEST CONNECTIVITY THROUGH THE PIX FIREWALL .............................. 121 USEFUL COMMAND REVIEW FAQ............................................................................................................. 123 CONCLUSION ............................................................................................................................................... 128

Section 1 The Groundwork

Introduction Congratulations on taking your first step to understanding how to successfully configure and deploy a Cisco PIX Firewall. I am confident that this eBook will show you the fundamentals of the PIX Firewall and will give you the resources you need to secure your network infrastructure. What you do with the knowledge you will gain from reading the following pages is up to you, but this I can say with all confidence, that if you apply the teachings you will learn here you will walk away with a great potential to succeed.

My success in the IT world has come due hard work, a constant desire to learn and understand new and existing technology, a focus on following the big players in the industry, (specifically Microsoft and Cisco Systems) and a few good breaks. Also included in my success is the fact that I strive to do all my work with excellence, communicate honestly, do what I say Im going to do, and have a desire to help people out when it comes to technology. I believe anyone with an aptitude to learn and to think logically can excel in the field of IT Networking.

I have personally mentored and helped other people who may not have had as much practical experience as I have had and watched them grow and succeed in the field of IT Networking. The conclusion I have come to is this: If someone really wants to learn and are willing to be taught, they will ultimately succeed. If you are hungry for knowledge you will be fed. The knowledge you gain can be immediately put to practice. My goal in this eBook is to mentor you on the PIX Firewall so that you will have the tools necessary to put the knowledge into practice.
3

As I have fully immersed myself into the field of Network Engineering and IT Security for the past nearly ten years, I know that it is a rewarding and lucrative career to be in. For those of us who are always interested in new challenges, this field is one that will always keep you on your toes. Technology is in a constant state of flux which helps to ensure your job as an IT professional will never become mundane. I believe Network Security is a field that will only continue to grow in the coming years and I plan on staying on the forefront of new technologies as they arise. The Cisco PIX Firewall is here to stay, so learn all you can about it, and launch into new heights in your own career by configuring and deploying the PIX everywhere you can.

This eBook is the result of hands-on working experience with the PIX, including various hardware platforms and software versions, and summarizes all of the core concepts, components and fundamentals that a Firewall Administrator or Engineer must know and practice when working with a PIX Firewall.

This eBook can be used in conjunction with other documentation sources and may be complementary to other books out there on the Cisco PIX Firewall. My goal is to lay out the fundamentals of the PIX from a conceptual and practical perspective to give the Firewall Administrator or Engineer direct knowledge and understanding pertaining to the PIX.

My goal is that you will find this eBook beneficial, helpful and tailored to your practical needs whether you are new to the PIX entirely, simply need a PIX refresher course, or would like to have a useful technical reference in your network arsenal to refer back to whenever needed.
4

The Need for Network Security The Internet is an amazing tool that has changed the way we work, live, communicate, play, and learn. There are currently tens of millions of devices connected to the Internet and millions more on the way. Many of us have grown very reliant on the Internet to learn just about anything we might be interested in, to communicate with friends and relatives thousands of miles away, or to do a variety of business activities. However, with all of the positive and beneficial aspects of the Internet, there are equally negative aspects. One primary negative aspect is in the form of hackers and crackers. Hackers are those who simply want to exploit a system for the sake of doing it, similar to a prankster or explorer, while crackers are usually in it for financial gain or to do deliberate damage.

Using the Internet, these malicious users have access to a virtual superhighway that they can ride on to target various systems in multiple locations all from the comfort of their own home. Make no mistake about it, they will seek and find vulnerable systems and penetrate them. Not only that, but with enormous amount of data to be found on the Internet, they can easily learn of new security holes or weaknesses to exploit. Hackers love to share information with other hackers and an Internet search on the word hacker will bring up thousands of web sites with instructions on exactly how and what to hack into as well as the ability to obtain software which has been specifically engineered to do most of the work for them.

The bottom line is there is a great need for Network Security. The bad guys will continue to get worse as the Internet continues to grow. It is easy to see that Network Security can be a very prosperous and rewarding field to be in.
5

Network Security in Business The business need for Network Security is obvious. It is a known fact that cyber-attacks continue to plague businesses and institutions. Most large corporations have a dedicated Network Security staff in place to keep up with Firewall modifications, rule changes, business to business (B2B) or site-tosite VPNs. A previous Fortune 500 company I worked for had over 30 full time employees in place to work specifically on Network Security related issues. Large corporations realize the necessity of maintaining Network Security within their organizations.

Small to medium sized businesses are generally another story Most small business owners realize that Network Security is important but consider it similar to insurance in that they know they should have it, but dont want to have to pay for it. This type of mind set ends up being the proverbial shooting oneself in the foot. I believe there has been a shift in this mind set and it will need to continue to go in favor of security. Small to medium sized businesses simply cannot afford to wait around hoping they never get hacked. There needs to be a move from the typical reactive way of dealing with problems after the fact to a more proactive approach. This is where some general education goes a long way. I have been able to successfully show many business owners the necessity of maintaining security with in their networks.

The PIX Firewall is a perfect candidate for any size of business. Later in the eBook I will present a quick sheet showing the many PIX hardware versions available and their associated features. Once the specific business requirements are understood, choosing the right PIX becomes an easy task.
6

Network Security in the Home Imagine if you will, picking up your home personal computer and attaching a long power cord, a long Ethernet or phone line which is connected to your Internet connection, and opening up the front door of your house and walking it outside onto the street. Then you grab your monitor, keyboard and mouse and plug in the peripherals. Next you write a big sign with an arrow pointing to the computer that says, FREE COMPUTER USAGE. This would allow anyone who was interested to come on over and use your computer 24 hours a day for whatever they wanted to do, and while they were at it they could view your personal documents, email messages, possible credit card numbers, passwords and anything else you had stored on your computer. Would you do this? Probably not! However, a PC attached to the Internet without a firewall can be hacked in just a few minutes by automated hacker bots (machines programmed to hack).

The above example is an adequate description of why Network Security is A MUST in the home. With more and more users coming on line everyday and the increase of the always on high-speed Internet connection, it would be foolish not to have a home based Firewall in every Internet connected home. The fact of the matter remains that many unaware and uninformed users are out there, just waiting to be hacked.

With a SOHO (small office / home office) PIX Firewall you can ensure that you and your clients are protected in the home. This can be a win/win relationship. You provide the needed security to your client; they pay you to provide the service.

PIX Features and Benefits Lets take a look under the hood of the PIX. The table below outlines the features and benefits of the PIX:

Feature Enterprise-Class Security

Benefit Uses a proprietary, hardened operating system that eliminates security risks associated with general purpose operating systems Combines Cisco product quality with no moving parts to provide a highly reliable security platform Provides perimeter network security to prevent unauthorized network access Uses state-of-the-art Cisco Adaptive Security Algorithm for robust stateful inspection firewall services Provides flexible access-control capabilities for over 100 predefined applications, services and protocols, with the ability to define custom applications and services Simplifies management of security policies by giving administrators the ability to create re-usable network and service object groups which can be referenced by multiple security policies, thus simplifying initial policy definition and ongoing policy maintenance Integrates over two dozen specialized inspection engines for protocols such as Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP), Domain Name System (DNS), SQL*Net, Microsoft Networking (SMB), Network File System (NFS), H.323 Versions 1-4, Session Initiation Protocol (SIP), Cisco Skinny Client Control Protocol (SCCP), Real-Time Streaming Protocol (RTSP), Internet Locator Service (ILS), and many more Provides remote access VPN concentrator services for up to 2000 remote software or hardware-based VPN clients Pushes VPN policy dynamically to Cisco Easy VPN Remote-enabled solutions (such as the Cisco VPN Client) upon connection, ensuring the latest corporate security policies are enforced Extends VPN reach into environments using NAT or PAT, via support of Internet Engineering Task Force (IETF) UDPbased draft standard for NAT traversal Includes a free unlimited license for the highly acclaimed, industry-leading Cisco VPN Client Available on wide-range of platforms including Microsoft Windows 98/ME/NT/2000/XP, Sun Solaris, Intel-based Linux distributions, and Apple Macintosh OS X Provides many innovative features including dynamic security policy downloading from Cisco Easy VPN Serverenabled products, automatic failover to backup Easy VPN Servers, administrator customizable distributions, and more 8

Reliable, purpose-built security appliance

Stateful inspection firewall

Advanced application and protocol inspection

Easy VPN Server Cisco VPN Client

Site-to-site VPN

Intrusion prevention

AAA support X.509 certificate and CRL support

Integration with leading third-party solutions

Industry certifications and evaluations Robust Network Services/Integration

Integrates with the award-winning Cisco Security Agent (SA) for comprehensive endpoint security Supports IKE and IPSec VPN standards Extends networks securely over the Internet by ensuring data privacy/integrity and strong authentication with remote networks and remote users Supports 56-bit DES, 168-bit 3DES, and up to 256-bit AES data encryption to ensure data privacy Provides protection from over 55 different types of popular network-based attacks ranging from malformed packet attacks to denial-of-service (DoS) attacks Integrates with Cisco Network Intrusion Detection System (IDS) sensors to identify and dynamically block/shun hostile network nodes Integrates with popular authentication, authorization, and accounting services via TACACS+ and RADIUS Provides tight integration with Cisco Secure Access Control Server (ACS) for user/administrator authentication, dynamic per-user/group policies, and administrator access privileges Supports SCEP-based enrollment with leading X.509 solutions from Baltimore, Entrust, Microsoft, and VeriSign Supports the broad range of Cisco AVVID (Architecture for Voice, Video and Integrated Data) partner solutions that provide URL filtering, content filtering, virus protection, scalable remote management, and more Earned numerous leading industry certifications and evaluations, including: Common Criteria Evaluated Assurance Level 4 (EAL4) ICSA Labs Firewall 4.0 Certification, Corporate RSSP Category ICSA Labs IPSec 1.0B Certification Provides increased flexibility when defining security policies and eases overall integration into switched network environments by supporting the creation of logical interfaces based on IEEE 802.1q VLAN tags, and the creation of security policies based on these virtual interfaces Supports multiple virtual interfaces on a single physical interface through VLAN trunking, with support for multiple VLAN trunks per Cisco PIX Security Appliance Support for up to eight total VLANs on a Cisco PIX 515E Security Appliance Provides comprehensive OSPF dynamic routing services using technology based on world-renowned Cisco IOS Software Offers improved network reliability through fast route convergence and secure, efficient route distribution Delivers a secure routing solution in environments using Network Address Translation (NAT) through tight integration with Cisco PIX Security Appliance NAT services Supports MD5-based OSPF authentication, in addition to plaintext OSPF authentication, to prevent route spoofing and various routing-based DoS attacks Provides route redistribution between OSPF processes, including OSPF, static, and connected routes 9

Virtual LAN (VLAN)-based virtual interfaces Open Shortest Path First (OSPF) dynamic routing

DHCP server

DHCP relay

NAT/PAT support Rich Management Capabilities

Supports load balancing across equal-cost multipath routes Provides DHCP Server services on one or more interfaces for devices to obtain IP addresses dynamically Includes extensions for support of Cisco IP Phones and Cisco SoftPhone IP telephony solutions Forwards DHCP requests from internal devices to an administrator-specified DHCP server, enabling centralized distribution, tracking, and maintenance of IP addresses Provides rich dynamic, static, and policy-based Network Address Translation (NAT), as well as Port Address Translation (PAT) services Comprehensive management suite for large scale Cisco security product deployments Integrates policy management, software maintenance, and security monitoring into a single management console Intuitive, Web-based GUI enables simple, secure remote management of Cisco PIX Security Appliances Provides wide range of informative, real-time, and historical reports which give critical insight into usage trends, performance baselines, and security events Provides "touchless" secure remote management of Cisco PIX Security Appliance configuration and software images via a unique push/pull management model Next-generation secure XML/HTTPS management interface can be leveraged by Cisco and third-party management applications for remote Cisco PIX Security Appliance configuration management, inventory, software image management/deployment, and monitoring Integrates seamlessly with Management Center for Firewalls and Auto Update Server for robust, scalable remote management of up to 1000 Cisco PIX Security Appliances (per management server) Allows customers to use existing Cisco IOS CLI knowledge for easy installation and management without additional training Accessible through variety of methods including console port, Telnet, and SSH Gives businesses the ability to create up to 16 customizable administrative roles/profiles for managing a Cisco PIX Security Appliance (for example, monitoring only, read-only access to configuration, VPN administrator, firewall/NAT administrator, etc.) Leverages either the internal administrator database or outside sources via TACACS+, such as Cisco Secure Access Control Server (ACS) Provide remote monitoring and logging capabilities, with integration into Cisco and third-party management applications Supports easy installation of additional network interfaces via two PCI expansion slots Supports expansion cards including single-port Fast Ethernet and four-port Fast Ethernet cards Delivers high performance VPN services via addition of either a VPN Accelerator Card (VAC) or a VPN Accelerator Card+ (VAC+) 10

CiscoWorks VPN/Security Management Solution (CiscoWorks VMS)

PIX Device Manager (PDM)

Auto Update

Cisco PIX command line interface (CLI)

Command-level authorization SNMP and syslog support Flexible Expansion Capabilities

Fast Ethernet expansion options

Hardware VPN acceleration options

Cisco PIX Firewall At-A-Glance Many people are interested to know the exact differences between the PIX hardware models. For the most part the PIX 501 should primarily be used for the SOHO (Small Office / Home Office), the PIX 506E is best for ROBO (Remote Office / Branch Office, the PIX 515E is best for the SMB (Small to Medium Sized Business) and the 525 and 535 should be considered suitable for the Enterprise. The following chart outlines the exact differences and provides a good reference when purchasing the PIX:
501 10 Users 6.3(4) SOHO 10 501 50 Users 6.3(4) SOHO 50 501 506E 515FE Unlimited R/DMZ 6.3(4) 6.3(4) 7.0(1) SOHO ROBO SMB Unlimited Unlimited Unlimited 433 64* 16 3-Feb No 2 3 10 No Yes No No Yes Yes No Yes 190 20 45 35 48,000 515FE UR/FO/FO-AA 7.0(1) SMB Unlimited 433 128* 16 2 Yes 2 6 25 A/S, A/A** Yes Yes, 2/5*** Yes *** Yes Yes No Yes 190 60/130 130 130 130,000 2,000 525 R 7.0(1) Enterprise Unlimited 600 128 16 2 No 3 6 25 No Yes No No Yes Yes No Yes 330 30 65 65 140,000 525 UR/FO/FO-AA 7.0(1) Enterprise Unlimited 600 256 16 2 Yes 3 10 100 A/S, A/A** Yes Yes, 2/50*** Yes *** Yes Yes No Yes 330 70/145 135 135 280,000 2,000 535 R 7.0(1) Enterprise Unlimited 1000 512 16 2 No 9 8 50 No Yes No No Yes Yes No Yes 1650 50 110 90 250,000 535 UR/FO/FO-AA 7.0(1) Enterprise Unlimited 1000 1024 16 2 Yes 9 14 150 A/S, A/A** Yes Yes, 2/50*** Yes *** Yes Yes No Yes 1650 100/425 495 425 500,000 2,000

Cisco PIX Firewall Model SW Version Market Licensed Users Technical Specifications Processor (MHz) Shipping RAM (MB) Flash (MB) Integrated 10/100 Ports Integrated VPN acceleration PCI Expansion Slots Max. physical interfaces Max. virtual interfaces (VLANs) Software Features High-availablity support Layer 2 transparent firewalling Security contexts (included/max.) GTP/GPRS inspection OSPF support VLAN support Cisco VPN Remote (VPN client) Cisco Easy VPN Server Performance Summary Bidirectional FW throughput (Mbps) 3DES throughput (Mbps); VAC/VAC+ AES-128 throughput (Mpbs); VAC+ AES-256 throughput (Mpbs); VAC+ Maximum Connections Maximum VPN peers

133 133 133 300 16 16 16 32 8 8 8 8 1+4port Switch 1+4port Switch 1+4port Sw 2 N/A N/A N/A N/A 1+4port Switch 1+4port Switch 1+4port Sw 2 0 0 0 2 (DMZ) No No No No No No Yes Yes 60 3 4.5 3.4 7,500 10 No No No No No No Yes Yes 60 3 4.5 3.4 7,500 10 No No No No No No Yes Yes 60 3 4.5 3.4 7,500 10 No No No No Yes Yes Yes Yes 100 15 30 25 25,000 25

* Cisco PIX 515/515E will require additional memory to run Software Version 7.0(1) ** Requires Software Version 7.0(1) or higher; A/A high availability requires one UR and one FO-AA unit (A/S = Active Standby; A/A = Active/Active *** Licensed feature, requires Software Version 7.0(1) or higher

11

Section 2 The Technical Stuff

Technical Objectives The objective of this e-book is to give you a thorough technical understanding of the following: PIX Basics PIX Security Outbound communications through the PIX o Network Address Translation (NAT) o Port Address Translation (PAT) o Global Addressing Inbound communications through the PIX o Static Command o Access-Lists o Object-Groups Virtual Private Networking (VPN) with the PIX o Client VPNs o site-to-site VPNs PIX Device Manager (PDM) Fixups/Inspect

The PIX can be intimidating to some but it really doesnt have to be. Once you get a solid grasp of the basics, you will be well on your way to configuring and deploying the PIX both for business and home based solutions.

Previous versions of this book only contained information specific to PIX IOS 6.x, however this version also contains information on PIX IOS 7.x. The truth
12

of the matter is, learning the fundamentals of the PIX is the important part, and once you understand the fundamentals you will not have a problem switching between version 6.x and 7.x. At the time of this writing only the higher end PIX models (515, 525, 535) support IOS version 7.x and the SOHO or ROBO PIX models (501 and 506) still only run version 6.x.

Im sure Cisco will start using version 7.x on all PIX models eventually but it will probably take a while. In the meantime, you will be able to see both and how they compare with each other. Be sure you know what version your PIX is running (you can always check this with a show run). Or again, if you have a PIX 501 or 506 you know that it will be 6.x and if you have a PIX 515, 525 and 535, it may be 7.x.

I will be covering each of the above topics in detail. We will look first at the information on the above topics relating to version 6.x then at the bottom well look at differences relating to 7.x (if any). (Details on 7.x will be indicated by blue font and the words ***7.x info whenever you see that, what follows will be specific to only PIX version 7.x). If you are only interested in learning version 6.x at this time, simply ignore the blue writing! I will attempt to stay on each topic until it has been completely discussed. I will also provide examples, where appropriate, to give real world scenarios to help teach on the topic being covered.

13

PIX Basics It is worthwhile to cover the absolute basics on the PIX. The following table lists some basic PIX Firewall commands:

Task Saving my configuration Viewing my configuration Accumulating system log (syslog) messages Viewing system log (syslog) messages Clearing the message buffer

Related Command write memory write terminal logging buffered debugging show logging clear logging

To gain access to the PIX Firewall you must connect to the device, either over a direct cable connection, or over a network based connection. For this discussion, we will be looking at connecting to the PIX Firewall through the Console.

Accessing the PIX Firewall via the Console:

This is the most basic way of connecting to your PIX and works by making a direct connection from your computer to the PIX over what is known as the "console" port. You will not be using the network at all to connect via a console connection.

The console port will be found on the PIX and should be labeled and will generally be a Female RJ-45 connection. (In some cases it will be a DB-9 connection on the PIX and will require an adapter that plugs into the PIX DB-9 and has a RJ-45 connection on the other side).

14

You will need a RJ-45 to DB-9 cable that ships with the PIX. If you have lost your console cable you can purchase another one from Cisco, a Cisco reseller, or even from Ebay.

Step 1) Connect the DB-9 connector to the serial port on your desktop or laptop computer and plug the RJ-45 end into the console port on the PIX.

Step 2) Next, open up Hyperterminal (comes with Windows) or any other ANSI terminal emulation program.

You will be asked to name the connection, just call it Cisco Connection, or whatever name you like.

Find the box that says "Connect using:" and hit the drop down arrow. You will want to indicate whichever COM port the serial connection on your computer configured for, such as COM1, COM2, etc.

At the COM Properties dialog box, set the following fields:

Bits per second to 9600

Data bits to 8

Parity to None

Stop bits to 1

15

Flow control to Hardware

Click OK to continue

Step 3) Make sure the PIX Firewall is turned on and you should now be able to see the console display and eventually the PIX Firewall prompt.

4) Now you are ready to configure your PIX using the command-line interface.

When using the PIX Firewall command-line interface (CLI), you can do the following: Check the syntax before entering a command. Enter a command and

press the Enter key to view a quick summary, or precede a command with help, as in, help aaa. Abbreviate commands. For example, you can use the config t command

to start configuration mode, the write t command statement to list the configuration, and the write m command to write to Flash memory. Also, in most commands, show can be abbreviated as sh. This feature is called command completion. After changing or removing the alias, access-list, conduit, global, nat,

outbound, and static commands, use the clear xlate command to make the IP addresses available for access. Review possible port and protocol numbers at the following IANA

websites: http://www.iana.org/assignments/port-numbers http://www.iana.org/assignments/protocol-numbers

16

Create your configuration in a text editor and then cut and paste it into the

configuration. PIX Firewall lets you paste in a line at a time or the whole configuration. Always check your configuration after pasting large blocks of text to be sure everything copied.

I personally have made it a habit to script my changes using a text editor as mentioned above. I usually write my script, print it out and analyze it thoroughly before making any changes on the actual device. This helps to ensure the command syntax is correct and everything that needs to be included in the script is in place. I have caught many errors and typos doing it this way which is exactly the reason to do it. Finding typos in your script is much better than finding them as you are doing your implementation!

The PIX Firewall contains a command set based on Cisco IOS technologies and provides configurable command privilege modes based on the following command modes:

Unprivileged mode. When you first access the firewall, it displays the ">"

prompt. This is unprivileged mode, and it lets you view firewall settings. The unprivileged mode prompt appears as follows: pixfirewall>

Privileged mode, which displays the "#" prompt and lets you change

current settings. Any unprivileged mode command also works in privileged mode. Use the enable command to start privileged mode from unprivileged mode as follows:

17

pixfirewall> enable Password:******* pixfirewall#

Use the exit or quit commands to exit privileged mode and return to unprivileged mode as follows: pixfirewall# exit

Logoff

Type help or '?' for a list of available commands. pixfirewall>

Use the disable command to exit privileged mode and return to unprivileged mode as follows:

pixfirewall# disable pixfirewall>

Configuration mode, which displays the "(config)#" prompt and lets you

change the firewall configuration. All privileged, unprivileged, and configuration mode commands are available in this mode. Use the configure terminal command to start configuration mode as follows:

pixfirewall# configure terminal pixfirewall(config)#

18

Use the exit or quit commands to exit configuration mode and return to privileged mode as follows:

pixfirewall(config)# quit pixfirewall#

Use the disable command to exit configuration mode and return to unprivileged mode as follows:

pixfirewall(config)# disable pixfirewall>

When in configuration mode the clear command can be used to clear specific commands. The syntax for the clear command is as follows:

clear configurationcommand [subconfigurationcommand]

This command will clear the entire configuration for the configuration command that was specified. To clear only the configuration for a specific subcommand, a value can be entered for the subconfigurationcommand.

To disable the specific parameters or options of a command or subcommand, enter the no form of the command, as follows: no configurationcommand [subconfigurationcommand] qualifier [...] In this case use the no command to remove the specific configuration identified by the qualifier.

19

Ports and Protocols

A nice feature with the PIX is the fact that you can use names instead of numbers when it comes to commonly used TCP or UDP ports. The same is true for commonly used protocols. These literal names can be used in your access-lists rather than specifying the actual port or protocol numbers.

The chart below lists the literal names that can be used for ports on the PIX:

Literal aol bgp biff bootpc bootps chargen citrix-ica cmd ctiqbe daytime discard domain dnsix echo exec finger ftp ftp-data gopher https h323 hostname ident imap4 irc isakmp kerberos klogin kshell ldap ldaps lpd

TCP or UDP? TCP TCP UDP UDP UDP TCP TCP TCP TCP TCP TCP, UDP TCP, UDP UDP TCP, UDP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP UDP TCP, UDP TCP TCP TCP TCP TCP

Value 5190 179 512 68 67 19 1494 514 2748 13 9 53 195 7 512 79 21 20 70 443 1720 101 113 143 194 500 750 543 544 389 636 515

Description America On-line Border Gateway Protocol, RFC 1163 Used by mail system to notify users that new mail is received Bootstrap Protocol Client Bootstrap Protocol Server Character Generator Citrix Independent Computing Architecture (ICA) protocol Similar to exec except that cmd has automatic authentication Computer Telephony Interface Quick Buffer Encoding Day time, RFC 867 Discard DNS (Domain Name System) DNSIX Session Management Module Audit Redirector Echo Remote process execution Finger File Transfer Protocol (control port) File Transfer Protocol (data port) Gopher Hyper Text Transfer Protocol (SSL) H.323 call signalling NIC Host Name Server Ident authentication service Internet Message Access Protocol, version 4 Internet Relay Chat protocol Internet Security Association and Key Management Protocol Kerberos KLOGIN Korn Shell Lightweight Directory Access Protocol Lightweight Directory Access Protocol (SSL) Line Printer Daemon - printer spooler

20

login lotusnotes mobile-ip nameserver netbios-ns netbios-dgm netbios-ssn nntp ntp pcanywhere-status pcanywhere-data pim-auto-rp pop2 pop3 pptp radius radius-acct rip secureid-udp smtp snmp snmptrap sqlnet ssh sunrpc (rpc) syslog tacacs talk telnet tftp time uucp who whois www xdmcp

TCP TCP UDP UDP UDP UDP TCP TCP UDP UDP TCP TCP, UDP TCP TCP TCP UDP UDP UDP UDP TCP UDP UDP TCP TCP TCP, UDP UDP TCP, UDP TCP, UDP TCP UDP UDP TCP UDP TCP TCP UDP

513 1352 434 42 137 138 139 119 123 5632 5631 496 109 110 1723 1645 1646 520 5510 25 161 162 1521 22 111 514 49 517 23 69 37 540 513 43 80 177

Remote login IBM Lotus Notes MobileIP-Agent Host Name Server NetBIOS Name Service NetBIOS Datagram Service NetBIOS Session Service Network News Transfer Protocol Network Time Protocol pcAnywhere status pcAnywhere data Protocol Independent Multicast, reverse path flooding, dense mode Post Office Protocol - Version 2 Post Office Protocol - Version 3 Point-to-Point Tunneling Protocol Remote Authentication Dial-In User Service Remote Authentication Dial-In User Service (accounting) Routing Information Protocol SecureID over UDP Simple Mail Transport Protocol Simple Network Management Protocol Simple Network Management Protocol - Trap Structured Query Language Network Secure Shell Sun Remote Procedure Call System Log Terminal Access Controller Access Control System Plus Talk RFC 854 Telnet Trivial File Transfer Protocol Time UNIX-to-UNIX Copy Program Who Who Is World Wide Web X Display Manager Control Protocol

Port numbers can be viewed online at the IANA website:

http://www.iana.org/assignments/port-numbers

21

The chart below lists the literal names that can be used for protocols on the PIX:

Literal ah eigrp esp gre icmp igmp igrp ipinip nos ospf pcp snp tcp udp

Value 51 88 50 47 1 2 9 4 94 89 108 109 6 17

Description Authentication Header for IPv6, RFC 1826 Enhanced Interior Gateway Routing Protocol Encapsulating Security Payload (ESP) for IPv6, RFC 1827 General routing encapsulation Internet Control Message Protocol, RFC 792 Internet Group Management Protocol, RFC 1112 Interior Gateway Routing Protocol IP-in-IP encapsulation Network Operating System (Novell NetWare) Open Shortest Path First routing protocol, RFC 1247 Payload Compression Protocol Sitara Networks Protocol Transmission Control Protocol, RFC 793 User Datagram Protocol, RFC 768

Protocol numbers can be viewed online at the IANA website: http://www.iana.org/assignments/port-numbers

Performing the initial configurations:

One of the first things you should do on the PIX is set the passwords and assign the name. This can be accomplished, as follows:

pixfirewall(config)# enable password MyEnable

The above sets the enable password which will be displayed in the configuration as encrypted characters and will have the word encrypted at the end. The enable password allows the administrator to gain access to enable mode on the PIX.

22

The user mode password should also be set. This can be accomplished, as follows:

pixfirewall(config)# passwd MyPassword

The user mode password will be requested upon login and will also be the first password challenge when using Telnet. Again, the password will be displayed in the configuration as encrypted characters and will have the word encrypted at the end.

***PIX 7.x Info No changes were made to setting passwords in version 7.x.

Next, lets assign a hostname to our PIX. The name should generally be innocuous so that the device type isnt given away by the name. Even though a hacker will not be able to break through the PIX if he found it, lets not let them know that it is a firewall!

The hostname can be set as follows:

pixfirewall(config)# hostname device1

***PIX 7.x Info No changes were made to assigning the hostname in version 7.x.

Out of the box, the interfaces on a PIX Firewall are shutdown. Please note that the way to configure interfaces is different between version 6.x and 7.x.

23

Well look first at the way to configure interfaces in 6.x and after that look at the way to configure interfaces in 7.x

Configuring interfaces with 6.x:

To bring up Ethernet0, for example, you would issue the following command from configuration mode:

device1(config)# interface ethernet0 auto

Of course the above assumes that you wish the port speed to auto-negotiate. If you wanted to hard-code the speed and duplex setting, there are many command options. The following command hard-codes the port to a speed of 100, full duplex:

device1(config)# interface ethernet0 100full

Then you would configure the IP address on the interface, as follows:

device1(config)# ip address outside 199.199.199.1 255.255.255.0

You will need to do the same for the inside interface:

device1(config)# interface ethernet1 100full

device1(config)# ip address inside 192.168.1.1 255.255.255.0

24

If you are using a PIX 501 you will only have two interfaces. In other words, you will have one interface for your inside network and one for your outside network. If you are using a PIX 506 you will have two interfaces, with the option of adding more logical interfaces (more on that soon).

If you are using a PIX 515E, PIX 525 or PIX 535, you will have the option of adding interfaces into expansion slots and logical interfaces for DMZ, management or other networks.

Next, the interfaces can be named and given security levels (well talk more about security levels later). To name the interfaces and set the security use the nameif command, as follows:

device1(config)# nameif ethernet0 outside security0 device1(config)# nameif ethernet1 inside security100

Default interface names appear in the configuration of the PIX. By default, the Ethernet0 interface is named the outside interface and is considered the least secure interface. The Ethernet1 interface is named inside, by default, and is considered the most secure. Generally, your inside interface corresponds to your inside network. The inside network is where your secure data and systems reside. The outside interface is generally connected to an Internet facing router or other external network. Because this interface is essentially sitting on the Internet or other external network, it is the least secure interface.

***PIX 7.x Info With PIX 7.x the interface configuration has changed to be more hierarchical. The same concepts that we learned above still apply, we
25

just configure the interfaces a bit differently. So to configure Ethernet 0 as the outside interface with a security level of 0 and an IP address at a speed of 100 with full duplex, we would do the following:

device1(config)# interface Ethernet0

mode will then change to config-if, as follows:

device1(config-if)# nameif outside device1(config-if)# security-level 0 device1(config-if)# ip address 199.199.199.1 255.255.255.0 device1(config-if)# speed 100 device1(config-if)# duplex full

*Note the speed auto and duplex auto is the default interface configuration with PIX 7.x and is not displayed in the configuration if set. This new way to configure the interfaces is more similar to a Cisco router. I personally like it in the fact that it helps when reading the configuration file since it is not quite as flat.

Figure 1 below shows an illustration of a basic PIX Firewall design:

Figure 1 Basic PIX Firewall design

26

As noted previously the PIX 501 and 506e only have two physical interfaces, an inside and an outside, as depicted in the drawing above. When talking about physical interfaces I mean hardware interfaces. There is also the concept of logical interfaces with the PIX. Let me take a moment to explain some options you have with the PIX when it comes to interfaces.

With the PIX 501 you have two physical interfaces and that is all you can ever have. Two hardware interfaces, an inside and an outside with no opportunity for a DMZ which in the case of a small network is generally fine.

With the PIX 506E running version 6.3 you have the two physical interfaces, but you can also add two more logical interfaces. Logical interfaces, also called virtual interfaces allow you to create additional interfaces on the PIX using VLANs. Well look at how to do that in a minute.

The following chart shows the different interface options you have on the various PIX models running version 6.3 and above with Restricted and Unrestricted Licenses.

Model

Restricted License
Total Interfaces NA Physical Interfaces NA NA 3 NA 6 8 Logical Interfaces NA NA 3 NA 6 8

Unrestricted License Total Interfaces 2 4 10 12 12 24 Physical Interfaces 2 2 6 6 8 10 Logical Interfaces Not supported 2 8 10 10 22

PIX 501 PIX 506/506E PIX 515/515E PIX 520 PIX 525 PIX 535

NA 5 NA 8 10

27

Lets say, for example, you wanted a specific Demilitarized Zone (DMZ) for all corporate web servers. You have a PIX 515 running version 6.2 with three physical interfaces. We talked previously about assigning names and security using the nameif command. Adding on to the above example that was used when talking about PIX 6.x, see below for naming and setting security on the DMZ interface:

device1(config)# nameif dmz1 inside security10

Notice we made the security of the dmz1 interface a level 10. This essentially means that the DMZ interface is not as secure as the inside interface and more secure than the outside interface. We will discuss the topic of security on the PIX in greater detail in the next chapter, but it is necessary to make the new DMZ interface at a level somewhere between 1 and 99.

Now, lets say we have a PIX 506E running version 6.3 and we still need a DMZ. In this case we would need to use logical interfaces. *To do this configuration would also require the potential for router configurations to allow connectivity between VLANs and switch trunking which is outside the scope of this book, however the necessary steps for configuration of the PIX are below. Remember, you would only need to do this if you needed additional interfaces on your PIX. Most people who have the PIX 506 are fine with just 2 interfaces.

28

The following steps would need to be taken to configure our PIX 506E with logical interfaces:

First, bring up the physical interface, as we did above:

device1(config)# interface ethernet0 100full

Next, assign a VLAN to the physical interface of the PIX 506E.

device1(config)# interface ethernet0 vlan50 physical

What you are doing here is assigning a specific VLAN to the physical interface of the PIX which is the most secure method of utilizing VLANs on the PIX Firewall.

Now you can create the new logical interface to be used for the DMZ:

device1(config)# interface ethernet0 vlan100 logical

This allows the PIX to send and receive VLAN-tagged packets with VLAN number 100 on the physical interface of the PIX.

Now you can finalize the configuration by setting the IP addresses and names:

device1(config)# nameif ethernet0 security 0 device1(config)# nameif vlan100 dmz security 10 device1(config)# ip address outside 199.199.199.1 255.255.255.0
29

device1(config)# ip address dmz 200.200.200.1 255.255.255.0

After this configuration, both outside and dmz traffic will flow from the same physical interface (ethernet0), but they are logically separated.

***PIX 7.x Info Lets see what it takes to do configure logical interfaces with PIX 7.x. Remember, this will only apply to PIX 515 and above since version 7.x is not yet available on PIX 501 or 506.

The new method of configuring interfaces introduced with 7.x makes logical interfaces much cleaner. With 7.x you create the main interface, then add a sub-interface identifying the VLAN as a new interface, as follows:

First configure the generic main interface:

device1(config)# interface Ethernet1 device1(config-if)# no nameif device1(config-if)# no security-level device1(config-if)# no ip address

Then proceed to create the dmz VLAN interface:

device1(config)# interface Ethernet1.100 device1(config-if)# vlan 100 device1(config-if)# nameif dmz device1(config-if)# security-level 10 device1(config-if)# 200.200.200.1

30

Then, the physical interface:

device1(config)# interface Ethernet1.50 device1(config-if)# vlan 50 device1(config-if)# nameif inside device1(config-if)# security-level 100 device1(config-if)# 199.199.199.1

Whether you use the logical interface functionality of the PIX or not will be determined by your specific situation. In many cases, using a PIX with a DMZ is the right solution but every configuration and design is different.

Figure 2 below shows an illustration of a PIX Firewall design with a DMZ interface:

Figure 2 PIX Firewall design with DMZ

31

DM Z1

Routing on the PIX

Another important configuration task we need to outline is routing on the PIX. The PIX performs routing on its directly connected interfaces and knows how to route to connected subnets, but any routes it does not know about will need to be configured. The PIX does support RIP (Routing Information Protocol) and software version 6.3 supports OSPF (Open Shortest Path First) but Cisco does not recommend using dynamic routing to or through the PIX unless absolutely necessary. Static routes are generally more secure and cannot be fooled as easily as something like RIP.

Generally speaking the PIX will require a default route to be added out the outside interface pointing to the next hop Internet connected router. This will send all traffic that the PIX does not know what to do with to this router. Assuming our Internet connected router had an IP address of 199.199.199.2 we would add the following default route configuration to the PIX:

device1(config)# route outside 0.0.0.0 0.0.0.0 199.199.199.2

***PIX 7.x Info No changes were made in regards to how routes are configured in version 7.x.

32

PIX Security The PIX Firewall security architecture is built around the Adaptive Security Algorithm (ASA). One main feature of the ASA is that it uses stateful information to ensure a high level of security. For example, lets say a user on the inside protected LAN goes to a web site on the internet. This traffic would create a new TCP connection that immediately gets logged in a stateful session flow table in the PIX ASA Engine. The session flow table logs the following: Source and Destination Addresses Port Numbers TCP Sequencing Information Any additional flags for each new TCP connection associated with that host This information will remain in the table and accurate as long as the session remains active. All of the above information creates a virtual finger print in the PIX Firewall. As new inbound packets come into the PIX they are then compared to the existing session flow table to determine if they meet the adequate criteria to be permitted through the PIX. By uniquely identifying the particular client who transmitted packets to the Internet (by making an external connection to a web site as in our example), and by maintaining the ports, TCP sequence numbers and additional TCP flags, the PIX makes it nearly impossible for a hacker to penetrate the firewall to the protected LAN client.

Another security benefit with the PIX is the fact that TCP sequence numbers are randomized. This security benefit combats the ability for hackers to participate in IP address spoofing attacks or other protected client attacks. If
33

a hacker wished to perform an IP spoofing attack they would need to know the IP address and the sequence numbers of TCP packets. Many TCP/IP implementations have tried to deter hackers from IP spoofing by using an algorithm that simply adds to the incrementing TCP sequence numbers. Many hackers find it easy to simply guess the next number in the sequence until they find the pattern which allows them then to successfully hijack the system. However, with the randomizing algorithm used by the PIX the process of guessing the next TCP sequence numbers becomes nearly impossible.

As noted previously each of the PIX interfaces have a specific security level associated with them. The outside interface (Ethernet0) is always 0, or least secure, and the inside interface (Ethernet1) is always 100, or most secure. The DMZ or any other perimeter interface can be anything between 1 and 99.

The PIX permits by default any connections or traffic passing from a higher security interface (for example, inside) to a lower security interface (for example, outside). In some cases even this default behavior should be changed to not specifically permit traffic from high to low security. This can be done by using access lists.

The PIX denies by default any connections or traffic passing from a lower security interface (for example, outside) to a higher security interface (for example, inside).

34

Figure 3 below shows an illustration of the basic PIX Security flows:

Figure 3 PIX Firewall basic security flows

In addition, Cisco has outlined the following rules that ASA follows. I will list each rule and add my comments below: No packets can traverse the PIX without a connection and a state.

Looking at our previous example, the user on the protected LAN attempting to visit a web site on the Internet was allowed to receive a data response from that web site based on his stateful information stored in the flow table. The established connection and state information allowed the packets to traverse the PIX.

Traffic may not exit the PIX on the same network interface it entered.

The PIX is concerned with passing traffic from one interface to the next. There should never be a reason for traffic coming in from the Internet, for example, to enter the outside interface of the PIX and then turn back around and exit that same interface without being forwarded onto an inside, DMZ or
35

other perimeter interface. If there ever was a situation where there was an attempt of traffic to exit on the same network interface that it entered, the following message gets logged in the system log:
%PIX-7-106011: Deny inbound (No xlate) chars

Explanation This is a connection-related message. This message occurs when a packet is sent to the same interface that it arrived on. This usually indicates that a security breach is occurring. When the PIX Firewall receives a packet, it tries to establish a translation slot based on the security policy you set with the global and conduit commands, and your routing policy set with the route command.

Outbound connections or states are allowed, except those specifically denied by access control lists. An outbound connection is one where the originator or client is on a higher security interface than the receiver or server. The highest security interface is always the inside interface and the lowest is the outside interface. Any perimeter interfaces can have security levels between the inside and outside values.

This has been covered in detail above. It is worth repeating however because it is a very important concept with the PIX. This is what is known as a blacklist policy model, which means to allow everything except that which has been explicitly denied. Again, this only applies where the originator was attached to an interface of a higher security going out to a lower security interface. Inbound connections or states are denied, except those specifically allowed. An inbound connection or state is one where the originator or client is on a lower security interface/network than the receiver or
36

server. You can apply multiple exceptions to a single xlate (translation). This lets you permit access from an arbitrary machine, network, or any host on the Internet to the host defined by the xlate.

As mentioned previously, when going inbound, or from the outside interface to the inside interface, all connections are explicitly denied by default. This is what is known as a whitelist policy model, which means to deny everything except that which has been explicitly allowed. All ICMP packets are denied unless specifically permitted.

Actually, let me clarify the above statement. Inbound ICMP through the PIX is denied by default; outbound ICMP is permitted, but the incoming reply is denied by default. Many people run into problems with ICMP packets being denied. They configure their Firewall and begin testing and troubleshooting. The first thing many people do when troubleshooting is see if they can ping an interface or device. With the PIX, all ICMP packets (ping) are denied! So if you try to ping while testing and dont get a response, verify that you have the necessary access lists to allow ping. Also, it is good practice to turn off ping functionality when you are done testing.

Outbound communications through the PIX First, let me define the term outbound communications. Outbound communications would include any connections from a higher security interface to a lower security interface. This would include traffic going from inside to outside, inside to DMZ, DMZ to outside, or even DMZ to another
37

DMZ assuming one had a higher level of security than the other. To recap, the nameif command allows you to specify security levels on interfaces and it also can be used to indicate all current security levels on attached interfaces on the PIX. If you are ever unsure of the particular security level associated with an interface, issue the show nameif command.

As previously discussed, the PIX permits by default any connections or traffic passing from a higher security interface to a lower security interface. However, there are some basic configuration steps that are needed. Specifically, outbound connections require a translation method. All traffic leaving a higher security interface to a lower security interface must be translated. There are two ways to perform this translation on the PIX. The first is by using the static command, which as the name implies, performs a static translation. The other option, and generally more common, is by using a nat/global rule, which is a dynamic translation method. We will be discussing the nat/global translation method in detail. When we look at inbound connections through the PIX in another chapter we will discuss the static command.

Something important to keep in mind when it comes to outbound communications through the PIX is that if there is an access list (ACL) defined on the source interface, it will need to specifically allow the source host to access the destination hosts (including port and protocol). By default, there are no restrictions on outbound communications through the PIX, so as long as the translation method has been defined, and there are no previously configured ACLs, the outbound traffic will be allowed.

38

NAT and Global

As I mentioned above, a translation method must exist to allow for outbound connections through the PIX. Essentially, the NAT and Global commands perform the translation functionality that allows addressing on the inside to be translated to addresses on the outside. In a common secure network scenario, all of the inside hosts reside on a non-routable, internal network segment. IANA has set up a range of unregistered, non-routable addresses, which are to be used primarily in internal networks. Routers are designed to discard these unregistered addresses.

There is a specific range for each of the three classes of IP addresses used for networking: Range 1: Class A 10.0.0.0 through 10.255.255.255 Range 2: Class B 172.16.0.0 through 172.31.255.255 Range 3: Class C 192.168.0.0 through 192.168.255.255 For more information on unregistered addresses see RFC 1918: Address Allocation for Private Internets.

So in a typical inside network using non-routable, unregistered addressing, all traffic leaving the inside network to go out to the internet will get dropped by the first router it hits. There needs to be a way to translate these private, nonroutable addresses to something functional on the Internet. This is where Network Address Translation or NAT comes in. The PIX performs Network Address Translation by using the NAT command in conjunction with the Global command.

39

Lets add some addressing to our previous diagram and work with an example. Figure 4 below shows an example of PIX with inside and outside addressing:
Figure 4 PIX Firewall with inside and outside addressing

In this example, our inside network has been addressed with an internal, nonroutable network of 192.168.1.0/24. Our LAN clients are using addresses 192.168.1.20~192.168.1.255. We have two protected LAN servers on the inside network which are addressed as .10 and .11.

Our Internet Service Provider has given us an external address block of 199.199.199.0/27. These are addresses that are publicly routable on the Internet. For sake of definition we will refer to these ISP assigned publicly routable addresses as registered addresses. This gives us 30 addresses to allocate as we wish (.1~.30). The first address (.1) we assign to the outside interface of the PIX. The second (.2) we assign to the Internet connected router which gives us connectivity to the outside world.

Protected LAN Servers

40

Next we want to be sure that all inside protected LAN client traffic can get out to the Internet. For this to happen, we will need to configure the PIX with NAT and Global commands.

There are a few ways of doing this. In this example, we only have one inside network so we could simply open up everything to be NATed with the following command:

device1(config)# nat (inside) 1 0.0.0.0 0.0.0.0

If there are multiple inside networks or you simply want to be more specific about what you allow to be NATed, you can also configure NAT to the network level, as follows:

device1(config)# nat (inside) 1 192.168.1.0 255.255.255.0

In this example both of these commands are essentially doing the same thing. They are telling the PIX to allow the inside network hosts to be NATed. But what address are they being translated to? We havent gotten there yet!

You might be wondering what the purpose of the 1 in the above command is. The 1 is the NAT ID and as we will see shortly, the NAT ID must match in both the NAT and Global commands. It should also be noted that if you want to disable NAT for any particular network or hosts, the NAT ID 0 must be used. We will look at utilizing NAT 0 in a later chapter when we discuss VPN connectivity through the PIX.

41

When configuring NAT/ Global there are three main configuration options: One option is to configure Inside Dynamic NAT; another option is to configure Inside Dynamic Port Address Translation (PAT); and a final option is to configure Inside Static NAT. Lets take a moment to look at each of these.

Inside Dynamic NAT Translates between host addresses on more secure interfaces and a range or pool of IP addresses on a less secure interface. This provides a one-to-one mapping between internal and external addresses that allows internal users to share registered IP addresses and hides internal addresses from view on the public Internet.

Inside Dynamic PAT Translates between host addresses on more secure interfaces and a single address on a less secure interface. This provides a many-to-one mapping between internal and external addresses. This allows internal users to share a single registered IP address and hides internal addresses from view on the public Internet.

Inside Static NAT Provides a permanent, one-to-one mapping between an IP address on a more secure interface and an IP address on a less secure interface. This allows hosts to access the inside host from the public Internet without exposing the actual IP address.

42

To refer back to our example diagram above, if we wanted to perform Inside Dynamic NAT where all hosts on our internal network get translated to the range or pool of registered addresses that has been allocated to us by our ISP we would issue the following commands on the PIX:

device1(config)# global (outside) 1 199.199.199.3-199.199.199.30 netmask 255.255.255.224 device1(config)# nat (inside) 1 192.168.1.0 255.255.255.0

*Please note Due to space limitations, commands are shown on two lines. All commands shown should be configured on the PIX as one line commands.

These commands tell the PIX to translate source addresses on the 192.168.1.0 inside network to a registered address from the NAT pool which includes 28 public addresses (199.199.199.3-199.199.199.30). Notice the NAT ID of 1 in both the nat and global statements. The NAT ID needs to be the same on both as it essentially maps the two commands together and tells the PIX which inside networks to translate to which global.

These addresses will be translated on a first come, first served basis and when the NAT pool is depleted no new outbound connections will be permitted. In our example, as users on the inside LAN decide to initiate outbound connections to access external resources, such as Internet web sites, FTP sites, etc., they get translated one by one. The first user will get translated to the 199.199.199.3 address, the next user will get translated to the 199.199.199.4 address, and so on. This translation process will continue all the way up until the 28th user with address 199.199.199.30. If a 29th user
43

attempted to access external resources he or she would not be able to because the NAT pool will have been depleted.

Inside Dynamic NAT will require an equal number of registered IP addresses to those which will need to be translated. In our example above this might be a limitation due to the fact that our inside network has over 200 hosts (192.168.1.20~192.168.1.255). In this case Inside Dynamic PAT may be a better choice.

As mentioned previously, Inside Dynamic PAT Translates between host addresses on more secure interfaces and a single address on a less secure interface. This means that all of our hosts on the 192.168.1.0/24 network could be translated to one registered IP address. The commands needed to accomplish this configuration using Inside Dynamic PAT are as follows:

device1(config)# global (outside) 1 199.199.199.3 netmask 255.255.255.224 device1(config)# nat (inside) 1 192.168.1.0 255.255.255.0

This will allow every inside host on the inside network to be translated to the single registered address of 199.199.199.3.

PAT can also be used with the PIX outside interface IP address. Using the outside interface IP allows you to save on the amount of registered IP addresses needed. To use the outside IP address for PAT, issue the following global command: device1(config)# global (outside) 1 interface

44

How does Port Address Translation (PAT) work? As the name implies, PAT is more concerned with translating the port than it is the address. PAT ensures that a unique TCP source port is used for each unregistered IP. So even though multiple unregistered IP addresses get translated to the same registered IP, each one has a unique port assigned.

PAT uses a range of TCP ports between 1025 and 65535 which allows for over 60000 translations over just one registered IP. The PIX keeps a record of which inside host was assigned which unique TCP port and directs traffic back to that host.

Figure 5 shows an example of Port Address Translation (PAT):

Figure 5 Port Address Translation (PAT)

4
.22

Incoming Packets Are Routed Back to Proper Host based on TCP Port Number: 192.168.1.20:1024 192.168.1.21:1025 192.168.1.22:1026

Response From Internet Comes Back 3

.21

PIX Configured with PAT Global - 199.199.199.3

Network 192.168.1.0/24 Inside .1
PIX FIREWALL

.20

Network 199.199.199.0/27 .1 Outside

.2

Internet Connected Router

Internet

1 Inside Protected LAN Clients 192.168.1.20,.21,.22 Initiating OutboundTraffic to Internet

PAT Changes the Source Address of Each Packet to a Registered IP with Different Source Ports: 199.199.199.3:1024 199.199.199.3:1025 199.199.199.3:1026

PAT does have some restrictions such as the fact that it cannot support any application that has an inbound data stream which is different from the outgoing control path. These applications are few and far between and many
45

companies run Inside Dynamic PAT as their primary translation method without any problems. However, there is an option to run both NAT and PAT on the PIX.

The following commands achieve a best of both worlds solution:

device1(config)# global (outside) 1 199.199.199.3-199.199.199.29 netmask 255.255.255.224 device1(config)# global (outside) 1 199.199.199.30 netmask 255.255.255.224 device1(config)# nat (inside) 1 192.168.1.0 255.255.255.0

Using this configuration allows the use of Inside Dynamic NAT for the first 27 inside users. After this address pool has been depleted, the PIX then uses Inside Dynamic PAT to translate all subsequent source addresses to 199.199.199.30 until any new addresses in the NAT pool become free.

Figure 6 shows an example of our current configuration:

Figure 6 PIX Outbound Communications with NAT and PAT
Protected LAN Servers

46

***PIX 7.x Info No changes were made to the above NAT/Global commands with 7.x and all of the above commands and functionality will still work the same.

The one feature that was introduced with 7.x in regards to NAT is the natcontrol command. The nat-control command acts like a switch for NAT on outbound connectivity through the PIX. What this does is it enables you to be able to switch on and off whether you have to NAT on outbound connections.

With nat-control enabled, which is the default, you must have specific NAT rules to allow outbound connectivity. This is exactly like we looked at above when we talked about the need for NAT and Global statements on the PIX to allow outbound connectivity.

With nat-control disabled (no nat-control command) inside hosts can communicate with outside networks without the configuration of a NAT rule. However, for most cases this command is not needed simply because of the fact that the inside hosts are on unregistered RFC 1918 address space and outside addressing is on registered public addressing. If you need to NAT private RFC 1918 addressing to public registered addressing this command will not do you any good.

The no nat-control command can come in handy in a situation where all inside hosts are on registered public IP address space, or in secure network environments where the addressing is on unregistered private space 1918 address space but you need to maintain security within the environment. However, if you need to NAT private RFC 1918 addressing to public
47

registered addressing, which is one of the things the PIX is generally used to do, the no nat-control feature would probably not do you much good.

Inbound communications through the PIX First, let me define the term inbound communications. Inbound communications would include any connections from a lower security interface to a higher security interface. This would include traffic going from outside to inside, outside to DMZ, DMZ to inside, or even DMZ to another DMZ assuming one had a lower level of security than the other.

The best way to allow inbound communications through the PIX to a specific host on the inside network is to use Inside Static NAT. As mentioned previously Inside Static NAT Provides a permanent, one-to-one mapping between an IP address on a more secure interface and an IP address on a less secure interface. This allows hosts to access the inside host from the public Internet without exposing the actual IP address. Inside Static NAT differs from NAT or PAT in that it requires a specific dedicated address on the outside network for each host that will need to be accessed, so it does not help to save registered IP addresses.

Why would you want to use Inside Static NAT? Suppose you have a web server and a media server on the inside protected LAN that serves your company web site and provides media streaming. Both of these servers would need to be accessible from the Internet for the web and media services that your company provides. The servers themselves can remain on your inside protected LAN and still be protected from hackers and crackers. This is a very common scenario deployed by many companies today. The other
48

option is to put the servers on a dedicated DMZ network. The logic remains the same, outside traffic needs to access this internal resource.

To achieve this Inside Static NAT functionality, the static command must be used on the PIX. The static command creates a one-to-one address translation rule (called an xlate slot). All xlate slots are maintained in a translation table on the PIX. A simplistic look at an xlate slot on the PIX would include information on the following four items:

(high security interface, low security interface) low security IP, high security IP

Individual static commands create the necessary xlate slots on the PIX. These xlate slots are required for each pair of interfaces in order to allow access to the inside (translated) IP. In other words, if you have two separate inside servers which need to be accessible from a lower security interface such as the outside, you will need two separate static commands. All inbound communications are allowed only if there is a valid xlate slot in the PIX. The static command creates the necessary xlate slot which essentially publishes the inside host and makes it accessible through the lower security interface.

I like to think of the static as a publishing or pass-through command. If you have an inside host that needs to be accessed from the outside, there will need to be a way for traffic to pass from the registered IP address to the unregistered local IP address. The static command is the key. It basically punches a hole in the firewall to allow connectivity to the inside host using its registered IP address. It publishes this inside host as being available

49

because the static exists. This sets up the connection or the mapping between the two registered and unregistered IP addresses.

So looking at our previous example, Figure 7 shows that we have two servers sitting on our inside protected LAN. One of these servers is a web server, and the other is a media server:
Figure 7 PIX Inbound Communications - Web and Media Servers

As noted above, we will need two individual static commands to publish these inside hosts as available to the outside world. These static commands will require registered IP addresses to match the one-to-one mapping for these internal servers. This means that if we need two inside servers to be accessible from the Internet, since we are using Inside Static NAT, we will need two registered IP addresses to allocate to these servers.

There is actually another option here to achieve the same goal of allowing connectivity from the outside to two servers on the inside with each server providing different services (i.e. one server providing www access and the
50

Protected LAN Servers

other providing media access) while only using one registered IP address. This method is called Port Redirection, or inbound PAT. I mention it last because using Inside Static NAT is the preferred method. Overall, Inside Static NAT is far more scalable and provides a clear mapping of host and IP address per service. I would only use Port Redirection in the event where there is no possible way I could obtain more than one registered IP address from the ISP, and even in this case there are definite limitations to using Port Redirection. For example, Port Redirection will not work if there are two inside servers that both run the same service and need to be accessed from users on the Internet. However, for those of you needing to utilize Port Redirection for inbound connectivity through the PIX, an example will be provided in the PIX Quick Configuration Guide found later in the book.

But for now, lets stick to what it would take to set this up utilizing Inside Static NAT. In our previous example discussing the NAT and Global configuration options we decided to have an Inside Dynamic NAT pool to be use for primary outgoing Network Translation as well as an inside Dynamic PAT address to be used as the primary pool got used up. In configuring our static commands we will need to take two addresses out of our pool to be associated with the two inside servers needing to be accessed by hosts on the Internet. This is not a problem since our ISP gave us 30 addresses. We will simply take the last two registered IP addresses out of our pool (.28 and .29) and allocate them specifically to our web and media servers by use of the static command.

To take these two addresses out of the pool, our previously configured global command will need to be updated as follows:

51

device1(config)# global (outside) 1 199.199.199.3-199.199.199.27 netmask 255.255.255.224

In a real world scenario we would likely have mapped all this out from the beginning and would not have to modify our global pool. However, for training purposes going through these motions helps to give one an understanding of exactly what is required when configuring the nat, global and static commands.

Now we are able to configure our static commands with the two registered IP addresses that we just took from the pool.

The static commands would be configured as follows:

device1(config)# static (inside, outside) 199.199.199.28 192.168.1.10 netmask 255.255.255.255 device1(config)# static (inside, outside) 199.199.199.29 192.168.1.11 netmask 255.255.255.255

*Please note if no address translation is being used the static command is still necessary for inbound communications. However, the static command parameters change to:

(high security interface, low security interface) high security IP, high security IP

52

For example, if we were not performing NAT and host 199.199.199.28 sat on the inside network of our protected LAN and this host needed to be accessible from the Internet, our static command would be as follows:

device1(config)# static (inside, outside) 199.199.199.28 199.199.199.28 netmask 255.255.255.255

Notice that no NAT is taking place with the static command above, however the static command is still required to publish the inside IP address.

Figure 8 shows our current configuration with all of the relevant translations. Outbound communications are being Dynamically NATed to the global pool, with a Dynamic PAT as a backup, and our two servers are being Statically NATed to the appropriate registered addresses:
Figure 8 PIX with Inbound and Outbound Translations

Protected LAN Servers

53

There is still one final step in allowing inbound communications to our internal servers. As noted previously the static command sets up the connection or the mapping between the two registered and unregistered IP addresses.

However, just having the connection set up between the registered and unregistered IP addresses does not grant global access to these addresses. By default, the PIX denies access to internal networks or hosts from an external (or one that is of a lower security value) network. The static command created the mapping, but that is only the first step. The next thing that must be configured are specific Access Control Lists which will tell the PIX to specifically allow only particular types of inbound communications to those hosts or networks which have been translated with the static command.

*Please note - If you are using a PIX with software version 5.0 or lower you may still be using the conduit command which is used to define what type of connection is allowed to an inside host. This command as well as the outbound command which is used to permit or deny outbound communications through the PIX, have been superseded by the access-list and access-group commands, starting in PIX release 5.0.1. Cisco will no longer be supporting these commands after software version 6.3 and it is strongly encouraged by Cisco to begin a migration path from conduit and outbound commands to Access Control Lists.

In our example, we need to create access-lists that specifically allow web and media traffic to our internal servers.

54

It should be noted first off that by default all access lists commands have an implicit deny all. This means that all access in an access lists is implicitly denied unless you specifically give access by using the permit statement.

The basic syntax for the access-list command is as follows:

access-list ID [line line-num] {deny|permit} protocol <source_address | interface if_name> [operator port] destination_address [operator port] The access-list ID can be any name or number you wish to identify a group of access-list command statements. It helpful to keep the name specific to what the ACL will be doing. For example, you might want to name the ACL acl_out which clearly defines and identifies the ACL as one pertaining to inbound connections from the outside interface. The line keyword is used to insert a remark about the ACL. The permit or deny statement is self explanatory. The protocol option allows you to specify which protocol will be used with the ACL (tcp or upd). The source_address will be the host or network address that will be accessing the particular destination_address. The keyword any can be used to let any host access the destination_address. If a single host needs access, use the host keyword. If a particular network needs access, specify the network as well as the network mask. The interface keyword can be used with the associated interface name if the interface has a dynamically assigned IP address. The operator port is used to match port numbers used by the source or destination. Valid operators are as follows: o Lt Less than
55

o Gt Greater than o Eq equal to o Negq not equal to o Range an inclusive range of values The port parameter must be used after an operator to identify the protocol port used by the source host initiating the connection. The destination_address is the host or network global address that was specified in the static command. The second port parameter must be used after an operator to identify the protocol port used by the destination host.

***PIX 7.x Info The access-list syntax has not been updated to the following:

access-list access_list_name [line line_number][extended] {deny | permit} protocol source_address mask [operator port] dest_address mask [operator port | icmp_type] [inactive] All of the above info we went over when looking at the 6.x ACL still applies, but the main difference with 7.x is the fact that we need to use extended ACLs. Well look at how it gets laid out in our example below.

Once the access-list has been defined, the access-group command must be used to bind the access-list(s) to the appropriate interface.

The basic syntax for the access-group command is as follows:

access-group ID in interface low_interface

56

 The ID in the access-group must be the same identifier as was used in the access-list statement. The low_interface must be the lower security interface which was specified in the static command. This is interface that external users will access the registered global address.

Now that we have defined the access-list and access-group commands and their associated options we can apply this to our example.

In our example we want to permit web traffic to come from the Internet to our web server sitting on our internal protected LAN.

We have already set up our static statements for the web and media servers, so we are ready to move on to the next step.

Next, lets allow the web server to be accessible from the Internet for web traffic. Port 80 is the standard TCP port for web traffic. We will need our access-list command to permit this traffic, as follows:

device1(config)# access-list acl_out permit tcp any host 199.199.199.28 eq 80

***PIX 7.x Info For PIX 7.x the same ACL would look like this:

device1(config)# access-list acl_out extended permit tcp any host 199.199.199.28 eq 80

57

Notice we are permitting tcp traffic over port 80 from a source of any, meaning anyone external to our outside interface, to only host 199.199.199.28. The ACL will always start with the source, in this case any and end with the destination, in this case host 199.199.199.28. The eq operator means, equal to or only that particular port. After you enter the above command you will notice that instead of saying eq 80 at the end of your access-list it will say eq www. This is a feature of the PIX to translate well known and frequently used port values. You could also opt to specify eq www instead of eq 80 depending on your preference.

Next, lets take care of the other server. As stated previously, this is a media server. The media server streams audio and video to Internet connected users. In this case, the media application requires many ports (both TCP and UDP) to be opened up to permit this streaming media from the server. Because so many ports will be needed we can take advantage of another command on the PIX, the object-group command.

The object-group command is a feature introduced in PIX software version 6.2 which essentially allows you to group objects such as hosts or networks, protocols, ports and ICMP types. Once the object group has been configured, it can then be used with the access-list command on the PIX to reference all objects within the group. This helps to reduce multiple line access-lists and ultimately configuration size.

The following information shows the different types of object groups which can be created and their associated options. Additionally, object groups can be nested, where one object group is included as a subset to another object group:
58

object-group icmp-type grp_id Specifies that the object group is related to icmp-type. The grp_id is a parameter that identifies the object group. It can be any assigned name or number (between 1 and 64 characters). icmp-object icmp_type The icmp_type is the decimal number or name of an ICMP type.

object-group network grp_id Specifies that the object group is related to network. The grp_id is a parameter that identifies the object group. It can be any assigned name or number (between 1 and 64 characters). network-object host host_addr host_addr is used if one particular hosts is being added to the group. network-object net_addr netmask net_addr is used if a network is being added to the group.

object-group protocol grp_id Specifies that the object group is related to protocol. The grp_id is a parameter that identifies the object group. It can be any assigned name or number (between 1 and 64 characters). protocol-object protocol protocol is used to specify which protocol is being added to the group.

object-group service grp_id {tcp|udp|tcp-udp} Specifies that the object group is related to a service. Service refers to a group of TCP or UDP ports.
59

 The grp_id is a parameter that identifies the object group. It can be any assigned name or number (between 1 and 64 characters). tcp\udp\tcp-udp is used to specify which type of port will be used. port-object eq service service is used to define a group of TCP or UDP port specifications. port-object range begin_service end_service The range keyword indicates that range parameters follow. begin_service end_service is used with TCP or UDP port start to finish ranges.

In our example we have one host destination needing to be accessed by any one on the Internet, so using the network object group wouldnt buy us anything. Additionally, we are not concerned with icmp-type, or protocol when it comes to accessing this server. However, we do have multiple ports to open up so we can benefit from using the object-group type service.

Our media server requires the following ports be opened up:

TCP Ports: 80, 443, 554, 1755, 7070, 8080, and 9090

UDP Ports: 1755, 34445, 34446, 34447, 34448, 34449, 34450, 34451, 34452, 34453, 34454, 34455, 34456, 34457, 34458 and 34459

Lets start by setting up our service object-group for the TCP ports:

device1(config)# object-group service media_tcp_ports tcp device1(config-service)# port-object eq 80 device1(config-service)# port-object eq 443
60

device1(config-service)# port-object eq 554 device1(config-service)# port-object eq 1755 device1(config-service)# port-object eq 7070 device1(config-service)# port-object eq 8080 device1(config-service)# port-object eq 9090

Next, our service object-group for the UDP ports:

device1(config)# object-group service media_udp_ports udp device1(config-service)# port-object eq 1755 device1(config-service)# port-object range 34445 34459

Notice how we were able to use the range keyword to add all of those UDP ports from 34445-34459. Nice and clean, weve changed a multiple line access list into just a few lines by using the object-group command.

***PIX 7.x Info Nothing has changed with Object Groups in PIX 7.x. Learn to use object groups, they come in very handy! The best thing about object groups is being able to quickly add a host or a port to an existing object group without having to rewrite a new ACL. Simply make your update to the object group and it instantly gets applied to whatever ACLs the object group is used in.

Now that we have all of the ports added and our service object-group has been created, we can configure our access-list to allow the media server to be accessible from the Internet for streaming media traffic.

61

First the access-list including the object-group for TCP ports:

device1(config)# access-list acl_out permit tcp any host 199.199.199.29 object-group media_tcp_ports

Then we need another access-list including the object-group for UDP ports:

device1(config)# access-list acl_out permit udp any host 199.199.199.29 object-group media_udp_ports

***PIX 7.x Info Again, just remember if you are using 7.x to configure your ACLs as extended. 7.x ACLs for this example would be as follows:

device1(config)# access-list acl_out extended permit tcp any host 199.199.199.29 object-group media_tcp_ports

Then we need another access-list including the object-group for UDP ports:

device1(config)# access-list acl_out extended permit udp any host 199.199.199.29 object-group media_udp_ports

Now we have created the necessary access-lists which have been configured to permit the specific traffic we want to allow into the designated servers on our protected LAN segment. There is one final step we must take before users can begin to access our internal resources. The final step we must take is to bind the access-list to the outside interface using the accessgroup command, as follows:

62

device1(config)# access-group acl_out in interface outside

***PIX 7.x Info Nothing has changed with the access-group command in version 7.x.

Just remember in either version that the access-group command needs to match up to the access list name and be applied to the proper interface for the access list to take effect.

Figure 9 shows a final depiction of our example network with the associated traffic flows:
Figure 9 Inbound and Outbound Traffic Flows

Protected LAN Servers

63

Summary:

The above discussion and examples should give you a good idea of what it takes to configure the PIX for outbound and inbound communications. Again, as a recap, outbound communications, or those going from a higher to lower security interface, require the use of NAT and Global commands, while inbound communications, or those going from a lower to higher security interface require the use of Static and Access-List commands. The accesslists get bound to the interface with the Access-Group command.

***PIX 7.x Info Remember as well that you do have the option of switching off NAT for outbound connectivity by using the no nat-control command, but only do so if it makes sense in your environment.

Virtual Private Networking (VPN) with the PIX Is it possible to use the PIX Firewall as a Virtual Private Networking tunnel endpoint. The PIX supports both remote access and site-to-site VPNs. From the remote access VPN perspective, the PIX can be used as a remote access device which would give a client access from an internet connected machine into a secure, private Local Area Network. Many companies use this to allow employees to connect to the corporate network from their home or while traveling. In addition, the PIX can be used to connect to another PIX (or other VPN capable device) which allows you to connect one Local Area Network to another. This can be a secure way to link two sites together using the Internet and bypass expensive leased line service such as T1 lines. We will look at both of these scenarios in the following pages.
64

PPTP, L2TP or IPSec

The PIX supports VPNs using PPTP, L2TP and IPSec. However, in our following discussions we will only be focusing on VPN connectivity using IPSec. There are many reasons for focusing on IPSec. One primary reason is that IPSec is an IETF open standard. Open standards are almost always better when considering interoperability, security and overall performance. PPTP is a proprietary Microsoft solution that should only be considered if there is a special circumstance warranting its use. L2TP is an IETF open standard but does not include any security which is essential for VPNs. Because L2TP does not have any security characteristics of its own, it relies on IPSec for security. Overall, IPSec is a best-practice of the industry including enhanced security features such as better encryption algorithms and more robust authentication.

Remote Access VPNs through the PIX

PIX Firewall software version 6.0 and later support VPN connections from clients running the Cisco VPN client software versions 3.x and 4.x. Building off our previous example configurations we will outline the configuration tasks necessary to allow client VPN connections to the PIX.

Lets set up a new example scenario. A former employee has been asked to come back to work and help out on a high priority project. This former employee has since moved out of state, but his knowledge about this project warrants him working on it remotely. His hiring manager has approved that he perform all of his necessary tasks from home using his high-speed Internet
65

connection. Our job is to configure the PIX to give him secure access into the inside protected LAN using VPN. Figure 10 shows the remote user with a high-speed connection to the Internet ready to be set up to access internal network resources using VPN
Figure 10 Remote VPN user
Protected LAN Servers

Remote Access VPN PIX Configuration Tasks

The first step in our configuration tasks to ensure assign a new block of unregistered IP addresses for VPN clients. We have decided to use an available network of 192.168.2.0/24 for the VPN client network. When a client comes in via VPN they will be assigned an address on this network.

We can do this with the ip local pool command. This command creates a pool of addresses to be used specifically for assigning dynamic IP addresses to VPN clients. These addresses need to be completely separate and must not overlap with any other IP address or pool on the PIX. We will issue the following command to our configuration:

66

device1(config)# ip local pool client_VPN 192.168.2.1-192.168.2.254

***PIX 7.x Info the ip local pool command is the same in 6.x and 7.x

When a remote user VPNs in, we do not want them to be NATed. To avoid using the NAT that is already in place, we will need to create new access list. This access-list will ensure that all client VPN (IPSec) packets avoid NAT. We configure the access-list as follows:

device1(config)# access-list Do_Not_NAT permit ip any 192.168.2.0 255.255.255.0

***PIX 7.x Info Again, same basic command and idea, however since this is PIX 7.x we need the extended access list:

device1(config)# access-list Do_Not_NAT extended permit ip any 192.168.2.0 255.255.255.0

This access list permits traffic from any source to our new VPN Client IP address pool. Now that we have the access-list configured we need to bind it to the NAT statement to avoid NAT on the IPSec packets.

device1(config)# nat (inside) 0 access-list Do_Not_NAT

***PIX 7.x Info No changes to the syntax of the above command in 7.x

67

As we stated previously NAT with an ID of 0 essentially turns off NAT. In this case we are turning off NAT for anything matching our access-list named Do_Not_NAT, which is any traffic destined for our VPN Client IP address pool.

IPSec and IKE Details

IPSec, short for IP Security, is a set of protocols developed by the IETF to support secure exchange of IP packets. For IPSec to work, the participating devices must establish a Security Association, or SA. The SA is basically the way in which the two corresponding devices agree on how to encrypt data and communicate securely. To establish the SA, the two devices generally use the Internet Key Exchange (IKE) protocol. IKE is a hybrid protocol which implements key exchange within the Internet Security Association and Key Management Protocol (ISAKMP) framework. IKE is beneficial in that it automatically negotiates IPSec SAs and therefore can play a big role in enabling IPSec secure communications. The use of IKE also helps to eliminate manual preconfiguration and therefore keeps associated costs down.

There are two primary phases IKE uses when establishing the SA. The first phase of IKE, referred to as Phase 1, is responsible for the two devices authenticating to each other. Both devices must be authenticated securely to move on to the next phase. In Phase 2, assuming that the two devices have established a secure channel, the security associations can be negotiated. This negotiation includes what form of encryption to use, lifetimes of the SA, etc. The final result to all of this is for IKE to generate the encryption and authentication keys to be used by IPSec. These keys are then used by the
68

two devices for encoding and decoding traffic using the DES or 3DES encryption algorithms.

Now that weve had some high-level discussion of IKE and IPSec, lets take a look at the specific command required on the PIX. Well start with the IKE specific commands.

The following commands are the IKE (ISAKMP) policy commands required for the VPN Client running 3.x or 4.x code. We will list them out as they will be configured on the PIX and then explain each command:

device1(config)# isakmp policy 10 authentication pre-share device1(config)# isakmp policy 10 encryption des device1(config)# isakmp policy 10 hash md5 device1(config)# isakmp policy 10 group 2 device1(config)# isakmp policy 10 lifetime 86400 isakmp policy 10 simply means that is the priority we are assigning to our IKE policy. IKE policy 1 is the highest priority. By starting with priority 10 we leave room to add higher priority IKE policies in the future. authentication pre-share means that the PIX and its peer must both contain pre-shared keys. encryption des is the encryption method to be used by IKE. The other option on the PIX would be 3DES which must be purchased separately or come with an enhanced software package.
69

 hash md5 is the hash method we have chosen. The other alternative is to use hash sha which is the default. group 2 is the defined Diffie-Hellman (DH) group number. VPN Client software running 3.x and later needs to be the DH Group 2 or above (Group 1 is the default). lifetime 86400 is the lifetime of the SA policy, in seconds. 86,400 seconds equals 1 day.

Next, ISAKMP negotiation needs to be enabled on the interface on which the IPSec peer will communicate. In our case, it is the outside interface:

device1(config)# isakmp enable outside

We also need the isakmp identity address command which tells the PIX that an IP address will be used as the IKE peer identity. There are two options on this command, hostname or IP address. A good rule of thumb is to ensure that both sides send the same type of identity so as to avoid identity recognition failures. In this case we are setting our identity as address:

device1(config)# isakmp identity address

***PIX 7.x Info All of the above ISAKMP commands work exactly the same and have the same syntax in versions 6.x and 7.x.

70

Now that we have defined the IKE commands and parameters, we need to define our IPSec commands and parameters on the PIX.

First, we need to configure the PIX with the sysopt command, as follows:

device1(config)# sysopt connection permit-ipsec

The sysopt command with the connection permit-ipsec option implicitly permits any packet that came from an IPSec tunnel. The logic here is if it came from an IPSec tunnel in the first place, thorough access-list checking can be avoided. IPSec traffic is already protected since it was explicitly permitted by an access-list to begin with. To perform another check would be redundant and would potentially cause the tunnel to fail.

However, there is also the option of not configuring the sysopt connection permit-ipsec command and specifically allowing what you wanted the VPN users to have access to via access-lists. In most cases VPN users are to be treated as trusted clients on the internal network so the sysopt connection permit-ipsec is a handy command to allow those packets coming from the IPSec tunnel.

***PIX 7.x Info The sysopt connection permit-ipsec command works exactly the same and has the same syntax in versions 6.x and 7.x.

71

We also need to define an access list that specifies which traffic will be protected by IPSec:

device1(config)# access-list example_cryptomap_acl permit ip any 192.168.2.0 255.255.255.0

We want the whole network as had been configured in the IP local pool to be included in this access list.

***PIX 7.x Info Again, same ACL just need the extended keyword as weve covered before.

Next we need to configure the Phase 2 encryption parameters. The following three commands go together when configuring the Phase 2 parameters and encryption types:

device1(config)# crypto ipsec transform-set example_set esp-des espmd5-hmac This command defines which security protocols will be used in the IPSec SA and subsequently how the traffic will be protected. We have defined a transform set named example_set and will be using single DES with encapsulating security payload (ESP) for payload data encryption and will use MD5 for authentication on the payload data.

device1(config)# crypto dynamic-map dyn_example_map 10 set transform-set example_set

72

 A dynamic-map called dyn_example_map has been configured which allows the PIX to accept requests for new security associations from previously unknown peers. In our example above we have a remote user needing VPN access into our internal network. We do not have the specific IP address of the host or any other crypto map parameters on the remote user so therefore a dynamic crypto map needs to be created.

device1(config)# crypto map example_map 10 ipsec-isakmp dynamic dyn_example_map Now that the dynamic crypto map has been created the above crypto map ipsec-isakmp dynamic command is needed to add the dynamic crypto map set to a static crypto map.

Finally, we need to match our newly created dynamic map to the access-list we created earlier:

device1(config)# crypto dynamic-map dyn_example_map 10 match address example_cryptomap_acl

Again, this access list indicates what traffic should be protected. Another way of putting this is to say the traffic that gets viewed as interesting to be encrypted and decrypted is specified by this access list.

Now we need to tell the PIX which interface the crypto map is to be used on. The following command binds the IPSec engine on the outside interface:
73

device1(config)# crypto map example_map interface outside

***PIX 7.x Info All of the above crypto commands work exactly the same and have the same syntax in versions 6.x and 7.x.

Next, we need to configure the specific parameters on the PIX to be used by the VPN client:

vpngroup example_group address-pool client_VPN vpngroup example_group dns-server 192.168.1.10 vpngroup example_group wins-server 192.168.1.10 vpngroup example_group default-domain example.com vpngroup example_group idle-time 1800 vpngroup example_group password ******** Weve created a vpngroup called example_group. Weve assigned our previously created VPN IP address pool to the VPN group so that IP addresses will be assigned to VPN users. VPN users will also obtain DNS and WINS server information which is configured to point to server 192.168.1.10 (also our web server). Weve used the default-domain command to set up our internal domain name. The idle-time has been set to 1800 seconds which equals 30 minutes. If a user is idle for 30 minutes they will be disconnected. Finally the password command indicates the pre-shared key which will need to be configured in the VPN client.
74

One final option we could add to the vpngroup command would be the splittunnel parameter. This option allows the VPN client to have simultaneous access to the internal network and to the Internet. This command uses our previously defined access-list name to tell which traffic gets split tunnel access and is configured as follows:

vpngroup example_group split-tunnel Do_Not_NAT

***PIX 7.x Info This is where things change with versions 6.x and 7.x. With PIX 7.x you no longer have the vpngroup command. This functionality is replaced by the use of the tunnel group, group policy, and username commands. This is a more hierarchical approach to configuring security policy information per groups of users. This is a very important change with 7.x so lets take a look at this in more detail.

Lets start by looking at the tunnel group functionality. Tunnel groups are something completely new to the PIX with version 7.x. Basically a tunnel group is a way to group specific connection information and specific connection policies into a logical group. The end result of this is a way to simplify system management.

PIX 7.x comes with two default tunnel groups which can be used for settings that would be common for many users. These default tunnel groups are called DefaultRAGroup and DefaultL2LGroup. The DefaultRAGroup is the default IPSec remote access tunnel group. This tunnel group would be used if there was no other specific tunnel group identified during tunnel negotiation.

75

The DefaultL2LGroup is the default IPSec LAN-to-LAN tunnel group. We will look more at the DefaultL2LGroup in the next section.

Basically tunnel groups hold the basic connectivity options you would like to configure to be associated with your remote VPN connectivity. Lets say that 90% of the company needed the same connectivity parameters assigned to them while connecting via Remote Access VPN, but the other 10% needed some completely different parameters, in this case you could set up the DefaultRAGroup for the 90% and create a new Remote Access Tunnel Group for the remaining 10%.

There are two main connectivity parameters that can be modified in an IPSec Remote Access tunnel group: the general attributes and the ipsec attributes.

General attributes include things such as which address pool should be used to assign IP addressing to a VPN client, the IP address of the dhcp server that will be used by clients connecting to the VPN, and which default group policy to associate to the tunnel group (we will be looking more at the group policy shortly which will help to tie this all together.

IPSec attributes include things such as authorization attributes (i.e. how a user is authenticated when connecting to the VPN), pre-shared-key values, etc.

As I mentioned before, PIX 7.x comes with a default tunnel group that may be used, or you have the option of creating a new tunnel group.

There are three basic attributes are needed in a remote access tunnel group:
76

 The connection type must be set to IPSec remote access The address assignment method must be set The authentication method must be set

Lets look at how we would go about creating a new tunnel group for Remote Access VPN users. First we configure the tunnel group name and type:

device1(config)# tunnel-group example_group type ipsec-ra

Next, we need to assign our address pool to the tunnel group so that our VPN users would obtain addresses from the pool we created earlier. This is configured in the general attributes of the tunnel group, as follows:

device1(config)# tunnel-group example_group general-attributes device1(config-general)# address-pool client_VPN

Finally, we need to configure the authentication method. This will be the preshared key that is used in the VPN client software group parameters. This setting is configured in the IPSec attributes of the tunnel group, as follows:

device1(config)# tunnel-group example_group ipsec-attributes device1(config-ipsec)# pre-shared-key 1234567

To view the configuration of all existing tunnel groups on your PIX, you would issue the following commands:

device1# sh run all tunnel-group

77

The default tunnel Remote Access tunnel group comes with the following parameters:

device1# sh run all tunnel-group DefaultRAGroup

tunnel-group DefaultRAGroup type ipsec-ra tunnel-group DefaultRAGroup general-attributes no address-pool authentication-server-group LOCAL no authorization-server-group no accounting-server-group default-group-policy DfltGrpPolicy no dhcp-server no strip-realm no strip-group tunnel-group DefaultRAGroup ipsec-attributes no pre-shared-key no authorization-required authorization-dn-attributes CN OU peer-id-validate req no radius-with-expiry no chain no trust-point isakmp keepalive threshold 300 retry 2

Now, in addition to the tunnel group, PIX 7.x also gives us the option of utilizing the group policy. Group policy is the place where attributes such as wins and dns server IPs are listed, the vpn idle timeout is set, vpn access hours are configured, etc. The tunnel group refers to a group policy that sets the terms for user connections after the tunnel is established. This allows you to group users together. For example, you may want all of the accounting department to only have access to VPN in from 8-5, while the IT department would need to have 24x7 access. This can be done easily by using group policies.

Similar to default tunnel groups that come with PIX 7.x, there is a default group policy which is called DfltGrpPolicy. In many cases, the company
78

requirements for all VPN users is similar enough that you could set the specific parameters to the default group policy and never need to create a new one. In other cases, it will be beneficial to create specific group policies for specific group of people. This will be determined by the requirements of your environment.

The default group policy comes with the following parameters:

device1# sh run all group-policy DftlGrpPolicy

group-policy DfltGrpPolicy internal group-policy DfltGrpPolicy attributes wins-server none dns-server none vpn-access-hours none vpn-simultaneous-logins 3 vpn-idle-timeout 30 vpn-session-timeout none vpn-filter none vpn-tunnel-protocol IPSec password-storage disable ip-comp disable re-xauth disable group-lock none pfs disable banner none ipsec-udp disable ipsec-udp-port 10000 split-tunnel-policy tunnelall split-tunnel-network-list none default-domain none split-dns none secure-unit-authentication disable user-authentication disable user-authentication-idle-timeout 30 ip-phone-bypass disable leap-bypass disable nem disable backup-servers keep-client-config client-firewall none client-access-rule none webvpn functions url-entry no html-content-filter no homepage no filter no url-list no port-forward port-forward-name value Application Access

79

Next, we need to look at how the username command is used. The username command is used to identify remote access users to the PIX when connecting via VPN. The command is very basic and is configured as follows:

device1(config)# username eric password 1234567

Each user that would be allowed to connect to the PIX could be assigned a username and password. By default the users created with the username command inherit the properties from the group policy associated with the username. However, there is also the option of assigning specific properties to a username and bypass any existing group policies. The ability to associate a user into a particular group policy is beneficial if there are different groups containing different attributes associated with different group policies.

For example, in our example above we talked about having an accounting group and an IT group both in their own group policy with different allowed VPN access hours associated with each. In this case it would be easy to take Bob, John and Mary from accounting and associate their usernames to the accounting group policy, then take Nish, Rick and Abby and associate their usernames to the IT group policy.

To assign the username to a specific group policy you would do the following:

device1(config)# username eric attributes device1(config-username)# vpn-group-policy <group name>

80

Remember as a recap: the tunnel connection parameters are associated to the tunnel group, the tunnel group refers to the group policy for that sets the terms for user connections once the tunnel is established, and the users get placed in the group policy. But users dont have to be placed in any group policies.

So lets pull this all together. Looking at the above example we used for a Remote Access VPN with version 6.x we used the vpngroup command to assign our users the following parameters:

We wanted them to use the address pool we created called client_VPN We set the dns server to be 192.168.1.10 We set the wins server to be 192.168.1.10 We wanted the domain to be set to example.com We wanted the vpn idle time to be set to 1800 seconds And we configured the group password that would be used by the VPN client.

Lets go through what it would take to do this using PIX 7.x, without using vpngroup command since it is no longer available, and well configure all new tunnel groups and group policies (in other words, we will not use the default groups for this example). In this case, well not associate the username to any particular group policy.

If you remember, we created our tunnel group previously with the following commands:

device1(config)# tunnel-group example_group type ipsec-ra

81

and assigned the IP pool to be used by the VPN clients:

device1(config)# tunnel-group example_group general-attributes device1(config-general)# address-pool client_VPN

and set the pre-shared key to be used with our VPN client software:

device1(config)# tunnel-group example_group ipsec-attributes device1(config-ipsec)# pre-shared-key 1234567

Now, that takes care of most of the configuration, but we still need to define the wins, dns, domain and vpn idle timeout. That is done with the group policy. So lets create the new group policy:

device1(config)# group-policy example_policy internal

Now we can modify the attributes:

device1(config)# group-policy example_policy attributes device1(config-group-policy)# wins-server value 192.168.1.10 device1(config-group-policy)# dns-server value 192.168.1.10 device1(config-group-policy)# default-domain value example.com device1(config-group-policy)# vpn-idle-timeout 1800

82

Now that our new group policy is created, we need to tell the tunnel group that we created to use the new group policy. This is done in the general attributes of the tunnel group we created earlier:

device1(config)# tunnel-group example_group general-attributes device1(config-general)# default-group-policy example_policy

Thats it, were done. Remember, to view the attributes of the policy, issue the following command:

device1#sh run all group-policy example_policy

Again, we could have opted not to create a new tunnel group or group policy and just made our configuration changes to the default Remote Access tunnel group (called DefaultRAGroup) and the default group policy (called DftlGrpPolicy). The configuration steps as we went through above are exactly the same, the only difference is the name.

For example, to change the dns server info in the default group policy, I would do so by issuing the following commands:

device1(config)# group-policy DfltGrpPolicy attributes device1(config-group-policy)# dns-server value 192.168.1.10

Make sense? Good! Do you see how using tunnel groups, group policies and usernames can be beneficial? They may seem a bit confusing at first, but Ive attempted to break it down here in the most basic terms possible. I think youll get the hang of it just fine!
83

Remote Access VPN Configuring the Client Software

Follow these steps to configure the VPN Client to work with the above PIX configuration. The client software configuration applies the same to version 6.x or 7.x.

1. Open the VPN client, and then click New. 2. Enter a name for the VPN Connection and click the Next button:

84

3. Enter the Host name or IP address of the server and click the Next button:

85

4. Enter the Group Access Information, including group Name and Password as configured on the PIX and click the Next button:

86

5. Click the Finish button to save the entry:

6. Once the connection has been saved, click the Connect button:

87

After this the remote VPN client should contact the PIX and VPN connectivity the internal network should be established.

*Please note that the above examples were taken from VPN Client version 3.6.4. The 4.x client has a slightly different look and feel but the configuration principles are the same.

Site-to-site VPNs through the PIX

Now we turn our attention to the other form of VPN connectivity with the PIX, the site-to-site VPN. There are a few terms for this form of VPN connectivity such as, site-to-site, LAN-2-LAN (L2L), Business-to-Business (B2B), etc. Although the names may differ, the concepts and configurations are the same. Many commands and concepts that we just went through when looking at the client VPN are very similar to the site-to-site configurations, so in efforts not to duplicate information we have already gone through in detail, we will outline all of the commands and provide any additional comments where necessary. Again, we will also be focusing on IPSec VPN configurations.

Lets set up a new example scenario. Your company just purchased another smaller company and your manager has asked you to come up with a way of connecting the two sites together. A high-speed Internet connection exists at the new site and budget will not allow for provisioning a leased line WAN link. After some thought, you determine that a site-to-site VPN would serve this situation perfectly. This will allow the two sites to be connected together
88

using their existing Internet connections which will save in bandwidth costs and a high level security will be maintained by using IPSec VPN configurations.

Figure 11 shows the remote office and how connectivity will be established through the VPN
Figure 11 Remote Site-to-Site VPN

Protected LAN Servers

Web Server .10

Site-to-Site VPN Tunnel

Media Server .11 Network 192.168.1.0/24 Inside .1
PIX FIREWALL

Network 199.199.199.0/27 .1 Outside

.2
Internet Connected Router

Internet Internet Connected Router

.2 Network 200.200.200.0/27 Outside .1

Protected LAN Clients

.20~.255

Remote Office
Inside .1

PIX

Network 192.168.100.0/24

Protected LAN Clients

.20~.255

The diagram above shows that a site-to-site VPN will be created between the Headquarters site and the Remote Office site. The Remote Office has a high-speed Internet connection and an internet connected router similar to the Headquarters site. The Remote Office has a registered IP address block of 200.200.200.0/27. The Remote Office is using 192.168.100.0/24 for the internal, unregistered IP address space.

89

* Please Note - While we could simply add the site-to-site VPN configuration on to the existing Client VPN configuration, I believe it will be more beneficial to treat the PIX as if it had not had any previous VPN configuration and start from scratch with a new VPN and IPSec configuration for site-to-site. This will allow us to outline every task and command required.

IPSec Modes - Tunnel vs. Transport

There are two IPSec modes to consider when looking at a site-to-site VPN, tunnel mode and transport mode:

Transport mode leaves the original IP header unchanged and secures packets between two endpoints. An example of transport mode would be where two hosts (Personal Computers, Servers, etc.) are themselves endpoints and do all of the IPSec encryption and authentication tasks.

Tunnel mode encapsulates the IP header and payload into a new IPSec packet for communications between two endpoints, usually gateway devices. An example of tunnel mode would be where two gateway devices, such as two PIX Firewalls, would handle all of the IPSec encryption and authentication tasks based on the packets they are receiving from the hosts they protect. A rule of thumb is that transport mode should be used for endto-end sessions and tunnel mode should be used for everything else. We will be focusing on tunnel mode in our site-to-site configuration example.

Site-to-site VPN PIX Configuration Tasks

90

As mentioned previously many of the configuration tasks and commands necessary for the site-to-site VPN is very similar to the Client VPN configurations. As we go through the commands, I will point out any new commands specific to the site-to-site example and explain them appropriately. For example purposes, the PIX located at the Remote Office will be named device2.

Lets begin by defining our access-lists on both Firewalls. These access lists initiate IKE and IPSec negotiation as soon as one of the PIXs receives traffic that is destined for the other PIXs inside network. In our example, we want to permit traffic to be sent from device1s internal network, through the IPSec tunnel, to device2s internal network. On the other side, we want to permit traffic to be sent from device2s internal network, through the IPSec tunnel, to device1s internal network. This can be achieved with the following access lists:

device1(config)# access-list 101 permit ip 192.168.1.0 255.255.255.0 192.168.100.0 255.255.255.0

device2(config)# access-list 101 permit ip 192.168.100.0 255.255.255.0 192.168.1.0 255.255.255.0

***PIX 7.x Info Again, same basic command and idea, however since this is PIX 7.x we need the extended access list:

device1(config)# access-list 101 extended permit ip 192.168.1.0 255.255.255.0 192.168.100.0 255.255.255.0

91

device2(config)# access-list 101 extended permit ip 192.168.100.0 255.255.255.0 192.168.1.0 255.255.255.0

We also need to tell the PIX to allow traffic matching the above access lists to bypass the existing NAT process. To put it another way, any traffic deemed interesting for IPSec (as defined in the access lists above) must be exempt from NAT services, as we did in our previous example.

Device1(config)# nat (inside) 0 access-list 101

Device2(config)#nat (inside) 0 access-list 101

***PIX 7.x Info No changes to the syntax of the above command in 7.x

Next we move on to configuring the IKE parameters. First well enable isakmp on our outside interfaces of both PIX Firewalls.

device1(config)# isakmp enable outside

device2(config)# isakmp enable outside

***PIX 7.x Info No changes to the syntax of the above command in 7.x

92

Next, we will need to specify the authentication pre-shared key for the remote peer. This pre-shared key must be identical on both peers. The IP address included in the command tells the PIX which peer the pre-shared key is valid for:

device1(config)# isakmp key 1234567 200.200.200.1 netmask 255.255.255.255

device2(config)# isakmp key 1234567 199.199.199.1 netmask 255.255.255.255

Notice how device1 points to device2s outside interface IP and vice versa.

***PIX 7.x Info With PIX 7.x we will not be entering the pre-shared key here. It will be configured in our tunnel group instead. Remember in the Remote Access VPN section we discussed that we use tunnel groups for Remote Access and LAN-to-LAN connection parameters. LAN-to-LAN tunnel groups follow the same general idea and must be configured for LAN-to-LAN VPN connections. Again, we have the choice of using the default LAN-to-LAN tunnel group, called DefaultL2LGroup, or creating our own. For this example, well be creating a new tunnel group and naming it with the IP address of the remote side peer.

For LAN-to-LAN tunnel groups how we do this is we first configure the tunnel group first as an l2l tunnel group, then configure the authentication method. In this case, were using pre-shared keys on both ends so we would configure the LAN-to-LAN tunnel group as follows:

93

device1(config)# tunnel-group 200.200.200.1 type ipsec-l2l

device2(config)# tunnel-group 199.199.199.1 type ipsec-l2l

Next, we configure the authentication parameters, which as mentioned before we will be using pre-shared keys:

device1(config)# tunnel-group 200.200.200.1 ipesec-attributes device1(config-ipsec)# pre-shared-key 1234567

device2(config)# tunnel-group 199.199.199.1 ipesec-attributes device2(config-ipsec)# pre-shared-key 1234567

Such as the case with our tunnel group configuration for Remote Access we have the option of assigning a group policy to the new tunnel groups we created. If we do not specify a group policy specifically, the default group policy (called DfltGrpPolicy) would be associated to the new tunnel groups.

To configure a group policy for the tunnel group you would do the following: device1(config)# tunnel-group 200.200.200.1 general-attributes device1(config-general)# default-group-policy <group name>

To view the new tunnel group and all of the associated parameters, issue the following:

device1#sh run all tunnel-group 200.200.200.1

94

Next, well configure our isakmp identity and other isakmp policy configurations as we did in our previous example. We need to do the same on both sides:

device1(config)# isakmp identity address device1(config)# isakmp policy 10 authentication pre-share device1(config)# isakmp policy 10 encryption des device1(config)# isakmp policy 10 hash md5 device1(config)# isakmp policy 10 group 2 device1(config)# isakmp policy 10 lifetime 86400

device2(config)# isakmp identity address device2(config)# isakmp policy 10 authentication pre-share device2(config)# isakmp policy 10 encryption des device2(config)# isakmp policy 10 hash md5 device2(config)# isakmp policy 10 group 2 device2(config)# isakmp policy 10 lifetime 86400

***PIX 7.x Info No changes to the syntax of the above commands in 7.x

Next, lets look at the required IPSec parameters. The sysopt and transformsets are needed as was the case previously:

device1(config)# sysopt connection permit-ipsec device1(config)# crypto ipsec transform-set example_set esp-des espmd5-hmac
95

device2(config)# sysopt connection permit-ipsec device2(config)# crypto ipsec transform-set example_set esp-des espmd5-hmac

***PIX 7.x Info No changes to the syntax of the above commands in 7.x

We also need to define the crypto map. This command differs slightly from our previous example because in this case we are not using dynamic maps. If you remember previously dynamic maps were needed to allow the PIX to accept requests from previously unknown peers. In this case the two peers are being specifically defined and therefore there is no need for dynamic maps. The following static crypto map tells the PIX to use IKE to establish IPSec SAs for the crypto map called example_map.

device1(config)# crypto map example_map 10 ipsec-isakmp

device2(config)# crypto map example_map 10 ipsec-isakmp

Next we need to define what traffic gets viewed as interesting to be encrypted and decrypted. The following crypto map statement will utilize our previously created access-list 101 to do this:

device1(config)# crypto map example_map 10 match address 101

device2(config)# crypto map example_map 10 match address 101

***PIX 7.x Info No changes to the syntax of the above commands in 7.x
96

Since we are using a static crypto map, we need to define the remote peer:

device1(config)# crypto map example_map 10 set peer 200.200.200.1

device2(config)# crypto map example_map 10 set peer 199.199.199.1

***PIX 7.x Info No changes to the syntax of the above command in 7.x

Then we tell the PIX which transform-sets to use for the peers defined above:

device1(config)# crypto map example_map set transform-set example_set

device2(config)# crypto map example_map set transform-set example_set

***PIX 7.x Info No changes to the syntax of the above command in 7.x

And finally, we apply the crypto map to the interface on the PIX:

device1(config)# crypto map example_map interface outside

device2(config)# crypto map example_map interface outside

***PIX 7.x Info No changes to the syntax of the above command in 7.x
97

Thats all there is to it! It is good to know of some general debugging and verification commands. The following are some good commands for troubleshooting IPSec connectivity: show crypto ipsec sa Displays any current IPSec security associations show crypt isakmp sa Displays any current IKE security associations debug crypto isakmp If encountering problems with your IPSec connections, start here. This command will give you detailed IKE debug output which is the first step to the IPSec process. debug crypto ipsec Useful in debugging IPSec problems. If IKE is working fine, this should be your next logical place to check.

PIX Device Manager (PDM) / Adaptive Security Device Manager (ASDM) The PIX Device Manager (PDM) is a graphical tool used by your web browser to help you set up, configure and monitor your PIX Firewall. With 7.x this has been changed to ASDM. Almost all of the discussion following here pertains to both PDM and ASDM, from here on out well simply call it the GUI for graphical user interface. The GUI has various drop-down menus, task oriented menus, and browse option which, when configurations are applied, send the correct command-line interface (CLI) commands to the PIX. The GUI works with PIX Firewalls with software version 6.0 and above. The GUI is a Java based tool that automatically uploads the required applet to your workstation when the PIX Firewall is accessed from your browser. The GUI

98

uses Secure Socket Layer (SSL) to ensure security during client to PIX communications.

All PIX Firewalls with software version 6.0 and above come preloaded with PDM or with 7.x ADSM, and there are no specific installation tasks. The GUI resides in the Flash memory of the PIX Firewall. If a PIX has been newly upgraded to software version 6.0 or above, the the software can be downloaded and installed manually. Because of its use of SSL, the GUI also requires a DES activation (license) key or the more secure 3DES. PIX Firewalls with software version 6.0 or above ship with a pre-installed DES key. 3DES keys must be purchased and registered separately.

To access the PIX using the GUI the PIX will need to have the http server enabled based on which networks or hosts you would like to have access to PDM, and through which interface. In a common scenario you may want to open up the whole inside network to allow access to the PDM. This can be achieved by the following command:

device1(config)# http server 192.168.1.0 255.255.255.0 inside

Or, if you just wanted to enable the http server to be used on a host by host basis, that can be achieved as well:

device1(config)# http server 192.168.1.100 255.255.255.255 inside

It is also possible, but not always recommended, to enable the http server for networks or hosts on the outside interface:

99

device1(config)# http server 199.199.199.10 255.255.255.255 outside

***PIX 7.x Info No changes to the syntax of the above commands in 7.x

Once the http server has been defined, assuming the PDM or ASDM software is loaded on the PIX, you should be able to access the GUI interface through a web browser by typing https proceeded by the PIXs inside interface IP address:

https://192.168.1.1

Once you do this you will be prompted to accept some security certificates, which you will need to do to proceed. Once logged you will have access to the following components: PDM Startup Wizard this wizard allows you to create a basic configuration. VPN Wizard this wizard allows you to create a remote access or siteto-site VPN. Configuration GUI this allows most configurations to be done graphically. Monitoring and Reporting Tools these tools allow you view realtime and historical data Graphical Tools including system graphs, connection graphs, Intrusion Detection System (IDS) graphs, and interface graphs. Syslog View this allows you to view syslog messages generated by the PIX.

100

There is one small limitation to the GUI and that is you can only access one PIX at a time, but otherwise it is a pretty nice tool. My take on the GUI is it is a nice to have, but not an essential. You may have noticed I spent the majority of the time in laying the groundwork and building the PIX configurations and examples using the CLI. The reason for this is I believe everyone should know the CLI and there may be situations where clients or businesses do not run or allow the GUI in their security policy. For example, I recently did some work for a large consulting firm that supported over 150 PIX Firewalls for various companies. In this environment, the GUI was not used at all. So if someone were to learn and understand how configure the PIX using the GUI only, they are not getting the entire picture, and may need to go back and learn the details of the CLI commands to be successful.

With that said, we have spent a lot of time and effort in laying down the foundation of what it takes to configure the PIX using the CLI. The GUI can now be used as a valuable tool on top of this foundation, and can help to give a visual depiction of the configuration tasks that have been carried out. I have never configured a PIX out of the box with only the GUI and I probably never will! I have made it a focus to train myself to use the CLI for all of my configuration tasks and in doing so I now understand the PIX a whole lot better.

It is definitely worthwhile to help you gain an understanding of what the GUI can do and how to access the PIX using the GUI and that has been my goal in this final chapter. I trust you now can appreciate why it was included at the end rather than at the beginning.

101

Fixups / Inspect

The PIX is focused on providing the most secure use of applications and services. However, some applications require special handling by the PIX to be able to successfully inspect the application appropriately. The applications that require special inspection by the PIX are generally those which embed IP addressing information in the data packet, or open other channels on dynamically assigned ports. A lot of this has to do with the fact that some applications dont work so well with NAT and PAT, which have covered thoroughly earlier in the book.

The application inspection process is pretty elaborate and gets into monitoring of application sessions to determine port numbers for secondary channels that may be opened up behind the scenes of the application. For example, some protocols open secondary TCP or UDP ports to improve performance. So you may be coming in over one TCP port, then the application may use that initial port to dynamically assign another port. The application inspection functionality is there to monitor these behind the scene actions being carried out by some applications that exhibit these behaviors.

You can think of it is a traffic cop, making sure the proper roads are being taken at the proper times by the proper folks.

Out of the box, the PIX with version 6.x will be preconfigured with the basic application inspection entries. For the most part you will not need to do much with these, but there may be a case where you need to change some of these defaults. This can be done with the fixup protocol command.
102

In my experience the fixup protocol command is not something that requires a lot of configuration changes. There may be a case where the web server on a network listens on TCP port 8880 rather than 80, and you can add a new fixup protocol command for the new http port number.

device1(config)# fixup protocol http 8880

***PIX 7.x Info With PIX 7.x the fixup protocol command was deprecated, in other words, it went bye-bye.

PIX 7.x has a new command which does essentially the same things, it is called inspect. Again, this is not an area where too many configuration changes are needed, but it is good to have the general idea of what it is.

103

PIX Quick Configuration Guide Since you now know the basics of the PIX (you did finish reading everything else already, right?!), lets look at a few more real world scenarios:
Scenario 1 PIX 501 Configured for Basic Internet Access

A small business owner has an office of 50 employees, and needs some way to secure his network. He might want to the ability to do VPN access for situations where his employees need to do some work from home. He has asked you to come up with the most secure and most affordable way of doing this.

After looking at your PIX Firewall At-A-Glance sheet (on page 11) you determine that a PIX 501 with a 50 user license would be his best bet. You contact your friendly Cisco Reseller at www.keyitconsulting.com (shameless plug) and order the right PIX to meet your specs.

It arrives and you begin your installation. You want to begin with the most basic configuration steps.

STEP 1

Getting in the right mode:

104

Remember, you start out in unprivileged mode and need to be in privileged mode:

pixfirewall> enable Password:******* pixfirewall#

Note: The > prompt indicates unprivileged mode. The # prompt indicates privileged mode.

Now you are in privileged mode which gives you access to the full configuration of the PIX. To check your configuration, do the following:

pixfirewall# show run

This will display your configuration, which at this point, will just have the basics and will not allow you to use the PIX. It must be configured!

How do you get in the proper configuration mode?

Easy, just type config t:

pixfirewall# config t pixfirewall(config)#

Note: if you do ever need to get out of configuration mode, just type exit:

pixfirewall(config)# exit
105

pixfirewall#

STEP 2

Set the passwords:

pixfirewall(config)# enable password YourEnablePass pixfirewall(config)# passwd YourPass

Note: the enable password is what will be required when entering enable mode. The passwd is what will be required when first accessing the device via telnet or console.

STEP 3

Name the PIX:

pixfirewall(config)# hostname device1

STEP 4

Set the duplex mode and IP addresses on the interfaces:

Outside interface: device1(config)# interface ethernet0 100full device1(config)# ip address outside 5.5.5.1 255.255.255.224

106

Inside interface: device1(config)# interface ethernet1 100full device1(config)# ip address inside 10.1.1.1 255.255.255.0

Note: remember you can set the speed to 10 or 100 and the duplex to half or full, or you can set it to autonegotiate. In our example, we want to hardcode it to 100 Mbps, Full duplex. However, if we had problems with the speed or duplex settings and wanted to just let the PIX autonegotiate, we would simply enter this command:

device1(config)# interface ethernet1 auto

107

STEP 5

Name the interfaces and set the appropriate security levels:

device1(config)# nameif ethernet0 outside security0 device1(config)# nameif ethernet1 inside security100

Note: remember the outside interface is always the least secure that is why it is set to security0. Why is it least secure? Because it is directly attached to and sitting on the internet. The inside interface is always the most secure and therefore set to security100. Why is it most secure? Because it is protecting your internal network from the internet. Make sense? Good!

STEP 6

Set the default route:

device1(config)# route outside 0.0.0.0 0.0.0.0 5.5.5.2

Note: this tells the PIX to send every packet to any network (first set of four 0s) with any subnet mask (second set of four 0s) to the ISP router which is 5.5.5.2

108

STEP 7

Set up the PIX to allow outbound communications with the NAT and Global commands:

device1(config)# global (outside) 1 5.5.5.3 netmask 255.255.255.224 device1(config)# nat (inside) 1 0.0.0.0 0.0.0.0

Note: this says to translate everything on the inside network (0.0.0.0 0.0.0.0) to the 5.5.5.3 address that was given by the ISP. The NAT and Global commands are always in a pair and the 1 identifies them being in use together.

STEP 8

The final step is to test internet connectivity from a computer on the inside network. To do this you will need to set up a computer and give it an IP address on the same IP range as has been configured on the inside interface of the PIX. For example, lets say your inside interface has an IP address of 10.1.1.1 255.255.255.0. That means that all network devices (PCs, printers, servers, etc) on the inside network will need to be on the 10.1.1.0 network, which includes the range of 10.1.1.1~10.1.1.254. The network devices should all be configured with a default gateway of the PIXs inside interface, which in the case of our example is 10.1.1.1. Of course, your inside network IP addressing scheme can be anything you like.

109

Scenario 2 PIX Configured as a DHCP Client to an ISP

Lets assume for this scenario that your ISP has only assigned you one dynamic IP address, and you need to configure your PIX with this dynamic IP address. This is a very common scenario and the good news is that this is possible with the PIX! This scenario will be covering those steps necessary to configure the PIX as a Dynamic Host Control Protocol, or DHCP client to the ISP.

STEP 1

Configure your outside interface to get a DHCP assigned IP address from the ISP with the following commands:

device1(config)# ip address outside dhcp setroute device1(config)# interface ethernet0 auto

Note: with this command implemented on the outside interface the PIX will receive a dynamically assigned IP address (via Dynamic Host Control Protocol or DHCP) from the ISP. The setroute option will allow the PIX to automatically assign the default route to the ISPs IP address. With this command enabled, you will not need to manually configure a default route as we did in the above example.

Remember what our default route command was in the last example? As a refresher, it was ip route 0.0.0.0 0.0.0.0 5.5.5.3. Again, you will not need to perform this command since you already indicated to the PIX to get the default route directly from the ISP with the setroute command option.
110

STEP 2

Make sure the ISP assigned IP address is on the PIX. You can do this by performing a show command on the outside (ethernet0) interface:

device1(config)# show interface e0

You will see an output of information on the interface such as the following:
Hardware is i82659 ethernet, address is 0020.32cc.7ed1 IP address 5.5.5.3, subnet mask 255.255.255.224 MTU 1500 bytes, BW 100000 Kbit full duplex 4983 packets input, 982092 bytes, 0 no buffer Received 200 broadcasts, 0 runts, 0 giants 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 338 packets output, 25535 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/3) software (0/1)

After performing this command, make sure the ISP assigned address is showing on the PIX. Notice in bold above where you can find it. This command is also handy if you ever need to know the hardware (MAC) address of the interface. This is shown above as address is 0020.32cc.7ed1.

111

STEP 3

Make sure the default route is being learned by the PIX. Remember, our setroute command told the PIX to get the default route directly from the ISP. We can check this with the following command:

device1(config)# show route

outside 0.0.0.0 0.0.0.0 5.5.5.2 1 DHCP static

This output shows that the PIX got the route from the ISP. This is similar to, and does the same thing as a manually configured route on the PIX using the command ip route 0.0.0.0 0.0.0.0 X.X.X.X, but again in this case the default route is learned by the ISP so no manually added static route is needed. Good job!

112

STEP 4

Set up the NAT and Global pair, similar to what we did above, but with a minor change. As has been explained throughout the book, outbound communications through the PIX require some type of Network Address Translation (or NAT). In this case, we only have one external address to NAT to, so we are really doing PAT (Port Address Translation). Now we did not manually assign the IP address to the Outside interface, but rather obtained it via DHCP from the ISP, so our Global command will need to use a slightly different option:

device1(config)# global (outside) 1 interface device1(config)# nat (inside) 1 0.0.0.0 0.0.0.0

Note: our NAT command looks identical, but our Global command uses the interface option which tells the PIX to PAT all outbound traffic to the Outside interface which has been assigned the IP address of 5.5.5.3. So all user traffic from this PIX will appear to be coming from the same IP address of 5.5.5.3

113

STEP 5

The final step is to test internet connectivity from a computer on the inside network. To do this you will need to set up a computer and give it an IP address on the same IP range as has been configured on the inside interface of the PIX. For example, lets say your inside interface has an IP address of 10.1.1.1 255.255.255.0. That means that all network devices (PCs, printers, servers, etc) on the inside network will need to be on the 10.1.1.0 network, which includes the range of 10.1.1.1~10.1.1.254. The network devices should all be configured with a default gateway of the PIXs inside interface, which in the case of our example is 10.1.1.1. Of course, your inside network IP addressing scheme can be anything you like.

Scenario 3 PIX with Port Redirection to an Internal Web Server and a Remote Desktop Client

In this scenario we will build off of our previous example. Our ISP has assigned via DHCP one IP address on the outside interface of the PIX. The PIX is working fine with this configuration for outbound communications (See scenario 2 above) but currently there is no inbound communications through the PIX. Your boss just came in and said that he needs you to do two things: 1) he wants you to allow web access to the company website, keeping the web server on the inside network and thus maintaining security through the PIX; and 2) he needs to be able to access his work desktop from home using Microsoft Remote Desktop. You say, no problem boss, Ill have it done right away!

114

STEP 1

First you need to define your static entries for the host and the port redirecting. Lets start with the web server:

device1(config)# static (inside,outside) tcp interface 80 10.1.1.20 80 netmask 255.255.255.255

Note: The interface option tells the PIX to use the IP address as had been assigned on the outside interface via DHCP by the ISP. The 10.1.1.20 is the address configured on the inside Web Server. This static command will forward all traffic hitting the outside interface IP, destined for port 80 to the inside host IP of 10.1.1.20. STEP 2

Now we need to do the same thing for the Microsoft Remote Desktop machine:

device1(config)# static (inside,outside) tcp interface 3389 10.1.1.50 3389 netmask 255.255.255.255

Note: TCP port 3389 is the port used by Microsoft Remote Desktop. The 10.1.1.50 is the address configured on your boss work desktop. This static command will forward all traffic hitting the outside interface IP, destined for port 3389 to the inside host IP of 10.1.1.50.

115

STEP 3

Next, we need to set up the Access Lists to allow access through the PIX. Again, we will start with the web server:

device1(config)# access-list acl_out permit tcp any interface outside eq www

Note: the acl_out access list is permitting any source (i.e. anyone on the Internet) to access the destination IP address of the outside interface over TCP port 80 (www traffic).

STEP 4

Next, the Access List for the Remote Desktop communications: device1(config)# access-list acl_out permit tcp host 2.2.2.1 interface outside eq 3389

Note: We are adding another line to the acl_out access list to permit a source host 2.2.2.1 which is your boss home registered IP address to access the destination IP address of the outside interface over TCP port 3389 (Microsoft Remote Desktop traffic). By limiting this access to only your boss home IP address you maintain better security.

116

STEP 5

The final step is to bind the access list to the interface using the access-group command:

device1(config)# access-group acl_out in interface outside

In this scenario we are successfully using one DHCP assigned IP address for outbound communications through the PIX, using Inside Dynamic PAT, as well as inbound communications through the PIX, using Port Redirection. As I mentioned previously, Port Redirection should be considered a last resort as it does not scale well and has limitations. With the availability of static IP addresses being readily available today, this option may not ever have to be used. However, it was worthwhile including it as an option for those who may need to utilize a configuration similar to this.

In cases where this does need to be used it would be helpful to use some type of Dynamic DNS service to keep track of the ever changing DHCP addresses provided by your ISP. One good service for this can be found at www.no-ip.com. This service will keep track of the DHCP assigned IP address and associate it with a name of your choosing so that no matter how many times the IP may change, you can always access your server or service via your chosen name, rather than the actual IP address.

117

Scenario 4 PIX Configured as a DHCP Server for the Inside Network

In this scenario we would like the PIX to do Dynamic IP address allocation, or be what is knows as a DHCP Server, to all users on the inside network. A DHCP Server provides the ability for an inside host to be given an IP address automatically upon boot-up with no manual intervention required by the end user.

Depending on which PIX hardware and software platform you are using it will depend on how many active DHCP hosts can be available on the PIX. See the following table for the specifics:

PIX Firewall Version

Cisco PIX Firewall Platform

Version 5.2 and earlier Version 5.3 to version 6.0

All platforms

Maximum Number of DHCP Client Addresses (Active Hosts) 10

PIX 506/506E All other platforms

32 256 32 128

Version 6.1 and higher

PIX 501 PIX 501 with optional 50-user license

PIX 506/506E All other platforms

256 256

118

The PIX can easily be set up as a DHCP Server by performing the following steps.

STEP 1

Enable DHCP on the inside interface.

device1(config)# dhcpd enable inside

STEP 2

Configure the range of IP addresses that the PIX will assign to clients.

device1(config)# dhcpd address 10.1.1.2-10.1.1.50 inside

Note: Again, the amount of active connections at any given time will depend on your hardware and software versions as indicated in the above table.

STEP 3

Configure the length of the lease. This is the amount of time the IP address will be leased to the client.

device1(config)# dhcpd lease 2400

Note: this lease is indicated in seconds. The default lease time is 3600 seconds, so if no dhcpd lease command is used, the lease time will default to 3600 seconds.
119

STEP 4

Configure the DNS server IP address to be assigned to each client.

device1(config)# dhcpd dns 10.1.1.100

Note: This is an optional command. If no DNS server command is indicated, the DNS server will default to the PIXs inside address.

STEP 5

Configure the WINS server IP address to be assigned to each client.

device1(config)# dhcpd wins 10.1.1.100

Note: This is an optional command. If no WINS server command is indicated, the WINS server will default to the PIXs inside address.

STEP 6

Configure the domain name to be given to each client.

device1(config)# dhcpd domain example.com

Note: This is also an optional command.

120

Scenario 5 Using ICMP (Ping) to Test Connectivity Through the PIX Firewall

It should be noted right away that ping on the PIX should only be used for testing and troubleshooting. The following is what is needed to fully open the PIX Firewall to Ping for testing and troubleshooting purposes.

By default, inbound ICMP through the PIX is denied. That means that if you try to ping from somewhere on the Internet to the outside interface or a Statically NATed server on this inside, it will fail. By default, outbound ICMP is permitted, however the incoming reply is denied.

STEP 1

To allow pings inbound as well as responses to outbound pings an Access List will need to be created to permit ICMP:

device1(config)# access-list acl_out permit icmp any any

STEP 2

The next step is to bind the access list to the interface using the access-group command:

device1(config)# access-group acl_out in interface outside

121

STEP 3

To allow ping ability to the interfaces on the PIX, a different command is needed:

device1(config)# icmp permit any inside

device1(config)# icmp permit any outside

Note: This command will allow you to ping the IP address of the inside interface (from the inside) and the outside interface (from the Internet). Instead of using the any keyword, you can specify exactly which networks or hosts are allowed to ping the PIX interfaces. Again, these commands should only be used for troubleshooting and I would recommend taking all of the commands off after successfully troubleshooting.

STEP 4

Remove ping commands:

device1(config)# no icmp permit any inside

device1(config)# no icmp permit any outside

device1(config)# no access-list acl_out permit icmp any any

122

Useful Command Review FAQ

The PIX Firewall contains many valuable commands to view specific details about the PIX in general and specifically about the configuration details of your PIX. These are termed show commands because they do just that, they show you details about the PIX.

These commands can be issued on the PIX without affecting the current configuration of the PIX. They are essentially read only commands. In this section we will cover the basic and most important show commands and at the end I will show you how to view all of the available show commands so that you can be sure to understand all of the options.

We will also be looking at other useful commands, such as the command needed to save your configuration on the PIX, how to remove commands, and other must-know commands.

How do you view your PIX Firewall configuration?

device1(config)# show run (or) device1(config)# show conf

These commands both do the same thing. You can use either command. Each of these commands show your running configuration. I generally use show run, as this is the same on a Cisco Router.

123

How do you save your PIX Firewall configuration?

device1(config)# write mem

This command writes your configuration to memory.

How do you check your PIX Firewall interfaces?

device1(config)# show int

This command gives you information on all of the interfaces on the PIX Firewall.

How do you check specific interfaces on the PIX Firewall?

device1(config)# show int inside

This will show you information on just the inside interface. If you wanted to view just the outside interface, you would simply type the following:

device1(config)# show int outside

In both of these examples, you want to make sure your interfaces are showing in an up state. If the interface shows up but the line protocol shows down you may need to check your cabling.

124

If the interface is seen as administratively down you have not followed my previous instructions on how to bring up the interface

OK, I forgot that part; tell me again, how do I bring up the interface?

device1(config)# interface ethernet1 100full

You bring up the interface by specifying the speed and duplex and making sure there is no keyword of shutdown on the interface command.

How do you shut down an interface on your PIX Firewall?

device1(config)# interface ethernet1 100full shutdown

How do you remove a command on your PIX Firewall?

In most cases, you can enter the command with a no in front of it.

For example, lets say we had the following access-list:

device1(config)# access-list acl_out permit icmp any any And we wanted to remove it. We would simply enter the command with a no in front of it:

device1(config)# no access-list acl_out permit icmp any any

125

How do you view the static commands configured on your PIX Firewall?

device1(config)# show static

How do you make sure your static commands are accurately translating your registered to unregistered IP addresses?

device1(config)# show xlate

If you do not remember the details around the static command and NAT translations, please review the chapter titled Outbound Communications Through the PIX on page 28 and the chapter titled Inbound Communications Through the PIX on page 38. These are very important concepts to grasp and understand about the PIX Firewall!

How do you view the routes configured on your PIX Firewall?

device1(config)# show route

Do you have to be in configuration mode to issue these show commands?

No, you can also issue the commands while in privileged mode. If you do not remember the difference between being in privileged mode and configuration mode, please review the PIX Basics section on pages 14-17.

How do you view all of the available show command options on your PIX Firewall?

126

device1(config)# show ?

Performing a show ? will list all of the available show options on the PIX, along with a brief description of each. Take some time to look through all of the options and perform any show command you like to gain more detail on the PIX Firewall. These commands are very helpful in not only understanding your PIX Firewall, but also in troubleshooting potential issues with the PIX. Again, you can issue any show command you like at any time, provided you are in either privileged or configuration mode. Again, these commands are read-only so you do not need to worry about impacting the existing configuration on your PIX Firewall when issuing these commands.

In fact it would be a good idea get used to typing a question mark after every command you arent sure of. This will give you all of the available options and usages of the command as well as give you a general idea of what the command does if you arent 100% sure.

127

Conclusion If you have faithfully followed the concepts and examples I have laid out in this eBook I trust that you now understand the basic principles of the PIX. These foundational principles will guide you and help you in whatever specific types of requirements and configurations you will face. The access lists and IP addresses will change but you will bring to the table a knowing and understanding of what it takes to configure the PIX for the client or employer you are working for.

It is up to you know to take this information and run with it. There are plenty of opportunities out there in your sphere of influence to take these foundational principles of the PIX and put them into practice. You have been given keys to success, now it is up to you to take those keys and do something with them! If you came into this eBook with some PIX experience behind you, I hope that it was able to reinforce and confirm what you already knew and potentially clarify some of those things you werent too sure of.

Important note! Updates to this ebook are always free. If you would like to be automatically alerted to whenever an update is made to the ebook so that you can always have the newest copy, send a blank email to: fwkeysupdates@firewallkeys.com *Please note: this is a separate email list than the general PIX Firewall Keys news list that you may have subscribed to from the website so just be sure to send a blank email to the address above and youll be taken care of! It has been a pleasure serving you this information. Until next time!
128