-
Using Management Center for Firewalls 1.3
-
Preface
-
Getting Started with Firewall MC
-
Task Flow Checklists
-
Preparing the Firewall MC Environment
-
Managing Activities
-
Preparing Your Firewall Devices
-
Creating an Inheritance and Grouping Strategy
-
Representing Network Assets in Firewall MC
-
Configuring Device-Level Settings
-
Configuring Routing Rules
-
Defining Your Policy Building Blocks
-
Configuring Access Rules
-
Configuring Translation Rules
-
Defining Rules Manually Using CLI Syntax
-
Generating and Verifying Configuration Files
-
Deploying Configuration Files
-
Monitoring and Reporting
-
Configuring VPN Settings
-
Configuring Failover
-
Maintaining Your Firewall MC Server
-
Troubleshooting
-
Understanding User Roles and Permissions
-
Index
-
Table Of Contents
Understanding IPSec Tunnel Templates
Understanding IKE Tunnels Templates
Understanding the Default Tunnel Templates
Important Notes about IPSec Support in Firewall MC 1.3
Configuring Site-to-Site Tunnels
Configuring Easy VPN Management
Configuring VPN System Options
Configuring VPN Settings
You can use Firewall MC to configure and manage the IPSec features of Cisco PIX Firewalls. IPSec is a framework of open standards developed by the Internet Engineering Task Force (IETF). It provides security for transmission of sensitive information over unprotected networks such as the Internet. IPSec acts at the network layer, protecting and authenticating IP packets between participating IPSec devices ("peers"), such as Cisco routers.
IPSec provides the following network security services. These services are optional. In general, local security policy will dictate the use of one or more of these services:
•
Data Confidentiality—The IPSec sender can encrypt packets before transmitting them across a network.
•
•
•
With IPSec, data can be transmitted across a public network without fear of observation, modification, or spoofing. This enables applications such as virtual private networks (VPNs), including intranets, extranets, and remote user access.
This section provides an overview of IPSec, and describes the concepts and protocols used to create Virtual Private Networks (VPNs).
Topics to be discussed are:
•
•
•
•
IPSec Tunnels
You can use Firewall MC to configure and manage the IPSec features of Cisco PIX Firewalls. IPSec is a suite of protocols that seamlessly integrates security features, such as authentication, integrity, and confidentiality, into IP. Using the IPSec protocols, you can create an encrypted or authenticated communication path between two peers (endpoints), allowing IP traffic to safely cross public or untrusted networks.
The level of protection provided by the IPSec tunnel depends on the protocols used to form the tunnel. IPSec tunnels based on the Authentication Header (AH) protocol provide data integrity, data source authentication, and protection against replay attacks. IPSec tunnels based on the Encapsulating Security Payload (ESP) protocol can also provide data confidentiality in addition to data integrity, data source authentication, and protection against replay attacks.
You can apply both the AH and the ESP protocols to the data being protected, but with IPSec tunnels based on ESP, that is not always necessary. ESP provides an authentication algorithm, called the authenticator, which can be used for data source authentication. The authenticator, however, can be set to null, in which case, the ESP protocol does not provide data source authentication.
You can use Firewall MC to configure and manage IPSec tunnels in two basic configurations:
•
•
You can also use Firewall MC to configure some of the more advanced options of IPSec implemented in Cisco devices, such as tunnel failover. Additionally, Firewall MC facilitates the management of pre-shared keys (also known as pre-shared secrets) used during the negotiation of Internet Key Exchange (IKE) IPSec tunnels.
How Firewall MC Manages IPSec
You can configure and manage IPSec with Firewall MC from four main areas of the Firewall MC GUI:
•
•
•
•
About IPSec Device Settings
IKE options enable you to configure Internet Key Exchange (IKE) policies used for establishing Phase 1 security associations (SAs).
IKE operates in two phases:
•
•
To establish a secure tunnel, in either Phase 1 or Phase 2, both peers must agree on the encryption algorithm and other security parameters to use. After negotiations are completed, each peer establishes an SA that defines the security parameters to use with the other peer. An IKE policy defines the security parameters that you want a device to use in negotiation with a remote peer for creating a Phase 1 SA.
Pre-shared keys are one type of IKE option used during negotiation of the Phase 1 SA. These keys are used by two peers for authentication during IKE negotiations. They offer a simple, yet secure, solution for smaller networks because they do not require the support of a public key infrastructure (PKI). However, for larger, enterprise networks, the number of key pairs that you would have to maintain can become unwieldy. If you decide to implement IKE tunnels that use pre-shared keys, Firewall MC can assist you by generating pre-shared keys for tunnel peers.
Understanding IPSec Tunnel Templates
IPSec tunnel templates define the settings used to construct IPSec tunnels. You apply tunnel templates to tunnels to provide the peers in the tunnel with the security protocols used for key negotiation and tunnel creation. This ensures that each peer in the tunnel uses common protocols and algorithms when establishing a tunnel with another peer in the tunnel. Without common protocols and algorithms, the tunnel cannot be established.
You can apply the same tunnel template to multiple tunnels. This enables you to create a consistent level of security across your network. You also can create multiple templates, each with a different level of security, and apply them to different tunnels. This enables you, for example, to specify that tunnels created within an internal network use only basic encryption, while a tunnel created from a main office to a remote office across the Internet use the strongest possible encryption.
IKE tunnel templates contain the settings used to derive the primary key for IPSec tunnel sessions. Additionally, IKE tunnels can negotiate a common set of protocols and algorithms for creating tunnels.
Firewall MC provides several default tunnel templates. These templates serve as an example of how tunnel templates are configured for various security levels. You can also use them in your policy rules, with or without modification.
To learn more about IKE tunnel templates and the default tunnel templates provided by Firewall MC, see:
•
•
Understanding IKE Tunnels Templates
IKE tunnels use pre-shared keys, RSA signatures, and RSA encrypted nonces to negotiate authentication between tunnel peers. Firewall MC fully supports the use of pre-shared keys for authentication and partially supports the use of RSA signatures for authentication using a Certificate Authority (CA). You cannot configure CA commands using the Firewall MC GUI, but you can import CA commands or manually configure such commands using the Beginning and Ending Commands feature. Additionally, tunnel peers can negotiate the AH and/or ESP protocol algorithms used to create the tunnel.
IKE tunnels use the Diffie-Hellman algorithm to derive a symmetric key for the tunnel peers while the tunnel is being created. This key can be given a time-to-live (TTL) value, after which another key is negotiated, providing perfect forward secrecy (PFS) to the tunnel. During key negotiation, a hash algorithm is used to verify data integrity and either a digital certificate or a shared secret is used for data authentication. If a shared secret is used for authentication of the Diffie-Hellman exchange, the secret must be configured on the tunnel peers.
Firewall MC facilitates the configuration of IKE tunnel key negotiation and protocol algorithm proposals through the use of tunnel templates. The template enables you to specify the parameters of key negotiation (integrity and authentication algorithms and Diffie-Hellman group) and to create prioritized lists of AH and ESP proposals. You can then apply this template to a tunnel, which defines the tunnel peers, ensuring that all peers are configured with the same IKE configuration.
One benefit of IKE tunnels is that each time the tunnel is created, and each time the time-to-live value for a key is reached, a new key is generated. Even if one key is derived from the encrypted data, data protected by subsequent keys remains safe. It also prevents an observer from gaining a large amount of cipher text generated by the same key, which can potentially make the key that encrypted the text easier to decipher.
IKE tunnels are not limited to a single AH or ESP protocol, or both. You can create prioritized lists of proposals using different protocols in each proposal. These proposals are negotiated between the peers during the creation of the tunnel. For example, you can have a group of three tunnel peers, two of which support Triple DES (PeerA and PeerB) and one of which supports only DES (PeerC), that you want to connect with an ESP tunnel. In the tunnel template, you can create an initial proposal that uses ESP with Triple DES followed by a proposal that uses ESP with DES. Whenever PeerA negotiates a tunnel with PeerB, it uses the first proposal in the tunnel template (ESP with Triple DES). However, whenever PeerA or PeerB negotiates a tunnel with PeerC, the first proposal in the tunnel template will be rejected because PeerC does not support Triple DES. The second proposal will succeed, however, because devices that support Triple DES automatically support DES.
This negotiation is prioritized by the administrator who sets up the tunnels, not by any inherent property of the algorithms. In the previous example, the Triple DES and DES proposals could easily be reversed so that the peers try to use DES as the ESP encryption algorithm before trying Triple DES. In this case, PeerA and PeerB would have used DES when negotiating the tunnel.
Understanding the Default Tunnel Templates
Firewall MC comes with several default tunnel templates. These templates are configured with some common IPSec settings. You can modify these templates for your own use, without affecting Firewall MC, or you can use them in your IPSec implementation as is. The default templates are:
•
•
•
•
•
•
Understanding IPSec Tunnels
You use IPSec tunnels to define the peers (endpoints) in an IPSec SA. When you create IPsec tunnels, you define the tunnels at one peer and select the other peer in the tunnel definition. When you create a simple site-to-site VPN between two peers, it does not matter which peer you define the tunnel at as long as both devices are represented in Firewall MC. When you define the tunnel at one device, Firewall MC automatically configures the information at the remote peer. If Firewall MC does not manage the device at one end of the tunnel, you must define the tunnel on the device that Firewall MC does manage.
You can create a hub-and-spoke configuration in Firewall MC by placing the spoke devices in a device group, then defining the tunnel at the device group and selecting the hub device as the managed peer. In a hub-and-spoke configuration, one tunnel peer acts as a hub and the remaining peers act as spokes on the hub. This enables you to create a one-to-one tunnel from the hub to each spoke, but it does not allow the spokes to create tunnels directly to other spokes. Use this configuration when you want a central-office managed device to communicate with various remote-office managed devices through tunnels created directly between the home and remote offices.
Using a combination of these two techniques, you can create even more complex configurations, like a mesh configuration or a combination configuration. In a mesh configuration, each peer is connected to every hub in the tunnel. In this configuration, no matter which peers are communicating with one another, they can communicate through an IPSec tunnel. Use this configuration if you have several remote offices that you want to interconnect with IPSec tunnels.
A combination configuration is a mix of hub-and-spoke and mesh configurations, where the hubs are connected in a mesh configuration with additional peers connected to the hubs as spokes. A mesh configuration provides flexibility for defining tunnel configurations. For example, you could have several regional offices connected to one another using IPSec tunnel in a mesh configuration. Each regional office could be connected to several local branch offices associated with the regional office. Each branch office could be connected to the associated regional office as a spoke.
Understanding Tunnel Rules
The final component in the Firewall MC implementation of IPSec configuration and management is your security policy. You use tunnel rules to enforce your security policy. Tunnel rules define the network traffic that you want tunneled. They also specify which tunnel to use for the traffic.
Tunnel rules are applied to the interface specified by the tunnel in the tunnel rule. Both inbound and outbound traffic on this interface is evaluated with the tunnel rule. If any unprotected inbound traffic on the interface matches a tunnel rule that specifies such traffic should be protected, the traffic is dropped. Similarly, inbound IPSec traffic matching a Do Not Protect tunnel rule is dropped.
We recommend that for every tunnel rule you define at the local peer for the specified tunnel, you define a "mirror image" tunnel rule at the remote peer. This ensures that traffic that has IPSec protection applied locally can be processed correctly at the remote peer. If a tunnel rule applies to traffic in which the service uses two different ports for communication, you must specify the correct service and port when "mirroring" the tunnel rule.
Note
Important Notes about IPSec Support in Firewall MC 1.3
Support for the following features and commands is not implemented in the current version of Firewall MC:
•
•
•
•
•
Configuring Site-to-Site Tunnels
Site-to-site tunnels enable you to secure traffic that crosses a public or untrusted network. The traffic enters the IPSec tunnel as it crosses a network device, such as a router or firewall, that is typically located at the edge of the trusted network. The traffic leaves the tunnel as it crosses another network device, typically located at the edge of the receiving end's trusted network.
Site-to-site tunnels usually fall into one of two categories:
•
•
Although each type of tunnel is constructed in a similar manner, there are a few key differences that you should be aware of.
In remote office/home office tunnels, you control both ends of the tunnels and the networks behind those tunnels, including the IP address space. You can disable NAT for the tunneled traffic if, by doing so, you do not create duplicate internal IP addresses.
In business partner/home office tunnels, you usually do not manage the partner end of the tunnel. You can enable NAT to keep your internal IP address hidden. Additionally, you must include the IP address provided by the partner in the tunnel used for the partner traffic. You use the IP addresses provided by the partner in a policy rule as the source or destination of the tunneled traffic. Your partner must provide you with the information needed to model the unmanaged tunnel peer and IP addresses and to manually configure its end of the tunnel with the appropriate IPSec settings (manual keys, pre-shared keys, protocols, and so on).
Creating Site-to-Site Tunnels
The following checklist outlines the tasks required to create site-to-site IPSec tunnels between two devices that are connected by an untrusted or public network. Each task might contain several actions and should be performed in the order presented.
1.
IPSec tunnel templates enable you to define the tunnel policies that you use to create site-to-site tunnels. Transform sets are used to define IPSec tunnel templates. A transform set represents a certain combination of security protocols and algorithms. During the IPSec SA negotiation, the peers agree to use a particular transform set for protecting data flow.
Firewall MC provides several default tunnel templates. If an appropriate tunnel template does not exist, you must create one before proceeding.
For more information, see:
•
2.
Using the template defined in the previous task, create the site-to-site tunnel to use for VPN access. You can skip this step if you already have a tunnel to use.
Be sure to exclude the management traffic between the CiscoWorks Server or the AUS server and the firewall devices from the tunnel.
For more information, see Creating Site-to-Site Tunnels.
3.
Tunnel rules control the traffic that should be protected by the defined tunnel. The rules identify the devices and traffic that should use the specified tunnel.
For more information, see Defining Tunnel Rules.
4.
After making desired configuration changes, you must generate the new configuration files. After you generate the new configurations, you can deploy those files or save them, then deploy later.
For more information, see Generating Configurations for Modified Devices.
Configuring IKE Options
IKE options enable you to configure IKE policies used to establish Phase 1 SAs.
IKE operates in two phases:
•
•
To establish a secure tunnel, either in Phase 1 or Phase 2, both peers must agree on the encryption algorithm and other security parameters to use. After negotiation is complete, each peer establishes an SA that defines the security parameters to use with the other peer. An IKE policy defines the security parameters for your firewall to use in negotiation with a remote peer for creating a Phase 1 SA.
Topics to be discussed are:
•
•
Configuring IKE Settings
The IKE Settings feature enables you to define security parameters to use in negotiations with a remote peer for creating a Phase 1 SA. These parameters include Identity settings, Keepalive and Retry values, and NAT Transparency settings.
Step 1
The IKE Settings page appears.
Step 2
Note
Step 3
Note
Step 4
Note
a.
b.
c.
Step 5
Note
a.
b.
Step 6
Changes are applied to the assigned firewall device configuration files when the files are generated. The configuration files are then downloaded to the firewall devices at deployment.
Table 17-1 describes the elements on the IKE Settings page.
Table 17-1 IKE Settings
Inherit settings check box
When selected, the subgroups or devices inherit the settings of the enclosing group to current scope. You can override a default setting by deselecting the check box and specifying other values. See What Is Inheritance?.
Note
Enforce/Mandate settings for children check box
When selected, settings are at a group level and are inherited by the enclosed subgroups and devices. Mandatory settings cannot be changed by a subgroup or device. See What Is Inheritance?.
Note
Identity
Identifies whether the DNS hostname, IP address, or key ID is used to identify the firewall when establishing IPSec SAs using IKE. As a general rule, set the PIX Firewall and its peers' identities in the same way to avoid an IKE negotiation failure. This failure could be caused by either the PIX Firewall or its peer not recognizing its peer's identity.
The Key-ID option may be used for a DHCP enabled firewall at the remote site to interoperate with third-party VPN headend devices that do not support the Unity protocol. The headend VPN device uses the information in the Key ID field to look up the pre-shared key.
Key ID
Identifies the ID that a headend VPN device uses to look up the pre-shared key. This ID must be unique for each tunnel peer. Key-ID is supported only in PIX Firewall 6.3 and later.
The Key ID field is enabled when you select Key-ID as the Identity type. The Key ID string will be passed to the headend VPN device using aggressive mode negotiation.
Note
Set Keepalive and Retry Values
Enables you to modify Keepalive and Retry values. The Keepalive feature is used for Dead Peer Detection (DPD). Select this check box to enable entry on the Keepalive and Retry fields.
Keepalive
Identifies the Keepalive lifetime interval. Values are 10-3600 seconds (1 hour). Default is 10. You can specify the Keepalive interval with or without specifying the Retry interval.
Retry
Identifies the interval between retries after a Keepalive response has not been received. Values are 2-10 seconds. Default is 2. To specify a Retry interval, you must also specify the Keepalive interval.
Enable NAT Traversal
Select this check box to enable NAT traversal, which lets ESP packets pass through one or more NAT devices. NAT traversal is only supported in PIX Firewall 6.3 and later. NAT traversal is described by Version 2 and Version 3 of the draft IETF standard, "UDP Encapsulation of IPsec Packets," which is available at: http://www.ietf.org/html.charters/ipsec-charter.html
NAT Keepalive
Identifies the time in seconds to keep alive NAT mappings. Tunnel peers use the NAT Keepalive value to determine how frequently to send NAT Keepalive packets. Values are 10-3600 seconds (1 hour). Default is 20.
Configuring IKE Policies
The IKE Policies feature enables you to define security parameters that are used in negotiation with a remote peer for creating a Phase 1 SA.
Step 1
The IKE Policies page appears.
Step 2
The Create IKE Policy page appears.
Step 3
Lower priority numbers have a greater priority. If the remote IPSec peer does not support the parameters selected in your first priority policy, the firewall tries to use the parameters defined in the policy with the next lowest priority number.
Step 4
Note
•
Step 5
Step 6
Step 7
Note
The larger the modulus, the higher the security and the more processing time required.Step 8
Step 9
The IKE policy is added to the list of policies on the Policies page. Changes are applied to the assigned firewall device configuration files when the files are generated. The configuration files are then downloaded to the firewall devices at deployment.
Table 17-2 describes the elements on the IKE Policies page.
Table 17-2 IKE Policies
Inherit settings check box
When selected, the subgroups or devices inherit the settings of the enclosing group to current scope. You can override a default setting by deselecting the check box and specifying other values. See What Is Inheritance?.)
Note
Enforce/Mandate settings for children check box
When selected, settings are at a group level and are inherited by the enclosed subgroups and devices. Mandatory settings cannot be changed by a subgroup or device. See What Is Inheritance?.
Note
Priority
Identifies the priority of the IKE policy. Lower priority numbers have a greater priority. If the remote IPSec peer does not support the parameters selected in your first priority policy, the firewall tries to use the parameters defined in the policy with the next lowest priority number.
Encryption
Specifies the symmetric encryption algorithm used to establish the Phase 1 SA for protecting Phase 2 negotiations. The encryption algorithms supported by the firewall are:
Note
•
•
•
•
•
Hash
Specifies the hash algorithm used for authentication and ensuring data integrity.
•
•
Note
Diffie-Hellman Group
Specifies the Diffie-Hellman group identifier, which is used by the two IPSec peers to derive a shared secret without transmitting it to each other.
To perform the Diffie-Hellman operation, both sides must agree to use a number or group for the mathematical calculation. PIX OS versions before 6.3 support Group 1 (768 bits) and Group 2 (1024 bits). PIX OS 6.3 and later adds support for Group 5 (1536 bits), which provides higher security for the Diffie-Hellman operation.
•
•
•
Authentication
Specifies the method of authentication used to establish the identify of each IPSec peer:
•
•
Firewall MC partially supports the use of RSA signatures for authentication using a CA. You cannot configure CA commands using the Firewall MC GUI, but you can import CA commands or manually configure such commands using the Beginning and Ending Commands feature.
Lifetime (sec)
Identifies the SA lifetime. Default is 86,400 seconds (24 hours). As a general rule, a shorter lifetime provides more secure IKE negotiations. However, with longer lifetimes, future IPSec SAs can be set up more quickly.
Configuring IKE Interfaces
The IKE Interfaces feature enables you to define which interfaces are enabled for IKE. You can also specify which of these interfaces also permit Easy VPN traffic.
Step 1
The IKE Interfaces page appears.
Step 2
Step 3
You must enable IKE on an interface before you can permit Easy VPN traffic on that interface.
Note
Step 4
Changes are applied to the assigned firewall device configuration files when the files are generated. The configuration files are then downloaded to the firewall devices at deployment.
Table 17-3 describes the elements on the IKE Interfaces page.
Table 17-3 IKE Interfaces
Inherit settings check box
When selected, the subgroups or devices inherit the settings of the enclosing group to current scope. You can override a default setting by deselecting the check box and specifying other values. See What Is Inheritance?.)
Note
Enforce/Mandate settings for children check box
When selected, settings are at a group level and are inherited by the enclosed subgroups and devices. Mandatory settings cannot be changed by a subgroup or device. See What Is Inheritance?.
Note
Interface column
Identifies the interfaces on which you can enable IKE and Easy VPN traffic. The table lists all interfaces defined at the current scope.
Enabled column
Identifies whether the interface is enabled or not.
IKE Enabled column
Identifies whether IKE is enabled on the interface. To enable IKE on an interface, select the IKE Enabled check box for that interface.
Allow Easy VPN Traffic column
Identifies whether Easy VPN traffic is permitted on the interface. To permit Easy VPN traffic on an interface, select the Allow Easy VPN Traffic check box. You must enable IKE on an interface before you can permit Easy VPN traffic.
Note
Configuring Pre-shared Keys
The Pre-shared Keys feature lets you configure pre-shared keys for authenticating IPSec peers. You can also define a default pre-shared key policy for peers that do not have a pre-shared key explicitly defined.
Whenever you cannot use IKE to establish SAs between your firewall and a remote IPSec peer, you can manually configure the pre-shared key used for establishing the Phase 1 SA. This is practical only with a limited number of IPSec peers having known IP addresses (or DNS hostnames). This method of configuration is most practical for site-to-site VPNs. Whenever a new peer is added to the network, you must configure pre-shared keys for that peer and any PIX Firewall or other VPN headend using pre-shared keys. Also, you cannot use SA lifetimes or PFS when using pre-shared keys. To access this feature, select Configuration > VPN > IKE Options > Pre-shared Keys.
Topics to be discussed are:
•
•
•
•
Defining the Default Pre-shared Key Policy
You can define a default pre-shared key policy for peers that do not have a pre-shared key explicitly defined.
Note
Step 1
The Pre-shared Keys page appears.
Step 2
•
•
•
Step 3
Table 17-4 describes the elements on the Default Pre-shared Key Policy page.
Table 17-4 Default Pre-shared Key Policy
Inherit settings check box
When selected, the subgroups or devices inherit the settings of the enclosing group to current scope. You can override a default setting by deselecting the check box and specifying other values. See What Is Inheritance?.)
Note
Enforce/Mandate settings for children check box
When selected, settings are at a group level and are inherited by the enclosed subgroups and devices. Mandatory settings cannot be changed by a subgroup or device. See What Is Inheritance?.
Note
Auto-generate Pre-shared Keys
Specifies how Firewall MC should handle key generation for peers whose pre-shared keys are not explicitly defined in the User Specified Pre-shared Key table.
•
•
•
Regenerate Pre-shared Keys check box
When selected, enables pre-shared keys that are automatically generated to be regenerated the next time configuration files are generated. This check box is available only after you click the Auto-generate Keys radio button.
Default Key
Identifies the key to use for peers that are not explicitly defined in the User Specified Pre-shared Key table. This field is enabled when you click the Use Default Key radio button.
Confirm Default Key
Enables you to re-enter the Default Key entry.
Apply button
Saves current settings.
Reset button
Discards changes made to the Default Pre-shared Key Policy table and reverts the information displayed to the most recent saved information.
View Keys button
Displays a list of the auto-generated and default pre-shared keys that are created from the default pre-shared key policy for the selected device.
Generating New Auto-generated Pre-shared Keys
Step 1
The Pre-shared Keys page appears.
Step 2
Step 3
Step 4
Step 5
Step 6
The Keys Status field for the selected tunnel changes to Keys Marked For Refresh. Firewall MC will generate new pre-shared keys for the IPSec tunnel peers the next time configuration files are generated.
Viewing Auto-generated Pre-shared Keys
Step 1
The Pre-shared Keys page appears.
Step 2
Note
Step 3
The IKE Pre-shared Keys page appears.
Step 4
Table 17-5 describes the elements on the IKE Pre-shared Keys page.
Defining the Pre-shared Key for a Peer
Step 1
The Pre-shared Keys page appears.
Step 2
The Create IKE Pre-shared Key page appears.
Step 3
Step 4
•
•
Step 5
a.
b.
c.
d.
e.
Step 6
a.
b.
Step 7
The pre-shared key is created and added to the User Specified Pre-shared Key Table.
Step 8
Table 17-6 describes the elements on the User Specified Pre-shared Key page.
Table 17-6 User Specified Pre-shared Keys
Inherit settings check box
When selected, the subgroups or devices inherit the settings of the enclosing group to current scope. You can override a default setting by deselecting the check box and specifying other values. See What Is Inheritance?.)
Note
Enforce/Mandate settings for children check box
When selected, settings are at a group level and are inherited by the enclosed subgroups and devices. Mandatory settings cannot be changed by a subgroup or device. See What Is Inheritance?.
Note
Key
Identifies the pre-shared authentication key for this peer. You enter the pre-shared key in the Create IKE Pre-shared Key page. The key is masked in the Create IKE Pre-shared Key page and in the User Specified Pre-shared Key table using asterisks (*). To view the key in clear text, select View Config > Generate Config.
Confirm Key
Allows you to re-enter the pre-shared authentication key for this peer. The key is masked using asterisks (*). To view the key in clear text, select View Config > Generate Config.
XAuth check box
Identifies whether extended authentication (XAuth) is enabled or disabled for the specified peer. XAuth lets you deploy IPSec VPNs using a TACACS+, RADIUS, or LOCAL database as your user authentication method. This feature provides user authentication by prompting for a username and password and verifying these with information stored in a TACACS+, RADIUS, or LOCAL database.
Note
Mode Config check box
When selected, a security gateway (in this case a PIX Firewall) can download an IP address and other network level configuration to a VPN client peer as part of IKE (Phase 1) SA negotiation. Using this exchange, the firewall gives an IP address to the VPN client to be used as an "inner" IP address encapsulated in the IPSec packet. This provides a known IP address for the VPN client, which can be matched against the IPSec rules. To implement this feature, it must also be supported by any routers handling the IPSec traffic.
Peer Type
Identifies whether the peer for which you are defining a pre-shared key is managed by Firewall MC.
•
•
Peer
Identifies the peer for which you are defining a pre-shared key.
•
•
Peer Interface
Lists available interfaces. Used when the peer for which you are defining a pre-shared key is a managed device.
Configuring XAuth/Mode Config
The XAuth/Mode Config feature enables you to configure Extended Authentication (XAuth) and Mode Configuration (Mode Config) on a particular interface. To access this feature, select Configuration > VPN > IKE Options > XAuth/Mode Config.
XAuth enables you to use a TACACS+, RADIUS, or LOCAL database to authenticate a remote user of an IPSec VPN. XAuth, which is designed for VPN clients, provides authentication by prompting the user for a username and password. This information is verified against information stored in your TACACS+, RADIUS, or LOCAL database. XAuth is negotiated between IPSec Phase 1 (IKE device authentication phase) and IPSec Phase 2 (IPSec SA negotiation phase). If XAuth fails, the IPSec SA will not be established and the IKE security association will be deleted.
Note
Mode Config allows a security gateway (in this case a PIX Firewall) to download an IP address (and other IP-related settings) to a VPN client peer as part of SA negotiation. Using this exchange, the firewall gives an IP address to the VPN client to be used as an "inner" IP address encapsulated under IPSec. This provides a known IP address for a VPN client, which can be matched against the IPSec policy. To implement this feature, it must also be supported by any routers handling the IPSec traffic.
Note
Before You Begin
•
The LOCAL group is defined by default, but if you are using the LOCAL database, you must configure user accounts. See Configuring User Accounts, page 8-59.
•
Step 1
The XAuth/Mode Config page appears.
Step 2
The IKE XAuth/Mode Config page appears.
Step 3
a.
b.
c.
Note
Step 4
a.
b.
Step 5
The settings are saved. Changes are applied to the assigned firewall device configuration files when they are generated. The configuration files are then downloaded to the firewall devices at deployment.
Table 17-7 describes the elements on the XAuth/Mode Config page.
Table 17-7 XAuth/Mode Config
Inherit settings check box
When selected, the subgroups or devices inherit the settings of the enclosing group to current scope. You can override a default setting by deselecting the check box and specifying other values. See What Is Inheritance?.)
Note
Enforce/Mandate settings for children check box
When selected, settings are at a group level and are inherited by the enclosed subgroups and devices. Mandatory settings cannot be changed by a subgroup or device. See What Is Inheritance?.
Note
Interface
Identifies the interface to which the XAuth and Mode Config settings apply.
XAuth check box
Enables the Extended Authentication (XAuth) feature within the IKE protocol. This allows you to use a TACACS+, RADIUS, or LOCAL database as your user authentication method for client-to-device VPN tunnels.
XAuth, which is designed for VPN clients, provides authentication by prompting the user for a username and password. This information is verified against information stored in your TACACS+, RADIUS, or LOCAL database. XAuth is negotiated between IPSec Phase 1 (IKE device authentication phase) and IPSec Phase 2 (IPSec SA negotiation phase). If XAuth fails, the IPSec SA will not be established and the IKE SA will be deleted.
Note
XAuth Server
Use this list to select the AAA server group1 to use for XAuth.
Token-based Server
(Server is Token-based check box)Enable this option if the AAA server supports a user authentication system based on a hardware or software token. This option is not available when using the LOCAL database.
Note
Mode Config check box
Enables the Mode Config feature. Mode Config allows a security gateway (in this case a PIX Firewall) to download an IP address (and other IP-related settings) to a VPN client peer as part of SA negotiation. Using this exchange, the firewall gives an IP address to the VPN client to be used as an "inner" IP address encapsulated under IPSec. This provides a known IP address for a VPN client, which can be matched against the IPSec policy. To implement this feature, it must also be supported by any routers handling the IPSec traffic.
Note
IP Pool
Identifies the pool of IP addresses2 to be used for supplying addresses when Mode Config is enabled.
IKE Enabled
Identifies whether IKE is enabled on the selected interface.
1 To define AAA server groups, select Configuration > Building Blocks > AAA Server Group. See Defining AAA Server Groups, page 10-31.
2 To configure IP pools, select Configuration > VPN > Remote Access > IP Pools. See Defining IP Pools.
Configuring Fully Qualified Domain Name/IP Address Exceptions
The Fully Qualified Domain Name (FQDN)/IP Address Exceptions feature lets you configure multiple IPSec peers and enable or disable XAuth and Mode Config for each. You should configure the XAuth feature for the peer depending on the authentication method used within your IKE policies.
Step 1
The FQDN/IP Exceptions page appears.
Step 2
The Create FQDN/IP Peer Exception page appears.
Step 3
Note
Step 4
•
•
Step 5
•
•
Step 6
The peer is added to the list of peers on the FQDN/IP Exceptions page.
Table 17-8 describes the elements on the FQDN/IP Exceptions page.
Table 17-8 FQDN/IP Exceptions
Inherit settings check box
When selected, the subgroups or devices inherit the settings of the enclosing group to current scope. You can override a default setting by deselecting the check box and specifying other values. See What Is Inheritance?.)
Note
Enforce/Mandate settings for children check box
When selected, settings are at a group level and are inherited by the enclosed subgroups and devices. Mandatory settings cannot be changed by a subgroup or device. See What Is Inheritance?.
Note
Peer
(Peer FQDN/IP)Specifies the fully qualified domain name (FQDN) or IP address of the IPSec VPN peer for which you are configuring XAuth or Mode Config settings.
XAuth
If you have both a site-to-site VPN peer and VPN client peers terminating on the same interface, and have the XAuth feature configured, configure the firewall to make an exception to this feature for the site-to-site VPN peer. With this exception, the firewall will not challenge the site-to-site peer for a username and password. The command that you employ to make an exception to the XAuth feature depends on the authentication method you are using within your IKE policies.
To disable the exchange of XAuth (username and password) information with the FQDN/IP peer, deselect the XAuth check box. To indicate that this device should use the default setting for XAuth when communicating with the FQDN/IP peer, select the XAuth check box.
Mode Config
If you have both a site-to-site VPN peer and VPN clients terminating on the same interface, and have the IKE Mode Config feature configured, you should also configure the firewall to make an exception. With this exception, the firewall does not attempt to download an IP address to the peer for dynamic IP address assignment.
To disable the exchange of Mode Config (dynamically assigned IP address) information with the FQDN/IP peer, deselect the Mode Config check box. To indicate that this device should use the default setting for Mode Config when communicating with the FQDN/IP peer, select the Mode Config check box.
Creating Site-to-Site Tunnels
The Site-to-Site Tunnels feature enables you to create IPSec tunnels. When you create IPSec tunnels, you define the tunnels at one peer and select the other peer in the tunnel definition. When creating a simple site-to-site VPN between two peers it does not matter at which peer you define the tunnel as long as both devices are represented in Firewall MC. When you define the tunnel at one device, Firewall MC automatically configures the tunnel information at the remote peer. If the device at one end of the tunnel is not managed by Firewall MC, you must define the tunnel on the device that is.
You can create a hub-and-spoke configuration in Firewall MC by placing the spoke devices in a device group, and then defining the tunnel on the device group and selecting the hub device as the managed peer.
Step 1
The Site-to-Site Tunnels page appears.
Step 2
Tip
Step 3
The Enter Site-to-Site Tunnel Data page appears.
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
a.
The Select Peer IP Address page appears.
b.
c.
The unmanaged peer is added to the list of peers.
Step 10
a.
The Select Hub page appears.
b.
c.
The managed peer is added to the list of peers.
d.
Step 11
Note
Step 12
Step 13
The site-to-site tunnel is created, and changes are applied to the assigned firewall device configuration files when they are generated. The configuration files are then downloaded to the firewall devices at deployment.
Table 17-9 describes the elements on the Site-to-Site Tunnels page.
Creating Dynamic Tunnels
The Dynamic Tunnels feature enables you to create tunnels to use for remote access. Dynamic tunnels do not require you to know the IP addresses of tunnel peers. You must create at least one dynamic tunnel before you can configure Easy VPN Servers.
Step 1
The Dynamic Tunnels page appears.
Step 2
Note
Step 3
The Enter Dynamic Tunnel Data page appears.
Step 4
Step 5
Step 6
Step 7
Step 8
Note
Step 9
Step 10
The dynamic tunnel is created, and changes are applied to the assigned firewall device configuration files when they are generated. The configuration files are then downloaded to the firewall devices at deployment.
Table 17-10 describes the elements on the Dynamic Tunnels page.
Defining Tunnel Rules
The Tunnel Rules feature enables you to define policy rules that govern which traffic should be tunneled, and the tunnel to use for such traffic. To access this feature, select Configuration > VPN > Tunnel Rules.
The Tunnel Rules table supports the use of categories, coloring, filtering, and highlighting. These features make it much easier to work with large tables. For more information, see Configuring Access Rule Tables, page 11-16.
Step 1
The Tunnel Rules page appears.
Step 2
Note
Step 3
•
•
•
•
•
The Create IPSec Rule page appears.
Step 4
Step 5
•
•
Note
•
Step 6
Note
•
Step 7
a.
The objects are moved to the Selected Objects column.
b.
A popup window helps you define the network object. After you complete the definition, the new network object is added to the Selected Objects column. For more information, see Adding or Editing a Network Object, page 10-21.
c.
Step 8
a.
The objects are moved to the Selected Objects column.
b.
A popup window helps you define the network object. For more information, see Defining Network Objects, page 10-9.
c.
Step 9
a.
b.
The objects are moved to the Selected Services column.
c.
A popup window helps you define the building block. After you complete the definition, the new building block is added to the Selected Services column. For more information, see Configuring Service Definitions, page 10-24.
d.
A popup window helps you define the building block. After you complete the definition, the new building block is added to the Selected Services column. For more information, see Defining Service Groups, page 10-28.
e.
Note
Step 10
Note
a.
The Selecting Tunnel Peers dialog box appears.
b.
The objects are moved to the Selected Peers column.
c.
Step 11
Step 12
Step 13
The tunnel rule is created, and changes are applied to the assigned firewall device configuration files when they are generated. The configuration files are then downloaded to the firewall devices at deployment.
Table 17-11 describes the elements on the Tunnel Rules page.
Table 17-11 Tunnel Rules
Action
Displays the action of the rules listed in the rules table. Valid actions for tunnel rules are:
•
•
Note
Tunnels
Identifies the tunnel to use for protecting this traffic.
Note
Remote Peers
Identifies remote peers to which this rule applies. If there are multiple remote peers for the selected tunnel, you can specify the peers to which a rule should apply.
Local Networks
Allows you to enter source network object1 names or addresses of hosts for which the tunnel rule applies. Multiple entries are separated by commas.
Note
Remote Networks
Allows you to enter destination network object 1 names or addresses of hosts for which the tunnel rule applies. Multiple entries are separated by commas.
Note
Service
Allows you to enter the name of one or more services2 . Multiple entries are separated by commas.
We recommend that for every tunnel rule you define at the local peer for the specified tunnel, you define a "mirror image" tunnel rule at the remote peer. This ensures that traffic that has IPSec protection applied locally can be processed correctly at the remote peer. If this tunnel rule applies to traffic in which the service uses two different ports for communication, you must specify the correct service and port when "mirroring" the tunnel rule.
Note
Enabled
Identifies whether the tunnel rule is enabled.
Category3
Element defined in Building Blocks to provide an intermediate level of detail to objects to help you categorize and readily identify rules and building blocks.
Description
Optional user-defined comment for the tunnel rule.
Insert button
Adds a row in an ordered table.
Edit button
Edits an existing row in a table.
View button
Shows information in read-only mode.
Copy button
Copies a row in a table.
Cut button
Removes a row in a table.
Paste button
Pastes a row that was copied or cut from a table.
Delete button
Removes a row from a table.
View All button
Displays all rules (mandatory and default) defined from Global down to the current scope.
1 For more information about network objects, see Defining Network Objects, page 10-9.
2 For more information about services, see Configuring Service Definitions, page 10-24.
3 Categories are defined in Building Blocks. Select Configuration > Building Blocks > Categories. See Using Categories and Color-Coding, page 10-5.
Cutting, Copying, or Pasting a Tunnel Rule
When configuring IPSec tunnel rules, you can use the following shortcuts to help you define your rules:
•
•
•
Note
Step 1
The Tunnel Rules table appears.
Step 2
Note
Step 3
•
•
•
Note
•
Deleting a Tunnel Rule
Step 1
The Tunnel Rules table appears.
Step 2
Note
Step 3
You are prompted to confirm the delete request.
Step 4
The row is removed from the table.
Configuring Remote Access
Firewall MC provides the following features for configuring Easy VPN Remote (vpnclient command) on a PIX Firewall:
•
•
Note
•
•
Creating Remote User Tunnels
You can create IPSec tunnels between a remote user and your internal network. This type of tunneling creates a VPN, whereby a remote user can be securely connected to a corporate intranet over the Internet or a shared network.
The following checklist outlines the tasks required to create IPSec tunnels between a remote user and your internal network. Each task should be performed in the order presented.
Before You Begin
•
•
–
–
–
–
–
–
–
1.
IPSec tunnel templates enable you to define tunnel policies that are used to create dynamic tunnels. Transform sets are used to define IPSec tunnel templates. A transform set represents a certain combination of security protocols and algorithms. During the IPSec SA negotiation, the peers agree to use a particular transform set for protecting data flow.
Firewall MC provides several default tunnel templates. If an appropriate tunnel template does not exist, you must create one before proceeding.
For more information, see:
•
2.
Using the template defined in the previous task, you must create the dynamic tunnel to use for remote access. The tunnel must be available at the same scope at which you are configuring an Easy VPN Server. You can skip this step if you already have a tunnel that you want to use.
For more information, see Creating Dynamic Tunnels.
3.
The IP Pools feature lets you create a named pool of local IP addresses that can be used for dynamically assigning IP addresses to remote VPN clients.
For more information, see Defining IP Pools.
4.
You must configure the PIX Firewall that is acting as an Easy VPN Server in order to provide access to VPN clients.
For more information, see Configuring Easy VPN Server.
5.
You must configure the Easy VPN Remote feature on PIX Firewalls that will be operating as Cisco Secure VPN Clients. Also, you can enable the Easy VPN Management feature for Cisco Secure VPN Clients.
For more information, see:
•
6.
The security policy identifies the devices and controls the traffic that should be protected by the defined tunnel.
For more information, see Defining Tunnel Rules.
7.
After making desired configuration changes, you must generate the new configuration files. After you generate the new configurations, you can deploy those files or save them and deploy them later.
For more information, see Generating Configurations for Modified Devices.
Defining IP Pools
The IP Pools feature lets you create a named pool of local IP addresses. A pool can be used for dynamically assigning IP addresses to remote VPN clients.
Step 1
The IP Pools page appears.
Step 2
The Create VPN IP Pool page appears.
Step 3
Step 4
Step 5
The IP pool is created and added to the list of pools available on the IP Pools page.
Table 17-12 describes the elements on the IP Pools page.
Table 17-12 IP Pools
Inherit settings check box
When selected, the subgroups or devices inherit the settings of the enclosing group to current scope. You can override a default setting by deselecting the check box and specifying other values. See What Is Inheritance?.)
Note
Enforce/Mandate settings for children check box
When selected, settings are at a group level and are inherited by the enclosed subgroups and devices. Mandatory settings cannot be changed by a subgroup or device. See What Is Inheritance?.
Note
Name
A descriptive identifier for the address pool.
Range Start (Start Address)
The starting IP address of the IP pool.
Note
Range End (End Address)
The ending IP address of the IP pool.
Configuring Easy VPN Server
The Easy VPN Server feature enables you to configure a PIX Firewall to operate as an Easy VPN Server. When used as an Easy VPN Server, the firewall can push VPN configuration to any Easy VPN Remote device, which greatly simplifies configuration and administration. To access this feature, select Configuration > VPN > Remote Access > Easy VPN Servers.
Note
The following are some of the different types of Easy VPN Remote devices you can use with a PIX Firewall configured as an Easy VPN Server:
•
–
–
•
–
–
–
Step 1
The Easy VPN Servers page appears.
Step 2
The Enter Easy VPN Server Data page appears.
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
The Enter Managed Split DNS/Tunneling Data page appears.
Step 13
Step 14
Step 15
The Enter Authentication Data page appears.
Step 16
Step 17
a.
b.
c.
d.
Step 18
The Enter Backup Servers Data page appears.
Step 19
a.
b.
Step 20
Note
Step 21
The Summary page appears.
Step 22
The Easy VPN Server is added to the list of servers on the Easy VPN Servers page. Changes are applied to the assigned firewall device configuration files when the files are generated. The configuration files are then downloaded to the firewall devices at deployment.
Table 17-13 describes the elements on the Easy VPN Servers page.
Table 17-13 Easy VPN Servers
Inherit settings check box
When selected, the subgroups or devices inherit the settings of the enclosing group to current scope. You can override a default setting by deselecting the check box and specifying other values. See What Is Inheritance?.)
Note
Enforce/Mandate settings for children check box
When selected, settings are at a group level and are inherited by the enclosed subgroups and devices. Mandatory settings cannot be changed by a subgroup or device. See What Is Inheritance?.
Note
Name
Descriptive group name for the Cisco VPN Client 3.x client group.
Pool
Pool used to assign IP addresses to Cisco VPN Clients. IP pools are defined at Configuration > VPN > Remote Access > IP Pools. See Defining IP Pools.
Primary DNS
IP address of the primary DNS server on your local network that will be passed to the Cisco VPN Client 3.x.
Primary WINS
IP address of the primary WINS server on your local network that will be passed to the Cisco VPN Client v3.x.
Domain
Local domain name that will be passed to the Cisco VPN client v3.x.
Name
Descriptive group name to be used for this Cisco VPN Client 3.x client group.
Password
The group pre-shared key to be used for IKE authentication by the Cisco VPN Client 3.x client group. This must be at least eight alphanumeric (U.S. English) characters with no special (non-alphanumeric) characters.
Confirm Password
Re-enter the group password.
IP Pool
Select the pool used to assign IP addresses to Cisco VPN Clients. IP pools are defined at Configuration > VPN > Remote Access > IP Pools. See Defining IP Pools.
Idle Timeout
Sets the inactivity timeout for a client in seconds. When the inactivity timeout for all IPSec SAs have expired for a Cisco VPN Client, the tunnel is terminated. Default is 1800 seconds (30 minutes).
Max Time
Sets the maximum connection time for a client in seconds. When the maximum connection time is reached for a Cisco VPN Client, the tunnel is terminated. This means the connection between the client and the firewall will have to be reestablished. Default is 365 days.
Domain
Local domain name that will be passed to the Cisco VPN client v3.x.
Enable PFS
When selected, enables perfect forward secrecy.
DNS Servers
IP address of the primary and secondary DNS servers on your local network that will be passed to the Cisco VPN Client 3.x.
WINS Servers
IP address of the primary and secondary WINS servers on your local network that will be passed to the Cisco VPN Client 3.x or 4.x.
Domain(s)
List of up to eight domain names, separated by a space or a comma. Requests to these domain names will be tunneled if split tunneling is enabled.
Network(s)
List of networks or network object building blocks, separated by a comma, for which traffic will be subject to split tunneling. Split tunneling allows a remote Cisco VPN Client simultaneous encrypted access to the corporate network and clear access to the Internet.
You can enter the network IP address and netmask (in either bit count or dotted decimal format) separated by a forward slash (for example, 192.168.1.10/24 or 192.168.1.10/255.255.255.0), or click Select to display a list of network objects.
Enable Secure Unit Authentication check box
When this check box is selected, Secure Unit Authentication (SUA) is enabled for the group.
User Authentication
Enable Individual User Authentication check box
When selected, Individual User Authentication (IUA) is enabled for the group. IUA lets you individually authenticate users based on IP address on your inside network. IUA is independent of SUA and all combinations of their configurations are supported.
Idle Timeout
Number of seconds of inactivity before the tunnel is torn down. Default is 1800 seconds (30 minutes).
AAA Server Group
Select the AAA server that VPN clients will use to authenticate from the list.
Note
Enable Device Pass Through check box
When selected, enables device pass through for the group. If certain devices on the inside interface of the Easy VPN Remote Device are incapable of authentication, such as IP phones, this option lets them bypass authentication when IUA is enabled. This feature must be enabled on the Easy VPN Server.
Enable Backup Server Configuration check box
When selected, you can configure a list of backup Easy VPN Servers. If the primary Easy VPN Server is not available, you can specify a list of backup Easy VPN Servers to connect to.
IP Address(es)
IP addresses of the backup Easy VPN Servers separated by a comma. You can list up to 10 backup servers.
Clear Current Client Backup Server(s) List check box
When selected, clears the local list of backup Easy VPN Servers from the configuration.
Note
Configuring Easy VPN Remote
The Easy VPN Remote feature enables you to configure a PIX Firewall to operate as a Cisco Secure VPN client, thus providing a VPN connection to an Easy VPN Server.
Step 1
The Easy VPN Remote page appears.
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
Enter MAC addresses and their respective masks in pairs. Use a space to separate the MAC address and the mask and a comma to separate information for multiple devices. Use one of the following formats:
•
•
•
•
For example, 0090.0C7A.0050 ffff.ffff.ffff, 00:72:34:a3:09:c4 ff:ff:ff:ff:ff:ff.
Note
Step 13
Changes are applied to the assigned firewall device configuration files when the files are generated. The configuration files are then downloaded to the firewall devices at deployment.
Table 17-14 describes the elements on the Easy VPN Remote page.
Table 17-14 Easy VPN Remote
Inherit settings check box
When selected, the subgroups or devices inherit the settings of the enclosing group to current scope. You can override a default setting by deselecting the check box and specifying other values. See What Is Inheritance?.
Note
Enforce/Mandate settings for children check box
When selected, settings are at a group level and are inherited by the enclosed subgroups and devices. Mandatory settings cannot be changed by a subgroup or device. See What Is Inheritance?.
Note
Enable easy VPN remote check box
Instructs firewall device to operate as a Cisco Secure VPN client.
Primary easy VPN server IP address
Server (concentrator) IP address to which VPN client connects.
Note
Secondary easy VPN server IP address
IP address of failover server (concentrator) to which VPN client connects.
Group name
Name of VPN group configured on Cisco Easy VPN Server. Maximum length is 63 alphanumeric (U.S. English) characters.
Note
A group name and password is required for PIX Firewall version 6.2 and earlier.Group password
Arbitrary string of characters used to prevent unauthorized access to a group of associated resources.
Confirm group password
Group password is re-entered.
Username
Unique name to be used for user authorization. Maximum length is 127 characters.
Note
User password
Arbitrary string of characters, chosen by a user or system administrator, used to prevent unauthorized access to a user's account. Maximum length is 127 characters.
Confirm user password
User password is re-entered.
Mode radio buttons
Mode of operation for the Easy VPN Remote device. Options are:
•
•
Note
MAC exempt addresses and masks
List of MAC addresses and masks of devices that are exempt from user authentication. MAC addresses and their respective masks are entered in pairs separated by commas, and must use one of the following formats:
•
•
•
•
For example,
0090.0C7A.0050 ffff.ffff.ffff, 00:72:34:a3:09:c4 ff:ff:ff:ff:ff:ff.
Configuring Easy VPN Management
PIX Firewall OS 6.3 introduces a feature that improves administrative security by letting you identify the networks from which your PIX Firewall can be managed remotely or by preventing remote management. The Easy VPN Management feature allows you to control remote management access to your PIX Firewall.
Note
Step 1
The Easy VPN Management page appears.
Step 2
Step 3
•
Note
•
–
–
192.168.1.1/255.255.255.0, 192.168.2.1/24). If you do not specify a subnet mask, Firewall MC applies a host mask (/32).•
Step 4
Changes are applied to the assigned firewall device configuration files when the files are generated. The configuration files are then downloaded to the firewall devices at deployment.
Table 17-15 describes the elements on the Easy VPN Management page.
Table 17-15 Easy VPN Management
Inherit settings check box
When selected, the subgroups or devices inherit the settings of the enclosing group to current scope. You can override a default setting by deselecting the check box and specifying other values. See What Is Inheritance?.)
Note
Enforce/Mandate settings for children check box
When selected, settings are at a group level and are inherited by the enclosed subgroups and devices. Mandatory settings cannot be changed by a subgroup or device. See What Is Inheritance?.
Note
Enable Easy VPN remote check box
Instructs firewall device to operate as a Cisco Secure VPN client.
Management access configuration radio buttons
•
Note
•
192.168.1.1/255.255.255.0, 192.168.2.1/24). If you do not specify a subnet mask, Firewall MC applies a host mask (/32).•
Configuring VPN System Options
The Sysopt feature lets you configure the firewall to allow IPSec traffic through it without the need for access rules. This means you will not have to configure specific access rules to permit this type of traffic. These system options are not enabled by default and must be explicitly enabled.
Step 1
The Sysopt page appears.
Step 2
Step 3
Table 17-16 describes the elements on the Sysopt page.
Table 17-16 Sysopt
Inherit settings check box
When selected, the subgroups or devices inherit the settings of the enclosing group to current scope. You can override a default setting by deselecting the check box and specifying other values. See What Is Inheritance?.)
Note
Enforce/Mandate settings for children check box
When selected, settings are at a group level and are inherited by the enclosed subgroups and devices. Mandatory settings cannot be changed by a subgroup or device. See What Is Inheritance?.
Note
Bypass Access Check for IPSec Traffic
When selected, enables IPSec authenticated/cipher inbound sessions to always be permitted. This permits IPSec traffic to pass through the firewall without a check of the conduit or access-list command statements. The sysopt connection permit-ipsec command is written to the firewall. Because L2TP traffic can only come from IPSec, the sysopt connection permit-ipsec command allows L2TP traffic to pass as well.
