Cisco PIX Firewalls: Fixups, Failover, and DHCP

Peter J. Welcher and Grant Moerschel

Introduction

This month we continue a series of articles on the PIX. Previous articles in this series:

Cisco PIX Firewall Basics	http://www.netcraftsmen.net/welcher/papers/pix01.html
Cisco PIX Firewalls: Access Lists and Management	http://www.netcraftsmen.net/welcher/papers/pix02.html

The present article takes a look at what fixups are, the need for fixups, the PIX failover commands, and how to use DHCP with the PIX (as both client and server).

The online reference materials for configuring Cisco PIX Firewall Version 6.1 are at the URL http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_61/index.htm . Please look there for the details we had to omit in this article. For basic PIX troubleshooting, the following looked rather useful: http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_61/config/bafwcfg.htm#xtocid25 .

Another good source of information about the Cisco PIX is the Cisco CSPFA course. This is a security-certification track course. See http://www.cisco.com/pcgi-bin/front.x/wwtraining/CELC/index.cgi?action=CourseDesc&COURSE_ID=1628 .

What is a Fixup?

The PIX does NAT and PAT Address Translation, as discussed briefly in prior articles. For brevity, we'll refer to either NAT or PAT as NAT henceforth. Certain application protocols do not work well with NAT. Generally, the problem is that these protocols rely upon packets that mix layers of the OSI model. Or, to say that less technically, the payload of the packet contains one or more IP addresses. Technically, the OSI Layer 4+ part of the packet contains Layer 3 addressing information. See the following figure to get an idea of what this looks like. The diagram shows the packet as it leaves a computer on the inside of the firewall/NAT point.

This packet was sent from within a privately addressed network through a NAT point (PIX) towards the Internet. As this special packet goes through the PIX NAT point, the source and/or destination IP addresses get address translated by the NAT function. TCP or UDP ports may get shifted as well. But the IP address in the payload (from the Layer 3 point of view) does not get translated. The following figure tries to suggest the address changes with color and text:

This is what the packet looks like on the Internet, on the outside of the PIX NAT point.

The problem arises because the offending application reads the untranslated IP Address from the payload, and then subsequently tries to communicate with it. If this address is a private address from inside a NAT point, there is no route to it and no way to communicate with it.

Another source of problems can be applications that pass a TCP or UDP port number in the payload. If these pass through a PAT device, the port in the payload does not normally get translated. The result is something on the outside trying to communicate with the wrong port, from the PAT device's point of view. Diagram:

Various protocols run afoul of generic NAT firewalls due to one of these two forms of behavior.

Application protocols with one or the other forms of problems with NAT include:

DNS
RTSP
FTP
HTTP
H323
RSH
SMTP
SQLNET
SIP
Skinny
NetBIOS over IP (several different functions)

The PIX provides special handling for the above protocols. When it does NAT, it recognizes these protocols, watches for any special packets or messages. When the PIX needs to, it fixes up the payload IP address or port, to match the other translations in effect. This results in fewer user problems as far as making applications work through the NAT point (PIX), a good thing for all concerned.

Some other protocols have problems with NAT. For example, SNMP network management generally does not work through a NAT point, because SNMP tools retrieve the IP addresses of devices. Since the format of the payload bearing the IP addresses is rather complex, no NAT device that I know of attempts to fix up the payload addresses. I know of a company that tried to develop code to handle this, and found it difficult.

The PIX does the right thing auto-magically in most cases. See also http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_62/config/fixup.htm

for some details. There is a list of supported protocols in the Configuration Guide which contains the above list as well as other protocols. See

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_62/config/subnets.htm#xtocid3

With some protocols we may have to help our PIX out a little bit. Sites lately shift FTP or HTTP or other protocols to unusual ports. The PIX needs to know how to snoop on the conversations on the unusual port in the right way, in order to spot the packets where the payload IP address or port needs fixing. So we have to help it out by telling it what protocol (program) is being run on the unusual port. We do this with the fixup protocol command.

Fixup protocol commands are for special handling of applications through the firewall. They let you enable or disable the special handling function for the applications listed above on the well known port numbers they tend to run on (e.g. http on port 80). In addition the fixup commands allow you to add other port numbers for these applications or replace the well known port number with another (with the exception of RSH and SIP - see below). For example, if you plan to have SQL*net connections going through the PIX on the well known port 1521 and another port of your choice, say port 1526, you may specify both using the commands fixup protocol sqlnet 1521 and fixup protocol sqlnet 1526 . The two entries will appear on two lines in the configuration and both ports will receive special handling.

