Keep your PIX firewall secure! In part 5 of our series of excerpts from the Cisco Press book, Cisco Secure Internet Security Solutions, you'll learn all about AAA authorization and why two DMZs are better than one.
Cisco Secure Internet Security Solutions - Chapter 4
by Andrew Mason, Mark Newcomb
Cisco Secure PIX Firewall - Part 5
Dual DMZ with AAA Authentication
This section introduces AAA authorization and creates two DMZs. This section focuses on the PIX configuration aspects of AAA. This section also introduces a failover PIX and access lists into this configuration.
Figure 4-8 shows how this network is configured. Notice that there are two PIX Firewalls, a primary and a failover. Should the primary PIX fail, the failover PIX takes over all of the duties of the primary PIX. You also have two DMZs, the public and the accounting DMZs.
The accounting DMZ is used for clients on the Internet to access the accounting data for
Figure 4-8: Dual DMZ Configuration
(Click image for larger view in a new window)
Although there is a failover cable that connects the serial ports on the firewalls, you also
added a hub on the inside interfaces to allow connectivity between the firewalls and the
interior router in order to save interfaces on the interior router. You did the same between
the outside interfaces of the firewalls and the exterior router. Both PIX Firewalls must have
connectivity to both DMZs for the failover PIX to operate correctly, should the primary fail.
The configuration of the primary PIX follows. This section discusses the changes made to
this configuration after the listing. The blank lines were added for clarity.
enable password enablepass encrypted
passwd password encrypted
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 public security 50
nameif ethernet3 accounting security 60
interface ethernet0 auto
interface ethernet1 auto
interface ethernet2 auto
interface ethernet3 auto
ip address outside 192.168.1.1 255.255.255.0
ip address inside 172.30.1.2 255.255.255.248
ip address public 192.168.2.1 255.255.255.0
ip address accounting 10.200.200.1 255.255.255.0
fixup protocol http 80
fixup protocol http 10120
fixup protocol http 10121
fixup protocol http 10122
fixup protocol http 10123
fixup protocol http 10124
fixup protocol http 10125
fixup protocol ftp 21
fixup protocol ftp 10126
fixup protocol ftp 10127
failover link failover
no rip inside passive
no rip outside passive
no rip public passive
no rip accounting passive
no rip inside default
no rip outside default
no rip public default
no rip accounting default
pager lines 24
aaa-server TACACS+ (inside) host 10.1.1.41 thekey timeout 20
aaa authentication include any outbound 0 0 0 0 TACACS+
aaa authorization include any outbound 0 0 0 0 TACACS+
aaa accounting include any outbound 0 0 0 0 TACACS+
aaa authentication serial console TACACS+
snmp-server community ourbigcompany
snmp-server location Seattle
snmp-server contact Mark Newcomb Andrew Mason
snmp-server host inside 10.1.1.74
snmp-server enable traps
logging host 10.1.1.50
logging trap 7
logging facility 20
no logging console
outbound limit_acctg deny 10.200.200.0 255.255.255.0
outbound limit_acctg except 10.10.1.51
outbound limit_acctg permit 10.200.200.66
outbound limit_acctg permit 10.200.200.67
apply (accounting) limit_acctg outgoing_dest
access-list acct_pub permit host 10.200.200.52
access-list acct_pub deny 10.200.200.0 255.255.255.0
access-group acct_pub in interface public
telnet 10.1.1.14 255.255.255.255
telnet 10.1.1.19 255.255.255.255
telnet 10.1.1.212 255.255.255.255
url-server (inside) host 10.1.1.51 timeout 30
url-server (inside) host 10.1.1.52
filter url http 0 0 0 0
global (outside) 1 192.168.1.50-192.168.1.253 255.255.255.0
global (outside) 1 192.168.1.254 255.255.255.0
nat (inside) 1 10.1.1.0 255.255.255.0 0 0
nat (inside) 1 10.2.1.0 255.255.255.0 0 0
nat (inside) 1 10.3.1.0 255.255.255.0 0 0
nat (public) 1 192.168.2.1 255.255.255.0 0 0
nat (accounting) 0 0 0
static (public, outside) 192.168.1.30 192.168.2.30
static (public, outside) 192.168.1.35 192.168.2.35
static (public, outside) 192.168.1.49 192.168.2.49
conduit permit tcp host 192.168.1.30 eq http any
conduit permit tcp host 192.168.1.35 eq ftp any
conduit permit tcp host 192.168.1.49 eq smtp any
conduit permit tcp any eq sqlnet host 192.168.1.30
route outside 0 0 192.168.1.2 1
route inside 10.1.1.0 255.255.255.0 172.30.1.1 1
route inside 10.2.1.0 255.255.255.0 172.30.1.1 1
route inside 10.3.1.0 255.255.255.0 172.30.1.1 1
route public 192.168.2.0 255.255.255.0 192.168.2.1
route accounting 10.200.200.0 255.255.255.0 10.200.200.1 1
arp timeout 7200
mtu inside 1500
mtu outside 1500
mtu public 1500
mtu accounting 1500
The first change made to this configuration is the added nameif command for the
accounting DMZ, assigning a security level of 60. The next change is that you enabled this
interface with the interface command. You then assigned an IP address to the interface.
Next, you configured the failover parameters.
The failover commands are relatively simple to use. Before discussing the commands, this section takes a few moments and discusses the requirements for a failover PIX, how the primary and secondary PIX are connected, and how the failover PIX is configured.
When purchasing a PIX, consider purchasing a failover PIX at the same time. When both
are purchased together, there is a significant price reduction on the failover unit. Because
the PIX is generally used as the primary device protecting your network, it usually makes
sense from both service and fiscal points of view to make this a redundant system.
For a PIX to failover to another PIX after failure, both firewalls must have identical
hardware and identical software versions. There is a proprietary cable made specifically for
connecting between PIX Firewalls. On the back of each PIX is a port labeled failover. The
cable ends are labeled primary and secondary. Once the primary PIX is configured, turn the
secondary PIX's power off. Connect the cable, and restore power to the secondary PIX.
After a few seconds, the secondary PIX acquires a copy of the configuration on the primary
PIX. Should the primary PIX fail, the secondary PIX starts establishing connections.
However, any connections that exist when the primary PIX fails are dropped and need to be
reestablished. After the secondary PIX is powered on with the failover cable connected,
changes should only be made to the primary PIX. One limitation of the failover system on
the PIX is the length of the failover cable. The length of the cable cannot be extended, and
the cable is required to be used. Therefore, you cannot use a primary PIX in one physical
location and the secondary PIX in another location.
The first command used is the failover active command. This command, like all
commands, should only be entered on the primary PIX. This command establishes that
failover is configured and that the present PIX is the primary PIX. Using the no form of this
command forces the current PIX to become the secondary PIX.
The second command shown is the failover link command. You have specified that the port
used for the failover is the failover port. There is one more command used regarding
failover. This command, write standby, is shown at the bottom of the configuration. The
write standby command should be used after each time the configuration is changed. This
causes the secondary PIX to receive a copy of the current configuration.
The failover features of the PIX are similar to those used with the Hot Standby Router
Protocol (HSRP) in that the standby device remains inactive until the primary device fails.
The standby device, on activation, assumes the IP and Media Access Control (MAC)
address of the primary unit. Likewise, the previously active device assumes the IP and
MAC addresses of the formerly standby device. Because network devices do not see any
change in these addresses, no new ARP entries need to be made on the hosts using the PIX
Starting with the PIX IOS 5.0 software release, stateful failovers are supported. Prior to this
release, the PIX did not maintain a copy of the connection state in the standby unit. When
the primary device failed, network traffic needed to reestablish previous connections.
Stateful failovers overcome this issue by passing data about the state of connections
between the primary and the standby devices within state update packets. A single packet
traversing the PIX can establish a new connection state. Because each connection state
changes on a per-packet basis, every packet received by the currently active device requires
a state update packet to be relayed to the inactive device. Although this process works very
well, there are some latency-sensitive applications that will time out before the failover
process is completed. In these cases, a new session will need to be established.
IP states are supported, as are TCP states, except those using HTTP. Almost no UDP state
tables are transferred between the active and standby devices. Exceptions to this include
dynamically opened ports used with multichannel protocols, such as H.323. Because DNS
resolves use a single channel port, the state of DNS requests is not transferred between
A dedicated LAN interface between the two PIX devices is required to achieve stateful
failover. State update packets are transmitted asynchronously in the background from the
active device to the standby device over the dedicated LAN interface. There are also a few
configurations changes required when using stateful failover. These changes are covered below in the section "Stateful Failover Configuration."
Several criteria are considered before a failover occurs. If the standby device detects that
the active device is powered down, the standby device will take active control. If the
failover cable is unplugged, a syslog entry is generated, but both devices maintain their
present state. An exception to this is during the boot process. Should the failover cable be
unplugged while the devices are booting, both devices will assume the same IP address,
causing a conflict on your network. Even if you are configuring the PIX Firewalls for
stateful failover using a dedicated LAN interface, the failover cable must be installed on
both devices for failover to function properly.
Failover hello packets are expected on each interface every 15 seconds. When the standby
device does not receive a failover hello packet within 30 seconds, the interface runs a series
of tests to establish the state of the active device. If these tests do not reveal that the active
device is present, the standby device assumes the active role.
A power failure on the active device is detected through the failover cable within 15
seconds. In this case, the standby device assumes the active role. A disconnected or
damaged failover cable is detected within 15 seconds.
Stateful Failover Configuration
Only a few commands need to be added to a configuration to enable stateful failover. The
following is a partial configuration, showing the commands necessary to enable stateful
failover. After the configuration, the commands are discussed.
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 failover security 60
ip address outside 192.168.1.1 255.255.255.0
ip address inside 172.30.1.1 255.255.255.0
ip address failover 10.200.200.1 255.255.255.0
failover ip address outside 192.168.1.2
failover ip address inside 172.30.1.2
failover ip address failover 10.200.200.2
failover link failover
Notice that the interfaces are named failover
, and a security level is assigned to the interface with the nameif
command. You could have named this interface anything, but for clarity, it is named failover here. This is the interface you will be using to transfer state update packets between the active and the standby devices.
After assigning IP addresses and netmasks to each of the interfaces, you are ready to start on the failover commands. Start failover with the failover active command. Next, use the failover ip address command on all of the interfaces.
When using the failover ip address command, you need to remember two things. First,
every interface needs the failover ip address command entered for that interface. If an
interface does not have an associated failover ip address command and the state of that
interface is changed to down, failover will not occur. For example, if you did not add the
failover ip address command for the outside interface and the cable connecting that
interface broke, all data intended to travel through that interface will be lost. This defeats
the purpose of having a failover device, because a failover device should allow all services
to continue after the primary device has failed. Additionally, because both devices must
have the same hardware installed, there is no reason not to enable failover to check all
interfaces. The second item that you need to remember is that the failover ip address needs to be on the same subnet but with a different IP address than that to which the interface is set.
The final configuration required is to assign a dedicated interface to failover. Using the failover link command with the interface name assigned by the nameif command, Ethernet2 has been assigned as the failover interface in this example.
You added commands to disable RIP on all interfaces. Notice that each interface has two lines associated with that interface: a no rip interface_name passive and a no rip interface_name default command. Each one of these commands accomplishes a different objective. The no rip interface_name passive command causes the PIX to stop listening to RIP updates. The no rip interface_name default command causes the PIX to stop broadcasting known routes through RIP.
RIPv1 and RIPv2 are both available on the PIX through the rip command. Use the no form of the rip command to disable a portion of RIP. Use the show rip command to show the current RIP entries and the clear rip command to clear RIP tables. The full syntax of this command is:
rip interface_name default | passive [version [1 | 2]]
[authentication [text | md5 key ( key_id)]]
The parameters and keyword meanings are listed in Table 4-2:
|interface_name||The interface to which this command should be applied.|
|default||Broadcasts a default route on the interface.|
|passive||Enables passive RIP (listening mode) and propagates the RIP tables based on these updates.|
|version</td>||RIP version 1 or 2. Version 2 must be used if encryption is required.|
|authentication||Enables RIP version 2 authentication.|
|text||Sends RIP updates as clear text. This is not a recommended option.|
|md5||Sends RIP update packets using MD5 encryption. Version 2 only.|
|key||This is the key used to encrypt RIP updates for version 2.|
|key_id||The key identification value. Both sides must use the same key. Version 2 only.|
pager lines Command
The pager lines command specifies how many lines are shown when a show config command is issued before a more prompt appears. Although this can be set to almost any value, 24 works well when using standard Telnet applications.
In our next installment of Cisco Secure Internet Security Solutions - Chapter 4, we will look at AAA commands, as well as additional Dual DMZ configuration considerations.