小菜ASA学习笔记（三）

Note When the security appliance is configured for IPsec ×××, you cannot enable security contexts (also called firewall multmode) or Active/Active stateful failover. Therefore, these features are unavailable. html

You must enable ISAKMP on the interface that terminates the ××× tunnel. Typically this is the outside, or public interface. web

Phase 1 ISAKMP negotiations can use either main mode or aggressive mode. Both provide the same services, but aggressive mode requires only two exchanges between the peers totaling 3 messages, rather than three exchanges totaling 6 messages. Aggressive mode is faster, but does not provide identity protection for the communicating parties. Therefore, the peers must exchange identification information prior to establishing a secure SA. Aggressive mode is enabled by default. session

NAT-T lets IPsec peers establish a connection through a NAT device. It does this by encapsulating IPsec traffic in UDP datagrams, using port 4500, thereby providing NAT devices with port information. NAT-T auto-detects any NAT devices, and only encapsulates IPsec traffic when necessary. This feature is disabled by default. app

With the exception of the home zone on the Cisco ASA 5505, the security appliance can simultaneously support standard IPsec, IPsec over TCP, NAT-T, and IPsec over UDP, depending on the client with which it is exchanging data. When both NAT-T and IPsec over UDP are enabled, NAT-T takes precedence. IPsec over TCP, if enabled, takes precedence over all other connection methods.less

Note IPsec over TCP does not work with proxy-based firewalls. dom

IPsec over TCP works with remote access clients. You enable it globally, and it works on all ISAKMP enabled interfaces. It is a client to security appliance feature only. It does not work for LAN-to-LAN connections ssh

You enable IPsec over TCP on both the security appliance and the client to which it connects. The default port is 10000. tcp

Each SA consists of the following: ide

? Transform sets ui

? Crypto maps

? Access lists

? Tunnel groups

? Prefragmentation policies

Note If you clear or delete the only element in a transform set, the security appliance automatically removes the crypto map references to it.

Access lists assigned to IPsec crypto maps have four primary functions:

? Select outbound traffic to be protected by IPsec (permit = protect).

? Trigger an ISAKMP negotiation for data travelling without an established SA.

? Process inbound traffic to filter out and discard traffic that should have been protected by IPsec.

? Determine whether to accept requests for IPsec SAs when processing IKE negotiation from the peer. (Negotiation applies only to ipsec-isakmp crypto map entries.) The peer must “permit” a data flow associated with an ipsec-isakmp crypto map command entry to ensure acceptance during negotiation.

Note If you delete the only element in an access list, the security appliance also removes the associated crypto map.

If you modify an access list currently referenced by one or more crypto maps, use the crypto map interface command to reinitialize the run-time SA database.

Note Decrypted "through" traffic is permitted from the client despite having an access-group on the outside interface, which calls a "deny ip any any" access-list, while no sysopt connection permit-*** is configured. Users who want to control access to the protected network via Site-to-Site or remote access ××× using the no sysopt permit command in conjunction with an access control list (ACL) on the outside interface are not successful.

In this situation, when management-access inside is enabled, the ACL is not applied, and users can still connect using SSH to the security appliance. Traffic to hosts on the inside network are blocked correctly by the ACL, but can't block decrypted "through" traffic to the inside interface. The ssh and http commands are of a higher priority than the ACLs. In other words, to deny ssh, telnet, or ICMP traffic to the box from the ××× session, use ssh, telnet and icmp commands, which denies the IP local pool should be added.

If you change a global lifetime, the security appliance drops the tunnel. It uses the new value in the negotiation of subsequently established SAs.

A dynamic crypto map is a crypto map without all of the parameters configured. It acts as a policy template where the missing parameters are later dynamically learned, as the result of an IPsec negotiation, to match the peer requirements. The security appliance applies a dynamic crypto map to let a peer negotiate a tunnel if its IP address is not already identified in a static crypto map. This occurs with the following types of peers:

? Peers with dynamically assigned public IP addresses. Both LAN-to-LAN and remote access peers can use DHCP to obtain a public IP address.

The security appliance uses this address only to initiate the tunnel.

? Peers with dynamically assigned private IP addresses.

Peers requesting remote access tunnels typically have private IP addresses assigned by the headend. Generally, LAN-to-LAN tunnels have a predetermined set of private networks that are used to configure static maps and therefore used to establish IPsec SAs.

Note A dynamic crypto map requires only the transform-set parameter.

Dynamic crypto maps can ease IPsec configuration and we recommend them for use in networks where the peers are not always predetermined. Use dynamic crypto maps for Cisco ××× clients (such as mobile users) and routers that obtain dynamically assigned IP addresses.

