|
|
This chapter includes the following sections:
Failover lets you add a secondary PIX Firewall unit that takes control if the Primary unit fails.
This section includes the following topics:
A failover configuration example is provided in "Failover Configuration" in "Configuration Examples."
You can choose the Stateful Failover option if you have 100 Mbps LAN interfaces so that connection states are automatically relayed between the two units.
Both units in a failover pair communicate through the failover cable, which is a modified RS-232 serial link cable that transfers data at 9600 baud. The data provides the unit identification of Primary or Secondary, the power status of the other unit, and serves as a communication link for various failover communications between the two units.
The two units send special failover "hello" packets to each other over all network interfaces and the failover cable every 15 seconds. The failover feature in PIX Firewall monitors failover communication, the power status of the other unit, and hello packets received at each interface. If two consecutive hello packets are not received within a time determined by the failover feature, failover starts testing the interfaces to determine which unit has failed, and transfers active control to the Standby unit.
When a failover occurs, each unit changes state. The newly Active unit assumes the IP and MAC addresses of the previously Active unit and begins accepting traffic. The new Standby unit assumes the failover IP and MAC addresses of the unit that was previously the Active unit. Because network devices see no change in these addresses, no ARP entries change or timeout anywhere on the network.
If you are using Stateful Failover, connection states are relayed from the Primary unit to the Secondary unit. Without Stateful Failover, the Standby unit does not maintain the state information of each connection. This means that all active connections will be dropped when failover occurs and that client systems must reestablish connections.
The Stateful Failover feature passes per-connection stateful information to the Standby unit. After a failover occurs, the same connection information is available at the new Active unit. End user applications are not required to do a reconnect to keep the same communication session. The state information passed to the Standby unit includes the global pool addresses and status, connection and translation information and status, the negotiated H.323 UDP ports, the port allocation bit map for PAT, and other details necessary to let the Standby unit take over processing if the Primary unit fails.
Depending on the failure, the PIX Firewall takes from 15 to 45 seconds to cause a switchover. Applications not handled by Stateful Failover will then require time to reconnect before the Active unit becomes fully functional.
Stateful Failover requires 100 Mbps Ethernet interface to be used exclusively for passing state information between the two PIX Firewall units. This interface can be connected to any of the following:
PIX Firewall does not support use of either Token Ring or FDDI for the Stateful Failover dedicated interface. Data is passed over the dedicated interface using IP protocol 105. No hosts or routers should be on this interface.
Figure 3-1 shows two PIX Firewall units connected for use with Stateful Failover.
 |
