Resources Archived Articles Cisco PIX Firewalls: Fixups, Failover, and DHCP
| Cisco PIX Firewalls: Fixups, Failover, and DHCP |
| Sunday, 05 May 2002 21:59 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
IntroductionThe 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:
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.
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 FailoverTo 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.
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 DHCPThe 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 athttp://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_62/config/pixclnt.htm .
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.
To troubleshoot this, we have the following commands: show ip address dhcp ConclusionOne 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 eleven CCIE's (4 of whom are double-CCIE's, R&S and Security). NetCraftsmen has 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/about-us/bios/staff-articles-and-blogs/pete-welcher.html . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to This e-mail address is being protected from spambots. You need JavaScript enabled to view it . 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 This e-mail address is being protected from spambots. You need JavaScript enabled to view it . 5/4/2002Copyright (C) 2002, Peter J. Welcher |