The fixup protocol command enables the Adaptive Security Algorithm when the protocol port numbers differ from the default. This command is global and changes things for both inbound and outbound connections, and cannot be restricted to any static command statements. The no version of the command disables fixups for the specified protocol.

The following table shows some fixup protocol commands that we might actually use in a real PIX configuration.

Command	Explanation
`fixup protocol ftp 21 strict`	The FTP port can be changed from the usual 21. If you change the default port 21, say to 2021, all FTP control connections must happen on port 2021. FTP control connections on port 21 will no longer work unless you also specify the standard port 21. If you disable FTP fixups with the `no fixup protocol ftp` command, outbound users can start connections only in passive mode, and all inbound FTP is disabled. The `strict` option prevents web browsers acting as FTP clients from sending embedded commands, which can be a security risk. It forces one FTP command at a time.
`fixup protocol http 80`	Special port handling is required for web traffic.
`fixup protocol h323 1720`	The fixup protocol h323 command provides support for Intel InternetPhone, CU-SeeMe, CU-SeeMe Pro, MeetingPoint, and MS NetMeeting. Version 5.2 supports H.323 version 2. H.323 is a suite of protocols defined by the International Telecommunication Union (ITU) for multimedia conferences over LANs. H.323 supports VoIP gateways and VoIP gatekeepers.
`fixup protocol rsh 514`	You can change the port value for each service except rsh and sip.
`fixup protocol rtsp 554`	Real time streaming protocol used by RealAudio. Quicktime, Cisco IP/TV (must also include the fixup protocol rtsp 8554 statement), and others. Does not support multicast RTSP.
`fixup protocol smtp 25`	The fixup protocol smtp command enables the Mail Guard feature, which only lets mail servers receive the RFC 821, section 4.5.1 commands of HELO, MAIL, RCPT, DATA, RSET, NOOP, and QUIT. All other commands are rejected with the "500 command unrecognized" reply code. Microsoft Exchange administrators should take special note that by default their mail servers use the extended command set of ESMTP. The PIX SMTP fixup does not cover everything that may be needed for a transaction between two ESMTP servers. Therefore, be aware that the limited set of supported Mail Guard commands may be at the root of some mail flow problems. See the documentation for more details of getting PIX and Exchange to play well together.
`fixup protocol sqlnet 1521`	PIX Firewall uses port 1521 for SQLNet. This is the default port used by Oracle for SQLNet; however, this value does not agree with IANA port assignments.
`fixup protocol sip 5060`	The fixup protocol sip command enables SIP on the interface. SIP enables call handling sessions—particularly two-party audio conferences, or "calls." SIP works with Session Description Protocol (SDP) for call signalling. SDP specifies the ports for the media stream. Using SIP, the PIX Firewall can support any SIP Voice over IP (VoIP) gateways and VoIP proxy servers.
`fixup protocol skinny 2000`	SCCP telephony protocol support at the app layer to ensure that SCCP signaling and media packets can traverse the PIX and interoperate with H.323 terminals.

Thought: the next time you go shopping for a NAT/PAT capable firewall, ask the salesperson for the list of fixups their box does. If nothing else, the expression on their face as they say "huh?" might be rather amusing.

PIX Failover

To avoid having a SPoF (Single Point of Failure), many sites implement everything in pairs. Fabulous failover firewalling features peoples' paired PIXes ! (Note to readers: Pete thought this up. --Grant). Cisco has a great document which explains the steps of failover in detail, see http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_62/config/failover.htm .

PIX redundancy is relatively simple to implement. Buy two PIXes with the same specifications, one of which is licensed as a Standby unit (less money). Connect them together with the special failover cable taking note that one end of it is marked "primary" and the other "secondary." Connect the inside and outside interfaces on each PIX to the corresponding inside and outside subnets. People generally use small Ethernet switches in each location but redundancy can become very elaborate with dual-everything, including power sources. Smaller or frugal sites who don't require iron-clad security might use one switch with different VLAN's for this. Other sites don't allow that, since it can be viewed as a security accident waiting to happen.

In addition to the normally assigned IP address, assign unique failover IP addresses for each interface. These addresses do have to be in the same subnet. Lastly, use the failover command without an argument since the default PIX configuration does not enable failover. That's it! The devices will then poll to detect a failure of the primary.

Stateful failover is available, but requires configuration and a high-speed (100 or 1000 Mbps) crossover link between the PIX units, in addition to the failover cable. Stateful failover is activated by specifying the high-speed failover link. With the release of PIX 6.2 software, which is very fresh at this writing, Cisco introduces the ability to do LAN-based failover freeing you from having to use the custom failover cable. This can come in handy if your PIX-pair are further than 3 feet apart.