Note All enabled interfaces must be connected between the Active and Standby units. If an interface is not in use, use the shutdown option to the interface command to disable the interface. |
The following provides a summary of Stateful Failover features, configuration, and restrictions:
1. Feature description:
a. What causes a failover?
b. What information is replicated to the Standby PIX Firewall?
c. What information is not replicated to the Standby PIX Firewall:
2. Hardware requirements:
a. Two identical PIX Firewall units with a Fast Ethernet LAN port dedicated to Stateful Failover are required. You must connect the LAN ports for Stateful Failover on both PIX Firewall units with a crossover cable or through a hub or switch. Full duplex is required between the Stateful Failover ports.
b. For better performance, a PIX 520 or later model of PIX Firewall is recommended.
c. You need a failover cable to connect the two failover ports on both PIX Firewall units.
d. Hardware restrictions:
3. Software requirements:
a. PIX Firewall version 5.0 or later is required for Stateful Failover.
b. Both PIX Firewall units have to run the same version of PIX Firewall software.
4. License requirements:
5. Commands for configuring Stateful Failover follow:
failover on failover ip address if_name ip_address failover link if_name
This section includes the following topics:
Follow these steps to configure failover:
Step 2 Install the Secondary unit as described in the Installation Guide for the Cisco Secure PIX Firewall Version 5.1 available in your accessory kit. If you are using Stateful Failover, install both units on 100 Mbps full-duplex LAN interfaces.
Step 3 Connect the failover cable also described in the Installation Guide for the Cisco Secure PIX Firewall Version 5.1.
Step 4 Only configure the Primary unit. When you enter the write memory command to save the configuration to Flash memory, the Primary unit updates the Secondary unit.
The sections that follow describe how to configure the Primary unit.
The two PIX Firewall units must be configured exactly the same and running the same software release. Configuration replication occurs over the failover cable from the Active unit to the Standby unit in three ways:
The configuration replication only occurs from memory to memory. After replication, use the write memory command to write the configuration into Flash memory. Because the failover cable is used, the replication can take a long time to complete with a large configuration. If a switchover occurs during the replication, the new Active unit will have a partial configuration. The unit will reboot itself to recover the configuration from the Flash or re-synchronize with the other unit. When the replication starts, the PIX Firewall console displays the message "Sync Started," and when complete, displays the message "Sync Completed." During the replication, information cannot be entered on the PIX Firewall console.
|
Note Always enter configuration changes on the Active unit. Configuration changes entered on the Standby unit are not saved to the Active unit. Only use the default configuration initially to ensure both units are working correctly. |
The following guidelines apply to configuring failover on the Active unit:
Use the show failover command to verify which unit is active and to provide Stateful Failover information.
If you want to force a PIX Firewall to be active or go to standby, you can use the failover active or no failover active command. Use this feature to force a PIX Firewall offline for maintenance or to return a failed unit to service.
This section includes the following topics:
The following notes apply to the use of failover on the PIX Firewall:
1. Syslog messages indicate whether the Primary unit or Secondary unit failed. Refer to "Failover Syslog Messages" for more information.
2. When a failover cable connects two PIX Firewall units, the no failover command now disables failover until you enter the failover command to explicitly enable failover. Previously, when the failover cable connected two PIX Firewall units and you entered the no failover command, failover would automatically re-enable after 15 seconds.
3. If you are upgrading from a previous version, refer to "Upgrading Failover from Version 4.1 to Version 4.2" and "Upgrading Failover from Version 4.2 to the Current Version" before continuing.
4. On PIX10000 and older PIX Firewall units using version 5.0 when failover is disabled, the following messages may appear during startup and can be ignored:
**** WARNING ***
Configuration Replication is NOT performed from Standby unit to Active unit.
Configurations are no longer synchronized.
5. Stateful Failover does not save state for HTTP Web connections. These connections can re-establish themselves quickly on their own. In addition, RIP state information is not stored, but is re-established within 30 seconds.
6. The Stateful Failover dedicated interface needs to be one of the following:
a. Cat 5 crossover cable directly connecting the Primary unit to the Secondary unit.
b. 100BaseTX half duplex hub using straight Cat 5 cables.
c. 100BaseTX full duplex on a dedicated switch or dedicated VLAN of a switch.
7. Stateful Failover can be used with Token Ring interfaces with a high speed Ethernet Stateful Failover interface connection. You can also use FDDI interfaces with non-Stateful Failover.
8. Because of the increased speed requirements, use of Stateful Failover on Token Ring interfaces or on LANs using VPN is not supported.
9. The PIX Firewall failover Standby unit is intended to be used solely for failover and not in standalone mode. If a failover unit is used in standalone mode, the unit will reboot at least once every 24 hours until the unit is returned to failover duty. When the unit reboots, the following message displays at the console:
=========================NOTICE ==========================
This machine is running in secondary mode without
a connection to an active primary PIX. Please
check your connection to the primary system.
REBOOTING....
==========================================================
10. If a failover-only PIX Firewall is not attached to a failover cable or is attached to the Primary end of a failover cable, then it will hang at boot time. It must be a Secondary unit.
11. Because the PIX Firewall clock is stored in the CMOS, you need do to specify the clock set time command on the Active PIX Firewall to synchronize the time on both PIX Firewall units.
12. In the event of a failover, information on idle TCP connections is not always sent to the Standby unit when using Stateful Failover. This can cause idle TCP connections to be dropped. The information is sent correctly approximately 66% of the time, but approximately 34% of the time it is not.
13. The ACT indicator light on the front of the PIX 515 is on when the unit is the Active failover unit. If failover is not enabled, this light is on. If failover is present, the light is on when the unit is the Active unit and off when the unit is in standby mode.
14. The Cable Status that displays with the show failover command has these values:
a. Normal---Indicates that the Active unit is working and that the Standby unit is ready.
b. Waiting---Indicates that monitoring of the other unit's network interfaces has not yet started.
c. Failed---Indicates that the PIX Firewall has failed.
15. Changes made on the Standby unit are not replicated on the Active unit.
16. Failover works by passing control to the Standby unit should the Active unit fail. For Ethernet, failover detection should occur within 30 seconds. Token Ring requires additional time for failover.
17. Failover works in a switched environment. If the unit is attached to a switch running spanning tree, this will take twice the forward delay time configured in the switch (typically 15 seconds) plus 30 seconds. This is because at bootup (and immediately following a failover event) the network switch will detect a temporary bridge loop.
18. Failover also works with the FDDI interface. Note that Port-B is on the top of the FDDI card, and Port-A is on the bottom.
19. The failover feature causes the PIX Firewall to ARP for itself every 15 seconds. If this adversely affects your ARP table, you can disable it with the no failover command.
20. If failover is disabled, the following messages display when you enter the show failover command:
show failover Failover Off Cable Status: My side not connected Reconnect timeout: 0:00:00
To upgrade failover from version 4.2 to version 4.2, perform the following steps:
|
Note Keep the configuration diskette in a safe place. The PIX Firewall version 4.1 configuration is required if a downgrade is ever necessary. |
Step 2 If failover is running, enter the no failover active command at the Primary unit.
Step 3 Remove the failover and network cables from the Standby unit. Do not remove the console cable.
Step 4 Insert the PIX Firewall version 4.2 diskette into the Standby unit and use the reload command to reboot the unit.
Step 5 After the Standby unit comes up, check the configuration and use the write memory command to store the configuration in Flash memory.
Step 6 Plug the failover and network cables into the Standby unit. Look for link lights on the network interface.
Step 7 On the Standby unit, enter the show interface command to ensure that traffic is moving through the PIX Firewall.
Step 8 Power off the Primary unit to force failover to the Standby unit.
Step 9 Enter the show conn command on the Standby unit to see if traffic is passing through the PIX Firewall.
Step 10 Disconnect the failover and network cables from the Primary unit which is now inactive.
Step 11 Insert the PIX Firewall version 4.2 diskette into the Primary unit.
Step 12 Check the configuration and use the write memory command to store the configuration in Flash memory.
Step 13 Plug in the failover and network cables. Look for link lights on the network interface.
Step 14 On the Primary unit, use the failover active command to restart failover.
Step 15 Enter the show conn command on the Primary unit to see if traffic is passing through the PIX Firewall.
This completes the upgrade procedure.
To upgrade failover from version 4.2 to the current version, perform the following steps:
Step 2 Insert the PIX Firewall version 4.2 diskette into the Primary unit. Enter the reload command at the Primary unit.
Step 3 As the Primary unit reboots, PIX Firewall prompts you to write the diskette to Flash memory. Before entering a reply, read the next three substeps and be ready to move quickly to complete them. When ready, enter y for yes to write the diskette to Flash memory.
a. Immediately remove the diskette from the Primary unit and insert it into the Standby unit. Locate the reset button on the front of the Standby unit.
b. When the PIX Firewall Cisco banner appears on the console, press the reset button on the Standby unit to load the new image.
c. On the Primary unit, enter the show failover command and examine the output.
Step 4 On the Primary unit, observe the link lights on the network interface to determine that the unit is receiving traffic. Once the Standby unit completes its startup, the two units replicate the configuration. During the replication, the Primary console will not receive input.
Step 5 On the Standby unit, use the show failover command to monitor progress. When both PIX Firewall units report Normal, the replication is done.
Step 6 On each unit, enter the write memory command to store the new images in Flash memory.
This completes the upgrade procedure.
This section includes the following topics:
If a failure is due to a condition other than a loss of power on the other unit, failover will begin a series of tests to determine which unit is failed. This series of tests will begin when hello messages are not heard for two consecutive 15-second intervals. Hello messages are sent over both network interfaces and the failover cable.
The purpose of these tests is to generate network traffic in order to determine which (if either) unit has failed. At the start of each test, each unit clears its received packet count for its interfaces. At the conclusion of each test, each unit looks to see if it has received any traffic. If it has, the interface is considered operational. If one unit receives traffic for a test and the other unit does not, the unit that received no traffic is considered failed. If neither unit has received traffic, then go to the next test.
|
Note If the failover IP address has not been set, failover does not work and the Network Activity, ARP, and Broadcast ping tests are not performed. |
Use the following tests for failover:
This section contains some frequently asked questions about the failover feature. Additional questions relating to installation are provided in the Installation Guide for the Cisco Secure PIX Firewall Version 5.1.
Syslog messages will be generated when any errors or switches occur. Evaluate the failed unit and fix or replace it.
Failover messages always have a syslog priority level of 2, which indicates a critical condition. Refer to the logging command description in "Command Reference," for more information on syslog messages. Refer to the System Log Messages for the Cisco Secure PIX Firewall Version 5.1, available online. PIX Firewall documentation is available online at the following site:
http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/index.htm
To receive SNMP syslog traps (SNMP failover traps), you must configure the SNMP agent to send SNMP traps to SNMP management stations, define a syslog host, and also have compiled the Cisco syslog MIB into your SNMP management station. See the snmp-server and logging command pages in "Command Reference," for more information.
In version 5.1, PIX Firewall provides support for Microsoft PPTP, which is an alternative to IPSec handling for VPN Clients. While PPTP is less secure than IPSec, PPTP is easier to implement and maintain.
This section contains the following topics:
The vpdn command implements the PPTP feature for inbound connections between the PIX Firewall and a Windows client. Point-to-Point Tunneling Protocol (PPTP) is a layer 2 tunneling protocol which lets a remote client use a public IP network to communicate securely with servers at a private corporate network. PPTP tunnels the IP protocol. RFC 2637 describes the PPTP protocol.
Version 5.1 supports only inbound PPTP and only one PIX Firewall interface can have the vpdn command enabled.
Supported authentication protocols include: PAP, CHAP, and MS-CHAP using external AAA (RADIUS or TACACS+) servers or the PIX Firewall local username and password database. Through the PPP IPCP protocol negotiation, PIX Firewall assigns a dynamic internal IP address to the PPTP client allocated from a locally defined IP address pool.
PIX Firewall PPTP VPN supports standard PPP CCP negotiations with Microsoft Point-To-Point Encryption (MPPE) extensions using RSA/RC4 algorithm. MPPE currently supports 40-bit and 128-bit session keys. MPPE generates an initial key during user authentication and refreshes the key regularly. In this release, compression is not supported.
When you specify MPPE, you must use the MS-CHAP PPP authentication protocol. If you are using an external AAA server, the protocol must be RADIUS and the external RADIUS server must be able to return the Microsoft MSCHAP_MPPE_KEY attribute to the PIX Firewall in the RADIUS Authentication Accept packet. See RFC-2548, "Microsoft Vendor Specific RADIUS Attributes," for more information on the MSCHAP_MPPE_KEY attribute.
Currently, Cisco has only tested the Steel-Belted RADIUS server from Funk Software as a server able to return the MSCHAP_MPPE_KEYS attribute.
PIX Firewall PPTP VPN has been tested with the following Microsoft Windows products: Windows 95 with DUN1.3, Windows 98, Windows NT 4.0 with SP6, and Windows 2000 Beta.
Use the vpdn command with the sysopt connection permit-pptp command to allow PPTP traffic to bypass checking of access-list command statements.
The show vpdn command lists tunnel and session information.
The clear vpdn command removes all vpdn commands from the configurations and stops all the active PPTP tunnels. The clear vpdn all command lets you remove all tunnels, and the clear vpdn id tunnel_id command lets you remove tunnels associated with tunnel_id. (You can view the tunnel_id with the show vpdn command.)
The clear vpdn group command removes all the vpdn group commands from the configuration. The clear vpdn username command removes all the vpdn username commands from the configuration. The clear vpdn command removes all vpdn commands from the configuration.
You can troubleshoot PPTP traffic with the debug ppp and debug vpdn commands.
The following example shows a simple configuration, which lets a Windows PPTP client dial in without any authentication (not recommended). Refer to the vpdn command page in "Command Reference," for more examples and descriptions of the vpdn commands and the command syntax.
The ip local pool command specifies the IP addresses assigned to each VPN Client as they log in to the network. The Windows client can Telnet to host 192.168.0.2 through the global IP address 209.165.201.2 in the static command statement. The access-list command statement permits Telnet access to the host.
ip local pool my-addr-pool 10.1.1.1-10.1.1.254 vpdn group 1 accept dialin pptp vpdn group 1 client configuration address local my-addr-pool vpdn enable outside static (inside, outside) 209.165.201.2 192.168.0.2 netmask 255.255.255.255 access-list acl_out permit tcp any host 209.165.201.2 eq telnet access-group acl_out in interface outside
ActiveX controls, formerly known as OLE or OCX controls, are components you can insert in a web page or other application. These controls include custom forms, calendars, or any of the extensive third-party forms for gathering or displaying information. As a technology, ActiveX creates many potential problems for the network clients including causing workstations to fail, introducing network security problems, or being used to attack servers.
The PIX Firewall ActiveX feature blocks the HTML <object> commands by commenting them out within the HTML web page. This functionality has been added to the filter command with the activex option.
|
Note The <object> tag is also used for Java applets, image files, and multimedia objects, which will also be blocked by the new command. |
|
Note If the <object> or </object> HTML tags split across network packets or if the code in the tags is longer than the number of bytes in the MTU, PIX Firewall cannot block the tag. |
If your network has a Websense server on any network interface, you can provide URL filtering through the PIX Firewall.
Follow these steps to configure the PIX Firewall to use Websense:
url-server (dmz) host 192.168.1.42 timeout 10
In this example, the Websense host is on the dmz interface at IP address 192.168.1.42. A timeout value of 10 seconds is specified as maximum allowed idle time before the PIX Firewall switches to the next Websense server.
Step 2 Use the filter url http command to tell the PIX Firewall how to filter requests. For example, to filter requests for all hosts, use the following command:
filter url http 0 0 0 0 allow
|
Note The allow option in the filter command is crucial to the use of PIX Firewall URL filtering feature. If you use the allow option and the Websense server goes offline, the PIX Firewall lets all Web requests continue without filtering. If the allow option is not specified, all port 80 Web requests are stopped until the server is back online. |
Step 3 If you want to disable URL filtering, use the no filter url command.
This section includes the following topics:
You can log FTP commands and WWW URLs when syslog is enabled. FTP and URL messages are logged at syslog level 7. User names are provided in the log information.
In version 5.1, both inbound and outbound FTP commands and URLs are sent to syslog.
Refer to the section "Step 16 - Enable Syslog" in "Configuring the PIX Firewall," for more information on how to view syslog messages on a server, console session, or via Telnet to the console.
Use the show fixup command to ensure that the following fixup protocol commands for FTP and HTTP are present in the configuration:
fixup protocol http 80 fixup protocol ftp 21
These commands are in the default configuration.
The sections that follow provide sample output displays for each logging type.
The following is an example of a URL logging syslog message:
192.168.69.71 accessed URL 10.0.0.1/secrets.gif
The following are examples of FTP logging syslog messages:
192.168.69.42 Retrieved 10.0.0.42:feathers.tar 192.168.42.54 Stored 10.0.42.69:privacy.zip
You can view these messages at the PIX Firewall console with the show logging command.
The snmp-server command causes the PIX Firewall to send SNMP traps so that the firewall can be monitored remotely. Use snmp-server host command to specify which systems receive the SNMP traps.
This section includes the following topics:
The PIX Firewall SNMP MIB-II groups available are System and Interfaces. Version 5.1 makes the Cisco Firewall MIB and Cisco Memory Pool MIB available.
All SNMP values are read only (RO).
Using SNMP, you can monitor system events on the PIX Firewall. SNMP events can be read, but information on the PIX Firewall cannot be changed with SNMP.
The PIX Firewall SNMP traps available to an SNMP management station are as follows:
Use CiscoWorks for Windows or any other SNMP V1, MIB-II compliant browser to receive SNMP traps and browse a MIB. SNMP traps occur at UDP port 162.
|
Note The PIX Firewall does not support browsing of the Cisco syslog MIB. |
You can browse the System and Interface groups of MIB-II. Browsing a MIB is different from sending traps. Browsing means doing an snmpget or snmpwalk of the MIB tree from the management station to determine values.
In version 5.1, the Cisco Firewall MIB and Cisco Memory Pool MIB are available.
PIX Firewall does not support the following in the Cisco Firewall MIB:
1. The MIB-II ifEntry.ifAdminStatus object returns 1 if the interface is accessible and 2 if you administratively shut down the interface using the shutdown option of the interface command.
2. The SNMP "ifOutUcastPkts" object now correctly returns the outbound packet count.
3. Syslog messages generated by the SNMP module now specify the interface name instead of an interface number.
Traps are different than browsing; they are unsolicited "comments" from the managed device to the management station for certain events, such as link up, link down, syslog event generated, and so on.
Two mechanisms work with SNMP, PIX Firewall responds to an SNMP request from a management station and the PIX Firewall sends a trap, which is an event notification. PIX Firewall supports two types of traps, generic and syslog traps.
Follow these steps to receive requests and send traps from the PIX Firewall to an SNMP management station:
Step 2 Set the snmp-server options for location, contact, and the community password as required.
If you only want to send the cold start, link up, and link down generic traps, no further configuration is required.
If you only want to receive SNMP requests, no further configuration is required.
Step 3 Add an snmp-server enable traps command statement.
Step 4 Set the logging level with the logging history command; for example:
logging history debugging
Cisco recommends that you use the debugging level during initial set up and during testing. Thereafter, set the level from debugging to a lower value for production use.
(The logging history command sets the severity level for SNMP syslog messages. This command is new in version 5.1.)
Step 5 Start sending syslog traps to the management station with the logging on command.
Step 6 To disable sending syslog traps, use the no logging on command or the no snmp-server enable traps command.
To receive security and failover SNMP traps from the PIX Firewall, compile the Cisco SMI MIB and the Cisco syslog MIB into your SNMP management application. If you do not compile the Cisco syslog MIB into your application, you only receive MIB-II traps for link up or down, and firewall cold start.
You can get the Cisco MIB files on the Web from the following sites:
To compile Cisco syslog MIB files into your browser using CiscoWorks for Windows (SNMPc), complete the following steps:
Step 2 Start SNMPc.
Step 3 Click Config>Compile MIB.
Step 4 Scroll to the bottom of the list, and click the last entry.
Step 5 Click Add.
Step 6 Find the file CISCO-FIREWALL-MIB.my and click OK.
Step 7 Scroll to the bottom of the list, and click the last entry.
Step 8 Click Add.
Step 9 Find the file CISCO-MEMORY-POOL-MIB.my and click OK.
Step 10 Scroll to the bottom of the list, and click the last entry.
Step 11 Click Add.
Step 12 Find the file CISCO-SMI.my and click OK.
Step 13 Scroll to the bottom of the list, and click the last entry.
Step 14 Click Add.
Step 15 Find the file CISCO-SYSLOG-MIB.my and click OK.
Step 16 Click Load All.
Step 17 If there are no errors, restart SNMPc.
These instructions are only for SNMPc (CiscoWorks for Windows).
The Cisco Firewall and Memory Pool MIBs let you poll failover and system status.
This section contains the following topics:
In the tables that follow in each section, the meaning of each returned value is shown in parentheses.
The SNMP failover status lets you determine whether failover is enabled and which unit is active. The Cisco Firewall MIB indicates failover status by two rows in the cfwHardwareStatusTable object. From the PIX Firewall command line, you can view failover status with the show failover command. You can access the object table from the following path:
.iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoFirewallMIB. ciscoFirewallMIBObjects.cfwSystem.cfwStatus.cfwHardwareStatusTable
Table 3-1 lists which objects provide failover information.
| Object | Object Type | Row 1: Returned if Failover is Disabled | Row 1: Returned if Failover is Enabled | Row 2: Returned if Failover is Enabled |
|---|---|---|---|---|
cfwHardwareType | Hardware | 6 (If Primary unit) | 6 (If Primary unit) | 7 (If Secondary unit) |
cfwHardwareInformation | SnmpAdminString | blank | blank | blank |
cfwHardwareStatusValue | HardwareStatus | 0 (Not used) | active or 9 (If Active unit) or standby or 10 (If Standby unit) | active or 9 (If Active unit) or standby or 10 (If Standby unit) |
cfwHardwareStatusDetail | SnmpAdminString | Failover Off | blank | blank |
In the HP OpenView Browse MIB application's "MIB values" window, if failover is disabled, a sample MIB query yields the following information:
cfwHardwareInformation.6 : cfwHardwareInformation.7 : cfwHardwareStatusValue.6 :0 cfwHardwareStatusValue.7 :0 cfwHardwareStatusDetail.6 :Failover Off cfwHardwareStatusDetail.7 :Failover Off
From this listing, the table index, cfwHardwareType, appears as either .6 or .7 appended to the end of each of the subsequent objects. The cfwHardwareInformation field is blank, the cfwHardwareStatusValue is 0, and the cfwHardwareStatusDetail contains Failover Off, which indicates the failover status.
When failover is enabled, a sample MIB query yields the following information:
cfwHardwareInformation.6 : cfwHardwareInformation.7 : cfwHardwareStatusValue.6 : active cfwHardwareStatusValue.7 : standby cfwHardwareStatusDetail.6 : cfwHardwareStatusDetail.7 :
In this listing, only the cfwHardwareStatusValue contains values, either active or standby to indicate the status of each unit.
You can determine how much free memory is available with one row in the Cisco Memory Pool MIB. From the PIX Firewall command line, memory usage is viewed with the show memory command. The following is the sample output from the show memory command:
show memory 16777216 bytes total, 5595136 bytes free
You can access the MIB objects from the following path:
.iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoMemoryPoolMIB. ciscoMemoryPoolObjects.ciscoMemoryPoolTable
Table 3-2 lists which objects provide memory usage information.
| Object | Object Type | Returned Value |
|---|---|---|
ciscoMemoryPoolType | CiscoMemoryPoolTypes | 1 (Processor memory) |
ciscoMemoryPoolName | DisplayString | PIX system memory |
ciscoMemoryPoolAlternate | Integer32 | 0 (No alternate memory pool) |
ciscoMemoryPoolValid | TruthValue | true (Means that the values of the remaining objects are valid) |
ciscoMemoryPoolUsed | Gauge32 | integer (Number of bytes currently in use---the total bytes minus the free bytes) |
ciscoMemoryPoolFree | Gauge32 | integer (Number of bytes currently free) |
ciscoMemoryPoolLargestFree | Gauge32 | 0 (Information not available) |
In the HP OpenView Browse MIB application's "MIB values" window a sample MIB query yields the following information:
ciscoMemoryPoolName.1 :PIX system memory ciscoMemoryPoolAlternate.1 :0 ciscoMemoryPoolValid.1 :true ciscoMemoryPoolUsed.1 :12312576 ciscoMemoryPoolFree.1 :54796288 ciscoMemoryPoolLargestFree.1 :0
From this listing, the table index, ciscoMemoryPoolName, appears as the .1 value at the end of each subsequent object value. The ciscoMemoryPoolUsed object lists the number of bytes currently in use, 12312576, and the ciscoMemoryPoolFree object lists the number of bytes currently free 54796288. The other objects always list the values described in Table 3-2.
You can view the number of connections in use from the two rows in the cfwConnectionStatTable in the Cisco Firewall MIB. From the PIX Firewall command line, you can view the connection count with the show conn command. The following sample output is for the show conn command:
show conn 15 in use, 88 most used
The cfwConnectionStatTable object table can be accessed from the following path:
.iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoFirewallMIB. ciscoFirewallMIBObjects.cfwSystem.cfwStatistics.cfwConnectionStatTable
Table 3-3 lists which objects provide connection count information.
| Object | Object Type | Row 1: Returned Value | Row 2: Returned Value |
|---|---|---|---|
cfwConnectionStatService | Services | 40 (IP protocol) | 40 (IP protocol) |
cfwConnectionStatType | ConnectionStat | 6 (Current connections in use) | 7 (High) |
cfwConnectionStatDescription | SnmpAdminString | number of connections currently in use by the entire firewall | highest number of connections in use at any one time since system startup |
cfwConnectionStatCount | Counter32 | 0 (Not used) | 0 (Not used) |
cfwConnectionStatValue | Gauge32 | integer (In use number) | integer (Most used number) |
In the HP OpenView Browse MIB application's "MIB values" window a sample MIB query yields the following information:
cfwConnectionStatDescription.40.6 :number of connections currently in use by the entire firewall cfwConnectionStatDescription.40.7 :highest number of connections in use at any one time since system startup cfwConnectionStatCount.40.6 :0 cfwConnectionStatCount.40.7 :0 cfwConnectionStatValue.40.6 :15 cfwConnectionStatValue.40.7 :88
From this listing, the table index, cfwConnectionStatService, appears as the .40 appended to each subsequent object and the table index, cfwConnectionStatType, appears as either .6 to indicate the number of connections in use or .7 to indicate the most used number of connections. The cfwConnectionStatValue object then lists the connection count. The cfwConnectionStatCount object always returns 0 (zero).
The system buffer usage provides an early warning of the PIX Firewall reaching the limit of its capacity. On the command line, you can view this information with the show blocks command. The following is the sample output for the show blocks command:
show blocks
You can view the system buffer usage from the Cisco Firewall MIB in multiple rows of the cfwBufferStatsTable. You can view this object table at the following path:
.iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoFirewallMIB. ciscoFirewallMIBObjects.cfwSystem.cfwStatistics.cfwBufferStatsTable
Table 3-4 lists the objects required to view the system block usage.
| Object | Object Type | First Row: Returned Value | Next Row: Returned Value | Next Row: Returned Value |
|---|---|---|---|---|
cfwBufferStatSize | Unsigned32 | integer (SIZE value; for example, 4 for a 4-byte block) | integer (SIZE value; for example, 4 for a 4-byte block) | integer (SIZE value; for example, 4 for a 4-byte block) |
cfwBufferStatType | ResourceStatistics | 3 (MAX) | 5 (LOW) | 8 (CNT) |
cfwBufferStatInformation | SnmpAdminString | maximum number of allocated integer byte blocks (integer is the number of bytes in a block) | fewest integer byte blocks available since system startup (integer is the number of bytes in a block) | current number of available integer byte blocks (integer is the number of bytes in a block) |
cfwBufferStatValue | Gauge32 | integer (MAX number) | integer (LOW number) | integer (CNT number) |
|
Note The three rows repeat for every block size listed in the output of the show blocks command. |
In the HP OpenView Browse MIB application's "MIB values" window a sample MIB query yields the following information:
cfwBufferStatInformation.4.3 :maximum number of allocated 4 byte blocks cfwBufferStatInformation.4.5 :fewest 4 byte blocks available since system startup cfwBufferStatInformation.4.8 :current number of available 4 byte blocks cfwBufferStatInformation.80.3 :maximum number of allocated 80 byte blocks cfwBufferStatInformation.80.5 fewest 80 byte blocks available since system startup cfwBufferStatInformation.80.8 :current number of available 80 byte blocks cfwBufferStatInformation.256.3 :maximum number of allocated 256 byte blocks cfwBufferStatInformation.256.5 :fewest 256 byte blocks available since system startup cfwBufferStatInformation.256.8 :current number of available 256 byte blocks cfwBufferStatInformation.1550.3 :maximum number of allocated 1550 byte blocks cfwBufferStatInformation.1550.5 :fewest 1550 byte blocks available since system startup cfwBufferStatInformation.1550.8 :current number of available 1550 byte blocks cfwBufferStatValue.4.3: 1600 cfwBufferStatValue.4.5: 1600 cfwBufferStatValue.4.8: 1600 cfwBufferStatValue.80.3: 400 cfwBufferStatValue.80.5: 396 cfwBufferStatValue.80.8: 400 cfwBufferStatValue.256.3: 1000 cfwBufferStatValue.256.5: 997 cfwBufferStatValue.256.8: 999 cfwBufferStatValue.1550.3: 1444 cfwBufferStatValue.1550.5: 928 cfwBufferStatValue.1550.8: 932
From this listing, the first table index, cfwBufferStatSize, appears as first number appended to the end of each object, such as .4 or .256. The other table index, cfwBufferStatType, appears as .3, .5, or .8 after the first index. For each block size, the cfwBufferStatInformation object identifies the type of value and the cfwBufferStatValue object identifies the number of bytes for each value.
Private Link is no longer supported in the PIX Firewall starting with version 5.0. It is supported in version 4. The Private Link feature allows Virtual Private Networks (VPNs) to be established between PIX Firewall sites connected to the same public (or outside) network. It enables incoming Private Link packets to bypass the NAT and ASA features and terminate on the corresponding sending interface on the destination network. A sending interface is the interface from which the IPSec packet was sent from. For example, IPSec packets sent from a perimeter interface from one network would be terminated at the equivalent perimeter interface at the destination network. With the use of the sysopt ipsec pl-compatible command, the IPSec feature simulates the Private Link feature by allowing IPSec packets to also bypass the NAT and ASA features and terminate on the sending interface. See the sysopt command page for more information regarding the sysopt ipsec pl-compatible command.
This section contains the following topics:
While IPSec is a much larger feature set than Private Link, the two feature sets do not have a complete parent-child inheritance relationship. The main difference between Private Link and IPSec is that a Private Link tunnel begins on the receiving interface and ends on the sending interface while an IPSec tunnel begins on the sending interface and terminates on the receiving interface.
This section contains the following topics:
Table 3-5 outlines the mapping of the core Private Link commands with the corresponding IPSec commands. A description of each command follows.
| Private Link Commands | IPSec Commands |
|---|---|
- | sysopt ipsec pl-compatible |
link (inside) remote_peer_ip key_id key
| 1. isakmp policy priority authentication pre-share 2. isakmp key keystring address peer-address 3. crypto map map-name interface interface-name |
link remote_peer_ip md5 | 1. crypto ipsec transform-set transform-set-name esp-des ah-md5-hmac 2. crypto map map-name seq-num set transform-set transform-set-name |
linkpath remote_network_ip remote_netmask remote_peer_ip | 1. access-list access-list-name permit ip any remote_network_ip remote_netmask 2. crypto map map-name seq-num match address access-list-name 3. crypto map map-name seq-num set peer ip-address |
age minutes | crypto ipsec security-association lifetime seconds seconds |
For more information about the IPSec related commands listed in Table 3-5, see "Command Reference," under the following command pages:
|
Note Private Link uses up to seven shared keys between two hosts and rotates among the seven keys. ISAKMP uses only one shared key between any two hosts to authenticate and dynamically negotiate other keys to protect the communication as necessary. |
The link command allows for the configuration of per packet authentication protection. In IPSec, the analogous protection is provided by the transform-set combination of ah-md5-hmac or esp-md5-hmac. You configure a transform set using the crypto ipsec transform-set command.
In IPSec, the access-list command statement address selectors in the crypto map are used to select outbound traffic from the interface to encrypt and tunnel to the remote peer. In the reverse direction, the access-list command statement address selectors are used to decrypt inbound traffic, which originated from the remote peer, at the outside interface.
The following are the steps to use to convert from a linkpath tunnel into an IPSec tunnel. These steps are included within the Private Link to IPSec configuration conversion procedure.
Step 2 Associate the defined access-list command statement with a crypto map entry. (Step 7 in the "Conversion" section.)
Step 3 Associate the linkpath remote peer as the crypto map peer. (Step 10 in the "Conversion" section.)
In IPSec, the crypto ipsec security-association lifetime second command is used to define how long the current shared key and the security association are used before their set time expires.
Covered in this section are the steps to convert your Private Link configuration into an IPSec configuration. An example of a Private Link configuration between two PIX Firewalls is provided for reference.
Figure 3-2 shows the Private Link network diagram that corresponds to the following configurations.
On PIX Firewall A, the Private Link configuration is:
link 192.168.37.1 1 fadebacfadebac
link 192.168.37.1 2 bacfadefadebac
link 192.168.37.1 3 baabaaafadebac
link 192.168.37.1 4 beebeeefadebac
linkpath 10.3.0.0 255.255.255.0 192.168.37.1
On PIX Firewall B, the Private Link configuration is:
link 192.168.35.1 1 fadebacfadebac
link 192.168.35.1 2 bacfadefadebac
link 192.168.35.1 3 baabaaafadebac
link 192.168.35.1 4 beebeeefadebac
linkpath 10.1.0.0 255.255.255.0 192.168.35.1
In this configuration, the link command specifies 192.168.35.1 as the external network interface IP address of PIX Firewall B, and 192.168.37.1 as the external network interface IP address of PIX Firewall A. The key IDs are 1 through 4. The four keys to be shared between the two PIX firewall units are fadebacfadebac, bacfadefadebac, baabaaafadebac, and beebeeefadebac.
The linkpath command identifies the internal and external network interfaces belonging to the remote peer. So on the PIX Firewall A, PIX Firewall B's internal network interface IP address of 10.3.0.0 with a netmask of 255.255.255.0 and its external network interface IP address of 192.168.37.1 is set. On PIX Firewall B, PIX Firewall A's internal network interface IP address of 10.1.0.0 with a netmask of 255.255.255.0 and its external network interface IP address of 192.168.35.1 is set.
Follow these steps to convert your Private Link configuration into an IPSec configuration where IKE is used to establish security associations,. Perform your configuration on each PIX Firewall:
PIX Firewall A:
sysopt ipsec pl-compatible
PIX Firewall B:
sysopt ipsec pl-compatible
Step 2 Specify that a pre-shared key will be used between PIX Firewall A and PIX Firewall B for authentication:
PIX Firewall A:
isakmp policy 10 authentication pre-share
PIX Firewall B:
isakmp policy 10 authentication pre-share
Step 3 Specify a pre-shared key that PIX Firewall A and PIX Firewall B will share. For example:
PIX Firewall A:
isakmp key fadebacfadebac address 192.168.37.1
PIX Firewall B:
isakmp key fadebacfadebac address 192.168.35.1
Step 4 Define a crypto map entry that uses IKE to establish security associations. For example:
PIX Firewall A:
crypto map Firewall-A 10 ipsec-isakmp
PIX Firewall B:
crypto map Firewall-B 10 ipsec-isakmp
Step 5 Apply the crypto map set to the interface through which IPSec traffic will flow. For example:
PIX Firewall A:
crypto map Firewall-A interface outside
PIX Firewall B:
crypto map Firewall-B interface outside
Step 6 Create an access list to define the traffic to protect. Use the same address selectors used in your linkpath statement. For example:
PIX Firewall A:
access-list linkpath-aclA permit ip any 10.3.0.0 255.255.255.0
PIX Firewall B:
access-list linkpath-aclB permit ip any 10.1.0.0 255.255.255.0
Step 7 Assign the access list to the crypto map entry you defined. For example:
PIX Firewall A:
crypto map Firewall-A 10 match address linkpath-aclA
PIX Firewall B:
crypto map Firewall-B 10 match address linkpath-aclB
Step 8 Configure the transform set that defines how the traffic will be protected. Use either esp-des ah-md5-hmac or esp-md5-hmac. Either one provides the analogous Private Link standard encryption and authentication protection. For example:
PIX Firewall A:
crypto ipsec transform-set private-link-base esp-des ah-md5-hmac
PIX Firewall B:
crypto ipsec transform-set private-link-base esp-des ah-md5-hmac
Step 9 Specify the transform set to be used with the crypto map entry. For example:
PIX Firewall A:
crypto map Firewall-A 10 set transform-set private-link-base
PIX Firewall B:
crypto map Firewall-B 10 set transform-set private-link-base
Step 10 Specify the remote peer to which the IPSec protected traffic can be forwarded. Specify the remote peer specified in your linkpath statement. For example:
PIX Firewall A:
crypto map Firewall-A 10 set peer 192.168.37.1
PIX Firewall B:
crypto map Firewall-B 10 set peer 192.168.35.1
Step 11 Apply the crypto map set to an interface through which IPSec traffic will flow.
For example:
PIX Firewall A:
crypto map Firewall-A interface outside
PIX Firewall B:
crypto map Firewall-B interface outside
See the telnet command page within "Command Reference." for more information about this command.
|
Note You will need to have two security policies set up on your Cisco Secure VPN Client. One security policy is used to secure your Telnet connection and another to secure your connection to the inside network. |
To encrypt your Telnet connection to the PIX Firewall's outside interface, perform the following steps as part of your PIX Firewall configuration. In the following examples, the IP address of the PIX Firewall's outside interface is 168.20.1.5, and the Cisco Secure VPN Client's IP address stemming from the virtual pool of addresses is 10.1.2.0.
access-list 80 permit ip host 168.20.1.5 10.1.2.0 255.255.255.0
Step 2 Specify which host can access the PIX Firewall console with Telnet. Specify the VPN Client's address from the local pool and the outside interface:
telnet 10.1.2.0 255.255.255.0 outside
Step 3 Within the VPN Client, create a security policy that specifies the Remote Party Identity IP address and gateway IP address as the same IP address--the IP address of the PIX Firewall's outside interface. In this example, the IP address of the PIX Firewall's outside is 168.20.1.5.
Step 4 Configure the rest of the security policy on the VPN Client to match the PIX Firewall's security policy.
Posted: Sun May 21 18:01:22 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.