Dynamic crypto maps work only to negotiate SAs with remote peers that initiate the connection. The security appliance cannot use dynamic crypto maps to initiate connections to a remote peer

A crypto map set may include a dynamic crypto map. Dynamic crypto map sets should be the lowest priority crypto maps in the crypto map set (that is, they should have the highest sequence numbers) so that the security appliance evaluates other crypto maps first. It examines the dynamic crypto map set only when the other (static) map entries do not match.

Similar to static crypto map sets, a dynamic crypto map set consists of all of the dynamic crypto maps with the same dynamic-map-name. The dynamic-seq-num differentiates the dynamic crypto maps in a set. If you configure a dynamic crypto map, insert a permit ACL to identify the data flow of the IPsec peer for the crypto access list. Otherwise the security appliance accepts any data flow identity the peer proposes.

Caution Do not assign static (default) routes for traffic to be tunneled to a security appliance interface configured with a dynamic crypto map set. To identify the traffic that should be tunneled, add the ACLs to the dynamic crypto map. Use care to identify the proper address pools when configuring the ACLs associated with remote access tunnels. Use Reverse Route Injection to install routes only after the tunnel is up.

The clear configure crypto command includes arguments that let you remove elements of the crypto configuration, including IPsec, crypto maps, dynamic crypto maps, CA trustpoints, all certificates, certificate map configurations, and ISAKMP.

L2TP

Layer 2 Tunneling Protocol (L2TP) is a ××× tunneling protocol which allows remote clients to use the public IP network to securely communicate with private corporate network servers. L2TP uses PPP over UDP (port 1701) to tunnel the data.

L2TP protocol is based on the client/server model. The function is divided between the L2TP Network Server (LNS), and the L2TP Access Concentrator (LAC). The LNS typically runs on a network gateway such as a router, while the LAC can be a dial-up Network Access Server (NAS), or a PC with a bundled L2TP client such as Microsoft Windows 2000.

The primary benefit of configuring L2TP with IPSec in a remote access scenario is that remote users can access a ××× over a public IP network without a gateway or a dedicated line, enabling remote access from virtually anyplace with POTS. An additional benefit is that the only client requirement for ××× access is the use of Windows 2000 with Microsoft Dial-Up Networking (DUN). No additional client software, such as Cisco ××× client software, is required.

To configure L2TP over IPSec, first configure IPSec transport mode to enable IPSec with L2TP. Then configure L2TP with a virtual private dial-up network VPDN group.

The configuration of L2TP with IPSec supports certificates using the pre-shared keys or RSA signature methods, and the use of dynamic (as opposed to static) crypto maps. This summary of tasks assumes completion of IKE, as well as pre-shared keys or RSA signature configuration.

Note L2TP with IPSec on the security appliance allows the LNS to interoperate with the Windows 2000 L2TP client. Interoperability with LACs from Cisco and other vendors is currently not supported. Only L2TP with IPSec is supported, native L2TP itself is not supported on security appliance.

Note The minimum IPSec security association lifetime supported by the Windows 2000 client is 300 seconds. If the lifetime on thesecurity appliance is set to less than 300 seconds, the Windows 2000 client ignores it and replaces it with a 300 second lifetime.

Note L2TP over IPsec sessions are not supported by stateful failover.

However, the Windows 2000 L2TP/IPSec client uses IPSec transport mode-only the IP payload is encrypted, and the original IP headers are left intact. This mode has the advantages of adding only a few bytes to each packet and allowing devices on the public network to see the final source and destination of the packet.

Therefore, In order for Windows 2000 L2TP/IPSec clients to connect to the security appliance, you must configure IPSec transport mode for a transform set using the crypto ipsec transform-set trans_name mode transport command.

Note The security appliance does not establish an L2TP/IPSec tunnel with Windows 2000 if either the Cisco ××× Client Version 3.x or the Cisco ××× 3000 Client Version 2.5 is installed. Disable the Cisco ××× Service for the Cisco ××× Client Version 3.x, or the ANetIKE Service for the Cisco ××× 3000 Client Version 2.5 from the Services panel in Windows 2000 (click Start>Programs>Administrative Tools>Services). Then restart the IPSec Policy Agent Service from the Services panel, and reboot the machine.

Tunnel Group Switching enables the security appliance to associate different users that are establishing L2TP over IPSec connections with different tunnel groups. Since each tunnel group has its own AAA server group and IP address pools, users can be authenticated through methods specific to their tunnel group.

With this feature, instead of sending just a username, the user sends a username and a group name in the format username@group_name, where “@” represents a delimiter that you can configure, and the group name is the name of a tunnel group that has been configured on the security appliance.

