|
|
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:
With version 5.0, 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.
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:
Stateful Failover requires a feature-based license key with failover feature support or connection based license key.
5. Commands for configuring Stateful Failover:
failover on failover ip address if_name ip_address failover link if_name
This section includes the following topics:
To configure failover:
Step 1 If you have a PIX 515, obtain a PIX-515-UR feature license key that lets you add the failover option. Then purchase the failover option, which includes the Secondary unit. If you have a PIX 520 or older model, purchase a second unit with the same connection license as the Primary unit.
Step 2 Install the Secondary unit as described in the Installation Guide for the Cisco Secure PIX Firewall Version 5.0 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.0.
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.
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.
The failover timeout command lets you specify the length of time during which, if a failover occurs, the Standby unit lets connections started with the static command and the norandomseq option pass through the PIX Firewall without requiring a prior xlate to exist. This feature handles long-life connections during failover without requiring the connection to be reestablished.
The syntax for the failover command is:
failover timeout hh:mm:ssIf the hh:mm:ss is specified as -1, the length of time is indefinite.
AAA and user authentication connections are not supported by this feature.
When a stateless TCP connection is created, the following message is sent to syslog:
302009: Rebuilt TCP connection conn# for faddr foreign_ip/fport gaddr global_ip/gport laddr local_ip/lport
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. If you are upgrading from a previous version, refer to "Upgrading from PIX Firewall Version 4.1 to Version 4.2" and "Upgrading from PIX Firewall Version 4.2(1) to the Current Version" before continuing.
3. 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.
4. 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.
5. Changes made on the Standby unit are not replicated on the Active unit.
6. 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.
7. 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.
When this bridge loop is detected, the switch will stop forwarding packets for the duration of the forwarding delay time. It will then enter "listen" mode for an additional forward delay time during which time the switch is listening for bridge loops but still not forwarding traffic (and thus not forwarding failover hello packets). After twice the forward delay time (30 seconds) traffic should resume. The PIX Firewall will remain in "waiting" mode until it hears two hello packets (1 every 15 seconds for a total of 30 seconds). During this time the PIX Firewall passes traffic, and will not fail the unit if it does not hear the hello packets. All other failover monitoring is still occurring (power, interface, and failover cable hello).
8. 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.
9. 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.
10. If failover is disabled, the following messages display:
show failover Failover Off Cable Status: My side not connected Reconnect timeout: 0:00:00
Step 1 Connect a separate console to the Primary unit and one to the Secondary unit.
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.
Step 1 Save the PIX Firewall version 4.1 configuration to a blank DOS-formatted diskette; write-protect, and label it.
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.
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.
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.0.
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.0, available online. PIX Firewall documentation is available online at:
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.
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.
If your network has a WebSENSE server on any network interface, you can provide URL filtering through the PIX Firewall.
To configure the PIX Firewall to use WebSENSE:
Step 1 Specify the interface and IP address of the WebSENSE server with the url-sever command as shown in this example:
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:
filter url http 0 0 0 0 allow
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. As of version 5.0, usernames are provided in the log information.
Refer to the section "Step 15 - 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 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.
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:
Use CiscoWorks for Windows (Product Number CWPC-2.0-WIN) or any other SNMP V1, MIB-II compliant browser to receive SNMP traps and browse a MIB. SNMP traps occur at UDP port 162.
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.
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 state and the PIX Firewall sends a trap, which is an event notification. PIX Firewall supports two types of traps, generic and syslog traps.
The topics that follow include:
For the PIX Firewall to receive requests from an SNMP management station:
Step 1 Identify the IP address of the SNMP management station with the snmp-server host command.
Step 2 Set the snmp-server options for location, contact, and the community password as required.
To send traps from the PIX Firewall to an SNMP management station:
Step 1 If not performed already, configure both steps described in "Receiving Requests."
If you only want to send the cold start, link up, and link down generic traps, no further configuration is required.
Step 2 Add an snmp-server enable traps command statement.
Step 3 Set the logging level with the logging trap command; for example:
logging trap 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.
Step 4 Start sending syslog traps to the management station with the logging on command.
Step 5 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:
http://www.cisco.com/public/mibs/v2/CISCO-SYSLOG-MIB.my
http://www.cisco.com/public/mibs/v2/CISCO-SMI.my
To compile Cisco syslog MIB files into your browser using CiscoWorks for Windows (SNMPc), complete the following steps:
Step 1 Get the Cisco syslog MIB files.
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-SMI.my and click OK.
Step 7 Scroll to the bottom of the list, and click the last entry.
Step 8 Click Add again.
Step 9 Find the file CISCO-SYSLOG-MIB.my and click OK.
Step 10 Click Load All.
Step 11 If there are no errors, restart SNMPc.
These instructions are only for SNMPc (CiscoWorks for Windows).
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 inside interface. 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 inside interface. See the sysopt command page for more information regarding the sysopt ipsec pl-compatible command.
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.
Table 3-1 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 , see "Command Reference," under the following command pages:
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 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 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 1 Define an access-list that has the same address selectors as your linkpath statement. (Step 7 in the conversion procedure.)
Step 2 Associate the defined access-list with a crypto map entry. (Step 8 in the conversion procedure.)
Step 3 Associate the linkpath remote peer as the crypto map peer. (Step 11 in the conversion procedure.)
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.
Step 1 Enable inside termination., For example:
PIX Firewall A:
sysopt ipsec pl-compatible
PIX Firewall B:
sysopt ipsec pl-compatible
Step 2 Explicitly list all routes. For example:
PIX Firewall A:
: connected routes
route inside 10.1.0.0 255.255.0.0 10.1.1.1
route outside 192.168.35.0 255.255.255.0 192.168.35.1
: nat routes
route inside 192.168.35.8 255.255.255.248 10.1.1.1
route inside 192.168.35.16 255.255.255.248 10.1.1.1
: reachability routes
route outside 10.3.0.0 255.255.0.0 192.168.35.2
route outside 192.168.37.0 255.255.255.0 192.168.35.2
route outside 0 0 192.168.35.2
PIX Firewall B:
: connected routes
route inside 10.3.0.0 255.255.0.0 10.3.1.1
route outside 192.168.37.0 255.255.255.0 192.168.37.1
: nat routes
route inside 192.168.37.8 255.255.255.268 10.3.1.1
route inside 192.168.37.16 255.255.255.268 10.3.1.1
: reachability routes
route outside 10.1.0.0 255.255.0.0 192.168.37.2
route outside 192.168.35.0 255.255.255.0 192.168.37.2
route outside 0 0 192.168.37.2
Step 3 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 4 Specify a pre-shared key that PIX Firewall A and PIX Firewall B will share. For example:
PIX Firewall A:
isakmp key fadebacfadebac adddress 192.168.37.1
PIX Firewall B:
isakmp key fadebacfadebac address 192.168.35.1
Step 5 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 6 Apply the crypto map set to the outside interface. For example:
PIX Firewall A:
crypto map Firewall-A interface outside
PIX Firewall B:
crypto map Firewall-B interface outside
Step 7 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 8 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 9 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 10 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 11 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 12 Apply the crypto map set to the outside interface. For example:
PIX Firewall A:
crypto map Firewall-A interface outside
PIX Firewall B:
crypto map Firewall-B interface outside
Posted: Thu Nov 11 19:39:26 PST 1999
Copyright 1989-1999©Cisco Systems Inc.