Use the show failover command to verify the status of the connection and to determine which of the two units is active. Note that if you plan to use the PIX as an IPsec end point, this information is not replicated if a PIX failover event occurs. So failover will break the IPsec connection.

Sample configuration commands for failover follow. They assume one high-speed interface has been named pix_failover . Always enter commands on the primary PIX otherwise changes will be lost.

Command	Explanation
`failover timeout 0:00:00`	Cisco recommends not changing this setting.It is provided for compatability with other manufacturer's equipment which does not apply at this time.
`failover poll 3`	Time in seconds for failover polling to the PIX backup unit. Default = 15. Setting set to 3 for faster stateful failover. Cisco recommends that the failover interface be on its own high-speed Ethernet.
`failover ip address outside 1.1.1.2`	Set the IP address assigned to the outside interface on the standby unit.This must be on the same subnet as the primary PIX outside interface.
f`ailover ip address inside 10.1.1.2`	Set the IP address assigned to the inside interface on the standby unit. This must be on the same subnet as the primary PIX inside interface.
`failover ip address management 10.2.2.2`	Set the IP address assigned to the management interface on the standby unit. This must be on the same subnet as the primary PIX management interface.
`failover ip address dmz 10.3.3.2`	The IP address assigned to the DMZ interface on the standby unit. This must be on the same subnet as the primary PIX DMZ interface.
`failover ip address pix_failover 10.4.4.2`	The IP address assigned to the pix_failover interface on the standby unit. This must be on the same subnet as the primary PIX pix_failover interface.
`failover link pix_failover`	The interface identified to be used for failover information and replication between units. Note that this interface must be set to 100 and full duplex for proper operation (unless Gigabit Ethernet is in use, of course) .
`failover replicate http`	Allows for stateful failover of HTTP sessions if you have enabled stateful failover.
`failover active`	Enter this command on the Standby unit if you want it to become the Primary
`no failover active`	Enter this command on the Primary if you want it to become the Standby

You can use the show failover command to identify failover status and which PIX is currently Primary and which Standby. And please do make configuration changes on the Primary!

PIX and DHCP

The PIX can act as both DHCP Server and Client, generally for SOHO (Small Office Home Office) use. If you put a PIX at your house, it can act as a DHCP server, providing addresses to the PCs in your home. For number of clients supported on the various PIX platforms, as well as other fine details, see the documentation at

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_62/config/pixclnt.htm .

Command	Explanation
`dhcpd address 10.1.1.101-10.1.1.130 inside`	Assign pool of addresses to be made available on the inside interface.
`dhcpd dns 10.1.1.100 10.1.2.100` `dhcpd wins 10.1.1.99` `dhcpd domain mydnsdomain.com`	Specify DNS server address(es), WINS server address, and DNS domain to be provided to clients by the DHCP server.
`dhcpd auto_config`	Automatically supply DNS server address(es), domain name, and WINS server to clients. This is an alternative to the previous three commands.
`dhcpd lease 3000`	Specify the lease time (default 3600 seconds).
`dhcpd enable inside`	Enable the DHCP process on the inside interface.

The DHCP client functionality allows the PIX to be issued an address by the cable or DSL modem or other upstream device. Re-issuing the command causes release/renew for the DHCP address.

Command	Explanation
`ip address outside dhcp setroute retry 15`	Obtain address for the PIX and for mapping of inside addresses from the external DHCP server (on the outside interface). The setroute option tells the PIX to set default gateway to that provided by the external DHCP server. (Do not configure your own default gateway if you want to use this option.) You can optionally specify the maximum number of retries.

To troubleshoot this, we have the following commands:

show ip address dhcp
debug dhcpc packet
debug dhcpc detail
debug dhcpc error

Conclusion

One more PIX article is planned, showing basic IPsec for the PIX. There are endless other IPsec combinations, but Pete says that a little IPsec at a time goes a long way.

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .

Grant P. Moerschel (CCNP #CSCO10108676) works for NovatoSystems.com LLC, an Internet security and network architecture consultancy and developers of FlackJacket security. NovatoSystems specializes in creating multi-layered secure networks based on the Cisco SAFE blueprint. FlackJacket, the premiere product offering of NovatoSystems, uses best-of-breed security components and advanced reporting systems to provide your organization with greater peace of mind regarding data protection. See http://www.flackjacket.net for more information. Questions, suggestions for articles, etc. can be sent to gm@flackjacket.net .