×××s work only in single, routed mode. ××× functionality is unavailable in configurations that include either security contexts, also referred to as multi-mode firewall, or Active/Active stateful failover.

The exception to this caveat is that you can configure and use one connection for administrative purposes to (not through) the security appliance in transparent mode.

To permit any packets that come from an IPSec tunnel without checking ACLs for the source and destination interfaces, enter the sysopt connection permit-ipsec command in global configuration mode.

To limit ××× sessions to a lower value than the security appliance allows, enter the ***-sessiondb max-session-limit command in global configuration mode.

? This command applies to all types of ××× sessions, including Web×××.

? This limit affects the calculated load percentage for ××× Load Balancing.

Load Balancing

Note ××× load balancing requires an active 3DES/AES license. The security appliance checks for the existence of this crypto license before enabling load balancing. If it does not detect an active 3DES or AES license, the security appliance prevents the enabling of load balancing and also prevents internal configuration of 3DES by the load balancing system unless the license permits this usage.

To do Web××× load Balancing using FQDNs rather than IP addresse

Groups and users are core concepts in managing the security of virtual private networks (×××s) and in configuring the security appliance. They specify attributes that determine user access to and use of the ×××. A group is a collection of users treated as a single entity. Users get their attributes from group policies. Connection profiles identify the group policy for a specific connection. If you do not assign a particular group policy to a user, the default group policy for the connection applies.

Note You configure connection profiles using tunnel-group commands

Connection profiles and group policies simplify system management. To streamline the configuration task, the security appliance provides a default LAN-to-LAN connection profile, a default remote access connection profile, a default connection profile for clientless SSL ×××, and a default group policy (DfltGrpPolicy). The default connection profiles and group policy provide settings that are likely to be common for many users. As you add users, you can specify that they “inherit” parameters from a group policy. Thus you can quickly configure ××× access for large numbers of users.

The security appliance can apply attribute values from a variety of sources. It applies them according to the following hierarchy:

1. Dynamic Access Policy (DAP) record

2. Username

3. Group policy

4. Group policy for the connection profile

5. Default group policy

Therefore, DAP values for an attribute have a higher priority than those configured for a user, group policy, or connection profile.

When you enable or disable an attribute for a DAP record, the security appliance applies that value and enforces it. For example, when you disable HTTP proxy in dap web*** mode, the security appliance looks no further for a value. When you instead use the no value for the http-proxy command, the attribute is not present in the DAP record, so the security appliance moves down to the AAA attribute in the username, and if necessary, the group policy to find a value to apply. We recommend that you use ASDM to configure DAP.

Connection profiles are local to the security appliance and are not configurable on external servers.

Connection profiles specify the following attributes:

? General Connection Profile Connection Parameters

? IPSec Tunnel-Group Connection Parameters

? Connection Profile Connection Parameters for Clientless SSL ××× Sessions

General Connection Profile Connection Parameters

? Connection profile name

? Connection type

? Authentication, Authorization, and Accounting servers

? Default group policy for the connection

? Client address assignment method

? Override account disabled

? Password management

? Strip group and strip realm

? Authorization required

? Authorization DN attributes

IPSec Tunnel-Group Connection Parameters

IPSec parameters include the following:

? A client authentication method: preshared keys, certificates, or both.

? An extended hybrid authentication method: XAUTH and hybrid XAUTH.

? ISAKMP (IKE) keepalive settings.

Note If you have a LAN-to-LAN configuration using IKE main mode, make sure that the two peers have the same IKE keepalive configuration. Both peers must have IKE keepalives enabled or both peers must have it disabled.

Note In earlier releases, “connection profiles” were known as “tunnel groups.” You configure a connection profile with tunnel-group commands.

You can modify the default connection profiles, and you can configure a new connection profile as any of the three tunnel-group types. If you don’t explicitly configure an attribute in a connection profile, that attribute gets its value from the default connection profile. The default connection-profile type is remote access. The subsequent parameters depend upon your choice of tunnel type. To see the current configured and default configuration of all your connection profiles, including the default connection profile, enter the show running-config all tunnel-group command.

The maximum number of connection profiles (tunnel groups) that an security appliance can support is a function of the maximum number of concurrent ××× sessions for the platform + 5. For example, an ASA5505 can support a maximum of 25 concurrent ××× sessions allowing for 30 tunnel groups (25+5).

The tunnel-group general attributes for clientless SSL ××× connection profiles are the same as those for IPSec remote-access connection profiles, except that the tunnel-group type is web*** and the strip-group and strip-realm commands do not apply. You define the attribute specific to clientless SSL ××× separately.

Group Policies

A group policy is a set of user-oriented attribute/value pairs for IPSec connections that are stored either internally (locally) on the device or externally on a RADIUS server. The connection profile uses a group policy that sets terms for user connections after the tunnel is established. Group policies let you apply whole sets of attributes to a user or a group of users, rather than having to specify each attribute individually for each user.

You can configure internal and external group policies. Internal groups are configured on the security appliance’s internal database. External groups are configured on an external authentication server, such as RADIUS.

Group policies include the following attributes:

? Identity

? Server definitions

? Client firewall settings

? Tunneling protocols

? IPSec settings

? Hardware client settings

? Filters

? Client configuration settings

? Connection settings

this default group policy does not take effect unless you configure the security appliance to use it.

Note External group names on the security appliance refer to user names on the RADIUS server. In other words, if you configure external group X on the security appliance, the RADIUS server sees the query as an authentication request for user X. So external groups are really just user accounts on the RADIUS server that have special meaning to the security appliance. If your external group attributes exist in the same RADIUS server as the users that you plan to authenticate, there must be no name duplication between them.

IPSec over UDP, sometimes called IPSec through NAT, lets a Cisco ××× client or hardware client connect via UDP to a security appliance that is running NAT. It is disabled by default. IPSec over UDP is proprietary; it applies only to remote-access connections, and it requires mode configuration. The security appliance exchanges configuration parameters with the client while negotiating SAs.

If you enabled IPSec over UDP, you must also configure the ipsec-udp-port command in group-policy configuration mode. This command sets a UDP port number for IPSec over UDP. In IPSec negotiations, the security appliance listens on the configured port and forwards UDP traffic for that port even if other filter rules drop UDP traffic. The port numbers can range from 4001 through 49151. The default port value is 10000.

Note The AnyConnect client does not support split DNS.

In group-policy web*** configuration mode, you can specify whether to inherit or customize the following parameters, each of which is described in the subsequent sections:

? customizations

? html-content-filter

? homepage

? filter

? url-list

? port-forward

? port-forward-name

? sso server (single-signon server)

? auto-signon ? deny message

? SSL ××× Client (SVC)

? keep-alive ignore

? HTTP compression

User Attributes

By default, users inherit all user attributes from the assigned group policy. The security appliance also lets you assign individual attributes at the user level, overriding values in the group policy that applies to that user. For example, you can specify a group policy giving all users access during business hours, but give a specific user 24-hour access.

The security appliance can use one or more of the following methods for assigning IP addresses to remote access clients. If you configure more than one address assignment method, the security appliance searches each of the options until it finds an IP address. By default, all methods are enabled. To view the current configuration, enter the show running-config all ***-addr-assign command.

To specify a method for assigning IP addresses to remote access clients, enter the ***-addr-assign command in global configuration mode. The syntax is ***-addr-assign {aaa | dhcp | local}.

ASA support for NAC Framework is limited to remote access IPSec and Web××× client sessions.

The NAC Framework configuration supports only single mode. NAC on the ASA does not support Layer 3 (non-×××) traffic and IPv6 traffic.

The Easy ××× Client supports one of two modes of operation: Client Mode or Network Extension Mode (NEM).

The mode of operation determines whether the inside hosts relative to the Easy ××× Client are accessible from the Enterprise network over the tunnel. Specifying a mode of operation is mandatory before making a connection because Easy ××× Client does not have a default mode.

Client mode, also called Port Address Translation (PAT) mode, isolates the IP addresses of all devices on the Easy ××× Client private network from those on the enterprise network. The Easy ××× Client performs PAT for all ××× traffic for its inside hosts. IP address management is neither required for the Easy ××× Client inside interface or the inside hosts.

NEM makes the inside interface and all inside hosts routeable across the enterprise network over the tunnel. Hosts on the inside network obtain their IP addresses from an accessible subnet (statically or via DHCP) pre-configured with static IP addresses. PAT does not apply to ××× traffic in NEM. This mode does not require a ××× configuration for each client. The Cisco ASA 5505 configured for NEM mode supports automatic tunnel initiation. The configuration must store the group name, user name, and password. Automatic tunnel initiation is disabled if secure unit authentication is enabled.

Note If the Easy ××× hardware client is using NEM and has connections to secondary servers, use the crypto map set reverse-route command on each headend device to configure dynamic announcements of the remote network using Reverse Route Injection (RRI).

To specify the mode for Easy ××× Clients, enter the following command in configuration mode:

[no] ***client mode {client-mode | network-extension-mode}

no removes the command from the running configuration.

If you have an ASA 5505 security appliance (version 7.2 (3) and higher) configured as an Easy ××× Client in Network Extension Mode with multiple interfaces configured, the security appliance builds a tunnel for locally encrypted traffic only from the interface with the highest security level.

By default, the Easy ××× hardware client and server encapsulate IPSec in User Datagram Protocol (UDP) packets. Some environments, such as those with certain firewall rules, or NAT and PAT devices, prohibit UDP. To use standard Encapsulating Security Protocol (ESP, Protocol 50) or Internet Key Exchange (IKE, UDP 500) in such environments, you must configure the client and the server to encapsulate IPSec within TCP packets to enable secure tunneling. If your environment allows UDP, however, configuring IPSec over TCP adds unnecessary overhead.

To configure the Easy ××× hardware client to use TCP-encapsulated IPSec, enter the following command in global configuration mode:

***client ipsec-over-tcp [port tcp_port]

The Easy ××× hardware client uses port 10000 if the command does not specify a port number.

The next example shows how to configure the Easy ××× hardware client to use TCP-encapsulated IPSec, using the port 10501, and to let it send large packets over the outside interface:

hostname(config)# ***client ipsec-over-tcp port 10501

hostname(config)# crypto ipsec df-bit clear-df outside

Caution Cisco does not support the use of the ***client management command if a NAT device is present between the client and the Internet.

The tunnel types the Cisco ASA 5505 configured as an Easy ××× hardware client sets up depends on a combination of the following factors:

? Use of the split-tunnel-network-list and the split-tunnel-policy commands on the headend to permit, restrict, or prohibit split tunneling.

? Use of the ***client management command to specify one of the following automatic tunnel initiation options:tunnel ，clear ，no 。

? Use of the ***client mode command to specify one of the following modes of operation:

When configuring the Cisco ASA 5505 as an Easy ××× hardware client, you can specify a tunnel group or trustpoint configured on the Easy ××× server, depending on the Easy ××× server configuration. See the section that names the option you want to use:

? Specifying the Tunnel Group

? Specifying the Trustpoint

Enter the following command in global configuration mode to specify the name of the ××× tunnel group and password for the Easy ××× client connection to the server: ***client ***group group_name password preshared_key

Enter the following command in global configuration mode to enable the automatic initiation of IPSec tunnels when NEM and split tunneling are configured: [no] ***client nem-st-autoconnect

Caution Do not configure a management tunnel on a Cisco ASA 5505 configured as an Easy ××× hardware client if a NAT device is operating between the Easy ××× hardware client and the Internet. In that configuration, use the ***client management clear command.

For example, enter the following command to automate the creation of an IPSec tunnel to provide management access to the host with IP address 192.168.10.10:

hostname(config)# ***client management tunnel 192.198.10.10 255.255.255.0

Easy ××× hardware client considerations that apply to the Easy ××× server:

? Group Policy and User Attributes Pushed to the Client

? Authentication Options

Note IPSec NAT-T connections are the only IPSec connection types supported on the home VLAN of a Cisco ASA 5505. IPSec over TCP and native IPSec connections are not supported.

PPPoE is composed of two main phases:

? Active Discovery Phase-In this phase, the PPPoE client locates a PPPoE server, called an access concentrator. During this phase, a Session ID is assigned and the PPPoE layer is established.

? PPP Session Phase-In this phase, PPP options are negotiated and authentication is performed. Once the link setup is completed, PPPoE functions as a Layer 2 encapsulation method, allowing data to be transferred over the PPP link within PPPoE headers.

At system initialization, the PPPoE client establishes a session with the access concentrator by exchanging a series of packets. Once the session is established, a PPP link is set up, which includes authentication using Password Authentication protocol (PAP). Once the PPP session is established, each packet is encapsulated in the PPPoE and PPP headers.

Note PPPoE is not supported when failover is configured on the security appliance, or in multiple context or transparent mode. PPPoE is only supported in single, routed mode, without failover.

PPPoE is not supported in conjunction with DHCP because with PPPoE the IP address is assigned by PPP. The setroute option causes a default route to be created if no default route exists. The default router is the address of the access concentrator. The maximum transmission unit (MTU) size is automatically set to 1492 bytes, which is the correct value to allow PPPoE transmission within an Ethernet frame.

Note If you have multiple VPDN groups configured, and you do not specify a group with the pppoe client vpdn group command, the security appliance may randomly choose a VPDN group. To avoid this, specify a VPDN group.

Note The setroute option is an option of the ip address command that you can use to allow the access concentrator to set the default routes when the PPPoE client has not yet established a connection. When using the setroute option, you cannot have a statically defined route in the configuration.