小菜ASA 学习笔记（一）

8.0从8.0(2)开始，没有8.0(1)web

8.0(2)redis

开始支持EIGRP，Redundant interfaces ，Failover pair Auto Update support ，Remote command execution in Failover pairs ,threat detection,透墙NAT，管理链接限制，AIP SSM模块开始支持虚拟sensor，ASA支持安全日志（PIX不支持）等。安全

Some of the benefits of NAT include the following: cookie

? You can use private addresses on your inside networks. Private addresses are not routable on the Internet. session

? NAT hides the local addresses from other networks, so attackers cannot learn the real address of a host. ? NAT can resolve IP routing problems by supporting overlapping IP addresses. app

The security appliance runs in two different firewall modes: ? Routed ? Transparentless

? Is this a new connection?dom

If it is a new connection, the security appliance has to check the packet against access lists and perform other tasks to determine if the packet is allowed or denied. To perform this check, the first packet of the session goes through the “session management path,” and depending on the type of traffic, it might also pass through the “control plane path.” The session management path is responsible for the following tasks:ide

- Performing the access list checksoop

- Performing route lookups

- Allocating NAT translations (xlates)

- Establishing sessions in the “fast path”

Note The session management path and the fast path make up the “accelerated security path.”

Some packets that require Layer 7 inspection (the packet payload must be inspected or altered) are passed on to the control plane path.

? Is this an established connection?

If the connection is already established, the security appliance does not need to re-check packets; most matching packets can go through the fast path in both directions. The fast path is responsible for the following tasks:

- IP checksum verification

- Session lookup

- TCP sequence number check

- NAT translations based on existing sessions

- Layer 3 and Layer 4 header adjustments

For UDP or other connectionless protocols, the security appliance creates connection state information so that it can also use the fast path.

Data packets for protocols that require Layer 7 inspection can also go through the fast path. Some established session packets must continue to go through the session management path or the control plane path. Packets that go through the session management path include HTTP packets that require inspection or content filtering. Packets that go through the control plane path include the control packets for protocols that require Layer 7 inspection.

The admin context is just like any other context, except that when a user logs into the admin context, then that user has system administrator rights and can access the system and all other contexts.

For the PIX 515/515E and the ASA 5510 and higher security appliances, the factory default configuration configures an interface for management so you can connect to it using ASDM, with which you can then complete your configuration.

For the ASA 5505 adaptive security appliance, the factory default configuration configures interfaces and NAT so that the security appliance is ready to use in your network immediately.

The factory default configuration is available only for routed firewall mode and single context mode.

To restore the factory default configuration, enter the following command:

hostname(config)# configure factory-default [ip_address [mask]]

This command also clears the boot system command, if present, along with the rest of the configuration. The boot system command lets you boot from a specific image, including an image on the external Flash memory card. The next time you reload the security appliance after restoring the factory configuration, it boots from the first image in internal Flash memory; if you do not have an image in internal Flash memory, the security appliance does not boot.

For multiple context mode, you can use only one firewall mode for all contexts. You must set the mode in the system execution space.

When you change modes, the security appliance clears the configuration because many commands are not supported for both modes. If you already have a populated configuration, be sure to back up your configuration before changing the mode; you can use this backup for reference when creating your new configuration.

? To set the mode to transparent, enter the following command in the system execution space: hostname(config)# firewall transparent

This command also appears in each context configuration for informational purposes only; you cannot enter this command in a context.

? To set the mode to routed, enter the following command in the system execution space:

hostname(config)# no firewall transparent

To save the system or context configuration, enter the following command within the system or context: hostname# write memory

For multiple context mode, context startup configurations can reside on external servers. In this case, the security appliance saves the configuration back to the server you identified in the context URL, except for an HTTP or HTTPS URL, which do not let you save the configuration to the server.

To save all context configurations at the same time, as well as the system configuration, enter the following command in the system execution space:

hostname# write memory all [/noconfirm]

保存的时候可能会出现问题，具体看P74

You cannot use Active/Active failover and ×××; if you want to use ×××, use Active/Standby failover.

pix不支持SSL ×××，不能作××× load blance。

多墙不支持feature：

? Dynamic routing protocols （只支持static路由）

? ×××

? Multicast routing. Multicast bridging is supported.

? Threat Detection

? QoS

The system configuration does not include any network interfaces or network settings for itself; rather, when the system needs to access network resources (such as downloading the contexts from the server), it uses one of the contexts that is designated as the admin context. The system configuration does include a specialized failover interface for failover traffic only.

Note If the destination MAC address is a multicast or broadcast MAC address, the packet is duplicated and delivered to each context.

Unique Interfaces If only one context is associated with the ingress interface, the security appliance classifies the packet into that context. In transparent firewall mode, unique interfaces for contexts are required, so this method is used to classify packets at all times.

Unique MAC Addresses If multiple contexts share an interface, then the classifier uses the interface MAC address. The security appliance lets you assign a different MAC address in each context to the same shared interface, whether it is a shared physical interface or a shared subinterface. By default, shared interfaces do not have unique MAC addresses; the interface uses the physical interface burned-in MAC address in every context. An upstream router cannot route directly to a context without unique MAC addresses. You can set the MAC addresses manually when you configure each interface , or you can automatically generate MAC addresses 。

NAT Configuration If you do not have unique MAC addresses, then the classifier intercepts the packet and performs a destination IP address lookup. All other fields are ignored; only the destination IP address is used. To use the destination address for classification, the classifier must have knowledge about the subnets located behind each security context. The classifier relies on the NAT configuration to determine the subnets in each context. The classifier matches the destination IP address to either a static command or a global command.

The following configurations are not used for packet classification:

? NAT exemption-The classifier does not use a NAT exemption configuration for classification purposes because NAT exemption does not identify a mapped interface.

? Routing table-If a context includes a static route that points to an external router as the next-hop to a subnet, and a different context includes a static command for the same subnet, then the classifier uses the static command to classify packets destined for that subnet and ignores the static route.

Note If you share an inside interface and do not use unique MAC addresses, the classifier imposes some major restrictions. The classifier relies on the address translation configuration to classify the packet within a context, and you must translate the destination addresses of the traffic. Because you do not usually perform NAT on outside addresses, sending packets from inside to outside on a shared interface is not always possible; the outside network is large, (the Web, for example), and addresses are not predictable for an outside NAT configuration. If you share an inside interface, we suggest you use unique MAC addresses.

For transparent firewalls, you must use unique interfaces.

Placing a context directly in front of another context is called cascading contexts; the outside interface of one context is the same interface as the inside interface of another context.

Note Cascading contexts requires that you configure unique MAC addresses for each context interface. Because of the limitations of classifying packets on shared interfaces without MAC addresses, we do not recommend using cascading contexts without unique MAC addresses.

System Administrator Access

You can access the security appliance as a system administrator in two ways:

? Access the security appliance console.

? Access the admin context using Telnet, SSH, or ASDM.

As the system administrator, you can access all contexts.

When you change to a context from admin or the system, your username changes to the default “enable_15” username. If you configured command authorization in that context, you need to either configure authorization privileges for the “enable_15” user, or you can log in as a different name for which you provide sufficient privileges in the command authorization configuration for the context. To log in with a username, enter the login command. For example, you log in to the admin context with the username “admin.” The admin context does not have any command authorization configuration, but all other contexts include command authorization. For convenience, each context configuration includes a user “admin” with maximum privileges. When you change from the admin context to context A, your username is altered, so you must log in again as “admin” by entering the login command. When you change to context B, you must again enter the login command to log in as “admin.”

The system execution space does not support any AAA commands, but you can configure its own enable password, as well as usernames in the local database to provide individual logins.

Context Administrator Access

You can access a context using Telnet, SSH, or ASDM. If you log in to a non-admin context, you can only access the configuration for that context. You can provide individual logins to the context.

Enabling or Disabling Multiple Context Mode

ASDM does not support changing modes, so you need to change modes using the CLI.

When you convert from single mode to multiple mode, the security appliance converts the running configuration into two files. The original startup configuration is not saved, so if it differs from the running configuration, you should back it up before proceeding.

The context mode (single or multiple) is not stored in the configuration file, even though it does endure reboots. If you need to copy your configuration to another device, set the mode on the new device to match using the mode command.

When you convert from single mode to multiple mode, the security appliance converts the running configuration into two files: a new startup configuration that comprises the system configuration, and admin.cfg that comprises the admin context (in the root directory of the internal Flash memory). The original running configuration is saved as old_running.cfg (in the root directory of the internal Flash memory). The original startup configuration is not saved. The security appliance automatically adds an entry for the admin context to the system configuration with the name “admin.”

To enable multiple mode, enter the following command:

hostname(config)# mode multiple

You are prompted to reboot the security appliance.

If you convert from multiple mode to single mode, you might want to first copy a full startup configuration (if available) to the security appliance; the system configuration inherited from multiple mode is not a complete functioning configuration for a single mode device. Because the system configuration does not have any network interfaces as part of its configuration, you must access the security appliance from the console to perform the copy. To copy the old running configuration to the startup configuration and to change the mode to single mode, perform the following steps in the system execution space:

hostname(config)# copy flash:old_running.cfg startup-config

hostname(config)# mode single

The security appliance reboots.

The security appliance（5505） interfaces do not support jumbo frames.

Note Subinterfaces are not available for the ASA 5505 adaptive security appliance.

If you are using failover, do not use this procedure to name interfaces that you are reserving for failover communications.

If you change the security level of an interface, and you do not want to wait for existing connections to time out before the new security information is used, you can clear the connections using the clear local-host command.

接口nameif不区分大小写。

To assign a private MAC address to this interface, enter the following command:

hostname(config-if)# mac-address mac_address [standby mac_address]

By default in routed mode, all VLANs use the same MAC address. In transparent mode, the VLANs use unique MAC addresses. You might want to set unique VLANs or change the generated VLANs if your switch requires it, or for access control purposes.

The ASA 5505 adaptive security appliance does not support Spanning Tree Protocol for loop detection in the network. Therefore you must ensure that any connection with the adaptive security appliance does not end up in a network loop.

You might want to prevent switch ports from communicating with each other if the devices on those switch ports are primarily accessed from other VLANs, you do not need to allow intra-VLAN access, and you want to isolate the devices from each other in case of infection or other security breach. For example, if you have a DMZ that hosts three web servers, you can isolate the web servers from each other if you apply the switchport protected command to each switch port. The inside and outside networks can both communicate with all three web servers, and vice versa, but the web servers cannot communicate with each other

The ASA 5500 management interface is a Fast Ethernet interface designed for management traffic only, and is specified as management0/0. You can, however, use it for through traffic if desired (see the management-only command). In transparent firewall mode, you can use the management interface (for management purposes) in addition to the two interfaces allowed for through traffic. You can also add subinterfaces to the management interface to provide management in each security context for multiple context mode.

If you enter the shutdown command, you also shut down all subinterfaces. If you shut down an interface in the system execution space, then that interface is shut down in all contexts that share it.

To use the fiber SFP connectors, you must set the media type to SFP. The fiber interface has a fixed speed and does not support duplex, but you can set the interface to negotiate link parameters (the default) or not to negotiate

hostname(config-if)# media-type sfp

To restore the default RJ-45, enter the media-type rj45 command.

hostname(config-if)# speed nonegotiate

The default is no speed nonegotiate, which sets the speed to 1000 Mbps and enables link negotiation for flow-control parameters and remote fault information. The speed nonegotiate command disables link negotiation.

Follow these guidelines when adding member interfaces:

? If you want to use a redundant interface for the failover or state link, then you must configure the redundant interface as part of the basic configuration on the secondary unit in addition to the primary unit.

? If you use a redundant interface for the failover or state link, you must put a switch or hub between the two units; you cannot connect them directly. Without the switch or hub, you could have the active port on the primary unit connected directly to the standby port on the secondary unit.

? You can monitor redundant interfaces for failover using the monitor-interface command; be sure to reference the logical redundant interface name.

? When the active interface fails over to the standby interface, this activity does not cause the redundant interface to appear to be failed when being monitored for device-level failover. Only when both physical interfaces fail does the redundant interface appear to be failed.

? Redundant interface delay values are configurable, but by default the unit will inherit the default delay values based on the physical type of its member interfaces.

The redundant interface uses the MAC address of the first physical interface that you add. If you change the order of the member interfaces in the configuration, then the MAC address changes to match the MAC address of the interface that is now listed first. Alternatively, you can assign a MAC address to the redundant interface, which is used regardless of the member interface MAC addresses

Follow these guidelines when adding member interfaces:

? Both member interfaces must be of the same physical type. For example, both must be Ethernet.

? You cannot add a physical interface to the redundant interface if you configured a name for it. You must first remove the name using the no nameif command.

? The only configuration available to physical interfaces that are part of a redundant interface pair are physical parameters

? If you shut down the active interface, then the standby interface becomes active.

Caution If you are using a physical interface already in your configuration, removing the name will clear any configuration that refers to the interface.

The following example creates two redundant interfaces:

hostname(config)# interface redundant 1

hostname(config-if)# member-interface gigabitethernet 0/0

hostname(config-if)# member-interface gigabitethernet 0/1

Subinterfaces let you divide a physical or redundant interface into multiple logical interfaces that are tagged with different VLAN IDs. An interface with one or more VLAN subinterfaces is automatically configured as an 802.1Q trunk. Because VLANs allow you to keep traffic separate on a given physical interface, you can increase the number of interfaces available to your network without adding additional physical interfaces or security appliances. This feature is particularly useful in multiple context mode so that you can assign unique interfaces to each context.

If you use subinterfaces, you typically do not also want the physical interface to pass traffic, because the physical interface passes untagged packets. This property is also true for the active physical interface in a redundant interface pair. Because the physical or redundant interface must be enabled for the subinterface to pass traffic, ensure that the physical or redundant interface does not pass traffic by leaving out the nameif command. If you want to let the physical or redundant interface pass untagged packets, you can configure the nameif command as usual

You can only assign a single VLAN to a subinterface, and you cannot assign the same VLAN to multiple subinterfaces. You cannot assign a VLAN to the physical interface. Each subinterface must have a VLAN ID before it can pass traffic. To change a VLAN ID, you do not need to remove the old VLAN ID with the no option; you can enter the vlan command with a different VLAN ID, and the security appliance changes the old ID.

By default, all security contexts have unlimited access to the resources of the security appliance, except where maximum limits per context are enforced. However, if you find that one or more contexts use too many resources, and they cause other contexts to be denied connections, for example, then you can configure resource management to limit the use of resources per context.

All contexts belong to the default class if they are not assigned to another class; you do not have to actively assign a context to the default class. If a context belongs to a class other than the default class, those class settings always override the default class settings. However, if the other class has any settings that are not defined, then the member context uses the default class for those limits. For example, if you create a class with a 2 percent limit for all concurrent connections, but no other limits, then all other limits are inherited from the default class. Conversely, if you create a class with a limit for all resources, the class uses no settings from the default class.

By default, the default class provides unlimited access to resources for all contexts, except for the following limits, which are by default set to the maximum allowed per context:

? Telnet sessions -5 sessions.

? SSH sessions -5 sessions.

? IPSec sessions -5 sessions.

? MAC addresses -65,535 entries.

The security context definition in the system configuration identifies the context name, configuration file URL, and interfaces that a context can use.

Note If you do not have an admin context (for example, if you clear the configuration) then you must first specify the admin context name by entering the following command: hostname(config)# admin-context name

Note The management interface for transparent mode does not flood a packet out the interface when that packet is not in the MAC address table.

You can assign the same interfaces to multiple contexts in routed mode, if desired. Transparent mode does not allow shared interfaces.

When you add a context URL, the system immediately loads the context so that it is running, if the configuration is available.

Note Enter the allocate-interface command(s) before you enter the config-url command. The security appliance must assign interfaces to the context before it loads the context configuration; the context configuration might include commands that refer to interfaces (interface, nat, global...). If you enter the config-url command first, the security appliance loads the context configuration immediately. If the context contains any commands that refer to interfaces, those commands fail.

Note The admin context file must be stored on the internal Flash memory.

To allow contexts to share interfaces, we suggest that you assign unique MAC addresses to each context interface. The MAC address is used to classify packets within a context. If you share an interface, but do not have unique MAC addresses for the interface in each context, then the destination IP address is used to classify packets. The destination address is matched with the context NAT configuration, and this method has some limitations compared to the MAC address method.

By default, the physical interface uses the burned-in MAC address, and all subinterfaces of a physical interface use the same burned-in MAC address. You can automatically assign private MAC addresses to each shared context interface by entering the following command in the system configuration: hostname(config)# mac-address auto

For use with failover, the security appliance generates both an active and standby MAC address for each interface. If the active unit fails over and the standby unit becomes active, the new active unit starts using the active MAC addresses to minimize network disruption.

If you log in to the system execution space (or the admin context using Telnet or SSH), you can change between contexts and perform configuration and monitoring tasks within each context. The running configuration that you edit in a configuration mode, or that is used in the copy or write commands, depends on your location. When you are in the system execution space, the running configuration consists only of the system configuration; when you are in a context, the running configuration consists only of that context.

? To change to a context, enter the following command:

hostname# changeto context name

The prompt changes to the following: hostname/name#

? To change to the system execution space, enter the following command:

hostname/admin# changeto system

The prompt changes to the following: hostname#

You can only remove a context by editing the system configuration. You cannot remove the current admin context, unless you remove all contexts using the clear context command

Note If you use failover, there is a delay between when you remove the context on the active unit and when the context is removed on the standby unit. You might see an error message indicating that the number of interfaces on the active and standby units are not consistent; this error is temporary and can be ignored.

? To remove a single context, enter the following command in the system execution space:

hostname(config)# no context name

? To remove all contexts (including the admin context), enter the following command in the system execution space:

hostname(config)# clear context

The system configuration does not include any network interfaces or network settings for itself; rather, when the system needs to access network resources (such as downloading the contexts from the server), it uses one of the contexts that is designated as the admin context. The admin context is just like any other context, except that when a user logs in to the admin context, then that user has system administrator rights and can access the system and all other contexts. The admin context is not restricted in any way, and can be used as a regular context. However, because logging into the admin context grants you administrator privileges over all contexts, you might need to restrict access to the admin context to appropriate users. You can set any context to be the admin context, as long as the configuration file is stored in the internal Flash memory. To set the admin context, enter the following command in the system execution space:

hostname(config)# admin-context context_name

Any remote management sessions, such as Telnet, SSH, or HTTPS, that are connected to the admin context are terminated. You must reconnect to the new admin context.

Note A few system commands, including ntp server, identify an interface name that belongs to the admin context. If you change the admin context, and that interface name does not exist in the new admin context, be sure to update any system commands that refer to the interface.

You cannot change the security context URL without reloading the configuration from the new URL. The security appliance merges the new configuration with the current running configuration. Reentering the same URL also merges the saved configuration with the running configuration. A merge adds any new commands from the new configuration to the running configuration. If the configurations are the same, no changes occur. If commands conflict or if commands affect the running of the context, then the effect of the merge depends on the command. You might get errors, or you might have unexpected results. If the running configuration is blank (for example, if the server was unavailable and the configuration was never downloaded), then the new configuration is used. If you do not want to merge the configurations, you can clear the running configuration, which disrupts any communications through the context, and then reload the configuration from the new URL.

You can reload the context in two ways:

? Clear the running configuration and then import the startup configuration. This action clears most attributes associated with the context, such as connections and NAT tables.

? Remove the context from the system configuration. This action clears additional attributes, such as memory allocation, which might be useful for troubleshooting. However, to add the context back to the system requires you to respecify the URL and interfaces.

From the system execution space, view the resource usage for each context by entering the following command:

hostname# show resource usage [context context_name | top n | all | summary | system] [resource {resource_name | all} | detail] [counter counter_name [count_threshold]]

The security appliance prevents SYN attacks using TCP Intercept. TCP Intercept uses the SYN cookies algorithm to prevent TCP SYN-flooding attacks.

In single mode or in the system execution space, interfaces have the following default states:

? Physical interfaces-Disabled.

? Redundant Interfaces-Enabled. However, for traffic to pass through the redundant interface, the member physical interfaces must also be enabled.

? Subinterfaces-Enabled. However, for traffic to pass through the subinterface, the physical interface must also be enabled.

However, you can configure any interface to be a management-only interface using the management-only command. Also, for Management 0/0, you can disable management-only mode so the interface can pass through traffic just like any other interface.

Note In multiple context mode, set the time in the system configuration only.

the Management IP Address for a Transparent Firewall This address must be on the same subnet as the upstream and downstream routers. You cannot set the subnet to a host subnet (255.255.255.255). This address must be IPv4; the transparent firewall does not support IPv6.

The ASA security appliance uses both routing table and XLATE tables for routing decisions. To handle destination IP translated traffic, that is, untranslated traffic, ASA searches for existing XLATE, or static translation to select the egress interface. The selection process is as follows:

Egress Interface Selection Process

1. If destination IP translating XLATE already exists, the egress interface for the packet is determined from the XLATE table, but not from the routing table.

2. If destination IP translating XLATE does not exist, but a matching static translation exists, then the egress interface is determined from the static route and an XLATE is created, and the routing table is not used.

3. If destination IP translating XLATE does not exist and no matching static translation exists, the packet is not destination IP translated. The security appliance processes this packet by looking up the route to select egress interface, then source IP translation is performed (if necessary). For regular dynamic outbound NAT, initial outgoing packets are routed using the route table and then creating the XLATE. Incoming return packets are forwarded using existing XLATE only. For static NAT, destination translated incoming packets are always forwarded using existing XLATE or static translation rules.

Next Hop Selection Process

After selecting egress interface using any method described above, an additional route lookup is performed to find out suitable next hop(s) that belong to previously selected egress interface. If there are no routes in routing table that explicitly belong to selected interface, the packet is dropped with level 6 error message 110001 "no route to host", even if there is another route for a given destination network that belongs to different egress interface. If the route that belongs to selected egress interface is found, the packet is forwarded to corresponding next hop.

Load sharing on the security appliance is possible only for multiple next-hops available using single egress interface. Load sharing cannot share multiple egress interfaces.

If dynamic routing is in use on security appliance and route table changes after XLATE creation, for example route flap, then destination translated traffic is still forwarded using old XLATE, not via route table, until XLATE times out.

Multiple context mode does not support dynamic routing, so you must use static routes for any networks to which the security appliance is not directly connected; for example, when there is a router between a network and the security appliance.

The security appliance supports up to three equal cost routes on the same interface for load balancing.

Static routes remain in the routing table even if the specified gateway becomes unavailable. If the specified gateway becomes unavailable, you need to remove the static route from the routing table manually. However, static routes are removed from the routing table if the specified interface goes down. They are reinstated when the interface comes back up.

You can define up to three equal cost routes to the same destination per interface. traffic is distributed among the specified gateways based on an algorithm that hashes the source and destination IP addresses.

One of the problems with static routes is that there is no inherent mechanism for determining if the route is up or down. They remain in the routing table even if the next hop gateway becomes unavailable. Static routes are only removed from the routing table if the associated interface on the security appliance goes down.

The static route tracking feature provides a method for tracking the availability of a static route and installing a backup route if the primary route should fail. This allows you to, for example, define a default route to an ISP gateway and a backup default route to a secondary ISP in case the primary ISP becomes unavailable.

When selecting a monitoring target, you need to make sure it can respond to ICMP echo requests. The target can be any network object that you choose, but you should consider using:

? the ISP gateway (for dual ISP support) address

? the next hop gateway address (if you are concerned about the availability of the gateway)

? a server on the target network, such as a AAA server, that the security appliance needs to communicate with

? a persistent network object on the destination network (a desktop or notebook computer that may be shut down at night is not a good choice)

You can configure static route tracking for statically defined routes or default routes obtained through DHCP or PPPoE. You can only enable PPPoE clients on multiple interface with route tracking.

The security appliance can run two processes of OSPF protocol simultaneously, on different sets of interfaces. You might want to run two processes if you have interfaces that use the same IP addresses (NAT allows these interfaces to coexist, but OSPF does not allow overlapping addresses). Or you might want to run one process on the inside, and another on the outside, and redistribute a subset of routes between the two processes. Similarly, you might need to segregate private addresses from public addresses

Note EIGRP neighbor relationships are not supported through the IPSec tunnel without a GRE tunnel.

On the ASA 5505 adaptive security appliance, the following route is also shown. It is the internal loopback interface, which is used by the ××× hardware client feature for individual user authentication.

C 127.1.0.0 255.255.0.0 is directly connected, _internal_loopback

The security appliance can provide a DHCP server or DHCP relay services to DHCP clients attached to security appliance interfaces.

DDNS update integrates DNS with DHCP. The two protocols are complementary: DHCP centralizes and automates IP address allocation; DDNS update automatically records the association between assigned addresses and hostnames at pre-defined intervals. DDNS allows frequently changing address-hostname associations to be updated frequently. Mobile hosts, for example, can then move freely on a network without user or administrator intervention. DDNS provides the necessary dynamic updating and synchronizing of the name to address and address to name mappings on the DNS server.

In multiple context mode, you cannot enable the DHCP server or DHCP relay on an interface that is used by more than one context.

You can configure a DHCP server on each interface of the security appliance. Each interface can have its own pool of addresses to draw from. However the other DHCP settings, such as DNS servers, domain name, options, ping timeout, and WINS servers, are configured globally and used by the DHCP server on all interfaces.

You cannot configure a DHCP client or DHCP Relay services on an interface on which the server is enabled. Additionally, DHCP clients must be directly connected to the interface on which the server is enabled.

Cisco IP Phones download their configuration from a TFTP server. When a Cisco IP Phone starts, if it does not have both the IP address and TFTP server IP address preconfigured, it sends a request with option 150 or 66 to the DHCP server to obtain this information.

? DHCP option 150 provides the IP addresses of a list of TFTP servers.

? DHCP option 66 gives the IP address or the hostname of a single TFTP server.

Cisco IP Phones might also include DHCP option 3 in their requests, which sets the default route.

You can configure the security appliance to send information for most options listed in RFC 2132.

The following restrictions apply to the use of the DHCP relay agent:

? The relay agent cannot be enabled if the DHCP server feature is also enabled.

? DHCP clients must be directly connected to the security appliance and cannot send requests through another relay agent or a router.

? For multiple context mode, you cannot enable DHCP relay on an interface that is used by more than one context.

? DHCP Relay services are not available in transparent firewall mode. A security appliance in transparent firewall mode only allows ARP traffic through; all other traffic requires an access list. To allow DHCP requests and replies through the security appliance in transparent mode, you need to configure two access lists, one that allows DCHP requests from the inside interface to the outside, and one that allows the replies from the server in the other direction.

? When DHCP relay is enabled and more than one DHCP relay server is defined, the security appliance forwards client requests to each defined DHCP relay server. Replies from the servers are also forwarded to the client until the client DHCP relay binding is removed. The binding is removed when the security appliance receives any of the following DHCP messages: ACK, NACK, or decline.

The purpose of web caching is to reduce latency and network traffic. Previously-accessed web pages are stored in a cache buffer, so if a user needs the page again, they can retrieve it from the cache instead of the web server.

WCCP specifies interactions between the security appliance and external web caches. The feature transparently redirects selected types of traffic to a group of web cache engines to optimize resource usage and lower response times. The security appliance only supports WCCP version 2.

Using a security appliance as an intermediary eliminates the need for a separate router to do the WCCP redirect because the security appliance takes care of redirecting requests to cache engines. When the security appliance knows when a packet needs redirection, it skips TCP state tracking, TCP sequence number randomization, and NAT on these traffic flows.

The following WCCPv2 features are supported with the security appliance:

? Redirection of multiple TCP/UDP port-destined traffic.

? Authentication for cache engines in a service group.

The following WCCPv2 features are not supported with the security appliance:

? Multiple routers in a service group is not supported. Multiple Cache Engines in a service group is still supported.

? Multicast WCCP is not supported.

? The Layer 2 redirect method is not supported; only GRE encapsulation is supported.

? WCCP source address spoofing.

In the security appliance implementation of WCCP, the following applies as to how the protocol interacts with other configurable features:

? An ingress access list entry always takes higher priority over WCCP. For example, if an access list does not permit a client to communicate with a server then traffic will not be redirected to a cache engine. Both ingress interface access lists and egress interface access lists will be applied.

? TCP intercept, authorization, URL filtering, inspect engines, and IPS features are not applied to a redirected flow of traffic.

? When a cache engine cannot service a request and packet is returned, or when a cache miss happens on a cache engine and it requests data from a web server, then the contents of the traffic flow will be subject to all the other configured features of the security appliance.

? In failover, WCCP redirect tables are not replicated to standby units. After a failover, packets will not be redirected until the tables are rebuilt. Sessions redirected prior to failover will likely be reset by the web server.

Note Stub Multicast Routing and PIM are not supported concurrently.

Note PIM is not supported with PAT. The PIM protocol does not use ports and PAT only works with protocols that use ports.

Note The security appliance does not support Auto-RP or PIM BSR; you must use the pim rp-address command to specify the RP address.

Note Failover does not support IPv6.

RADIUS Server Support

The ASA supports the following RADIUS servers for AAA, in addition to the one available on the ASA itself:

? Cisco Secure ACS 3.2, 4.0, 4.1

? RSA Radius in RSA Authentication Manager 5.2 & 6.1

The security appliance supports the following authentication methods with RADIUS:

? PAP-For all connection types.

? CHAP-For L2TP-over-IPSec. ? MS-CHAPv1-For L2TP-over-IPSec.

? MS-CHAPv2-For L2TP-over-IPSec, and for regular IPSec remote access connections when the password-management feature is enabled. You can also use MS-CHAPv2 with Clientless connections. ? Authentication Proxy modes-Including RADIUS to Active Directory, RADIUS to RSA/SDI, RADIUS to Token-server, and RSA/SI to RADIUS,

Note To enable MSChapV2 as the protocol used between the security appliance and the RADIUS server for a clientless connection, password management must be enabled in the tunnel-group general-attributes. Enabling password management prevents usernames and passwords from being transmitted in clear text between the security appliance and the RADIUS server.

The security appliance can use RADIUS servers for user authorization for network access using dynamic access lists or access list names per user. To implement dynamic access lists, you must configure the RADIUS server to support it. When the user authenticates, the RADIUS server sends a downloadable access list or access list name to the security appliance. Access to a given service is either permitted or denied by the access list. The security appliance deletes the access list when the authentication session expires.

TACACS+ Server Support

The security appliance supports TACACS+ authentication with ASCII, PAP, CHAP, and MS-CHAPv1.

Kerberos Server Support

The security appliance supports 3DES, DES, and RC4 encryption types.

Note The security appliance does not support changing user passwords during tunnel negotiation. To avoid this situation happening inadvertently, disable password expiration on the Kerberos/Active Directory server for users connecting to the security appliance.

SSO Support for Clientless SSL ××× with HTTP Forms

The security appliance can use the HTTP Form protocol for single sign-on (SSO) authentication of Clientless SSL ××× users only. Single sign-on support lets Clientless SSL ××× users enter a username and password only once to access multiple protected services and Web servers. The Clientless SSL ××× server running on the security appliance acts as a proxy for the user to the authenticating server. When a user logs in, the Clientless SSL ××× server sends an SSO authentication request, including username and password, to the authenticating server using HTTPS. If the server approves the authentication request, it returns an SSO authentication cookie to the Clientless SSL ××× server. The security appliance keeps this cookie on behalf of the user and uses it to authenticate the user to secure websites within the domain protected by the SSO server.

Note When the security appliance is configured for Active/Active stateful failover, you cannot enable IPSec or SSL ×××. Therefore, these features are unavailable. ××× failover is available for Active/Standby failover configurations only.

The two units in a failover configuration must have the same hardware configuration. They must be the same model, have the same number and types of interfaces, the same amount of RAM, and, for the ASA 5500 series security appliance, the same SSMs installed (if any).

Note The two units do not have to have the same size Flash memory. If using units with different Flash memory sizes in your failover configuration, make sure the unit with the smaller Flash memory has enough space to accommodate the software image files and the configuration files. If it does not, configuration synchronization from the unit with the larger Flash memory to the unit with the smaller Flash memory will fail.

The two units in a failover configuration must be in the operating modes (routed or transparent, single or multiple context). They have the same major (first number) and minor (second number) software version. However, you can use different versions of the software during an upgrade process; for example, you can upgrade one unit from Version 7.0(1) to Version 7.0(2) and have failover remain active. We recommend upgrading both units to the same version to ensure long-term compatibility.

On the PIX 500 series security appliance, at least one of the units must have an unrestricted (UR) license. The other unit can have a Failover Only (FO) license, a Failover Only Active-Active (FO_AA) license, or another UR license. Units with a Restricted license cannot be used for failover, and two units with FO or FO_AA licenses cannot be used together as a failover pair.

The FO and FO_AA licenses are intended to be used solely for units in a failover configuration and not for units in standalone mode. If a failover unit with one of these licenses is used in standalone mode, the unit reboots at least once every 24 hours until the unit is returned to failover duty. A unit with an FO or FO_AA license operates in standalone mode if it is booted without being connected to a failover peer with a UR license. If the unit with a UR license in a failover pair fails and is removed from the configuration, the unit with the FO or FO_AA license does not automatically reboot every 24 hours; it operates uninterrupted unless the it is manually rebooted.

The ASA 5500 series adaptive security appliance platform does not have this restriction.

Note The licensed features (such as SSL ××× peers or security contexts, for example) on both security appliances participating in failover must be identical.

The two units in a failover pair constantly communicate over a failover link to determine the operating status of each unit. The following information is communicated over the failover link:

? The unit state (active or standby).

? Power status (cable-based failover only-available only on the PIX 500 series security appliance).

? Hello messages (keep-alives).

? Network link status.

? MAC address exchange.

? Configuration replication and synchronization.

Connect the LAN failover link in one of the following two ways:

? Using a switch, with no other device on the same network segment (broadcast domain or VLAN) as the LAN failover interfaces of the ASA.

? Using a crossover Ethernet cable to connect the appliances directly, without the need for an external switch.

Note When you use a crossover cable for the LAN failover link, if the LAN interface fails, the link is brought down on both peers. This condition may hamper troubleshooting efforts because you cannot easily determine which interface failed and caused the link to come down.

Note The ASA supports Auto-MDI/MDIX on its copper Ethernet ports, so you can either use a crossover cable or a straight-through cable. If you use a straight-through cable, the interface automatically detects the cable and swaps one of the transmit/receive pairs to MDIX.

To use Stateful Failover, you must configure a Stateful Failover link to pass all state information. You have three options for configuring a Stateful Failover link:

? You can use a dedicated Ethernet interface for the Stateful Failover link.

? If you are using LAN-based failover, you can share the failover link.

? You can share a regular data interface, such as the inside interface. However, this option is not recommended.

If you are using a dedicated Ethernet interface for the Stateful Failover link, you can use either a switch or a crossover cable to directly connect the units. If you use a switch, no other hosts or routers should be on this link.

Note Enable the PortFast option on Cisco switch ports that connect directly to the security appliance.

Sharing a data interface with the Stateful Failover interface can leave you vulnerable to replay attacks. Additionally, large amounts of Stateful Failover traffic may be sent on the interface, causing performance problems on that network segment.

Note Using a data interface as the Stateful Failover interface is only supported in single context, routed mode.

In multiple context mode, the Stateful Failover link resides in the system context. This interface and the failover interface are the only interfaces in the system context. All other interfaces are allocated to and configured from within security contexts.

Note The IP address and MAC address for the Stateful Failover link does not change at failover unless the Stateful Failover link is configured on a regular data interface.

Active/Standby Failover

Note For multiple context mode, the security appliance can fail over the entire unit (including all contexts) but cannot fail over individual contexts separately.

Configuration synchronization occurs when one or both devices in the failover pair boot. Configurations are always synchronized from the active unit to the standby unit. When the standby unit completes its initial startup, it clears its running configuration (except for the failover commands needed to communicate with the active unit), and the active unit sends its entire configuration to the standby unit.

The active unit is determined by the following:

? If a unit boots and detects a peer already running as active, it becomes the standby unit.

? If a unit boots and does not detect a peer, it becomes the active unit.

? If both units boot simultaneously, then the primary unit becomes the active unit and the secondary unit becomes the standby unit.

Note If the secondary unit boots without detecting the primary unit, it becomes the active unit. It uses its own MAC addresses for the active IP addresses. However, when the primary unit becomes available, the secondary unit changes the MAC addresses to those of the primary unit, which can cause an interruption in your network traffic. To avoid this, configure the failover pair with virtual MAC addresses.

When the replication starts, the security appliance console on the active unit displays the message “Beginning configuration replication: Sending to mate,” and when it is complete, the security appliance displays the message “End Configuration Replication to mate.” During replication, commands entered on the active unit may not replicate properly to the standby unit, and commands entered on the standby unit may be overwritten by the configuration being replicated from the active unit. Avoid entering commands on either unit in the failover pair during the configuration replication process. Depending upon the size of the configuration, replication can take from a few seconds to several minutes.

Note The crypto ca server command and related sub-commands are not synchronized to the failover peer.

On the standby unit, the configuration exists only in running memory. To save the configuration to Flash memory after synchronization:

? For single context mode, enter the write memory command on the active unit. The command is replicated to the standby unit, which proceeds to write its configuration to Flash memory.

? For multiple context mode, enter the write memory all command on the active unit from the system execution space. The command is replicated to the standby unit, which proceeds to write its configuration to Flash memory. Using the all keyword with this command causes the system and all context configurations to be saved.

Note Startup configurations saved on external servers are accessible from either unit over the network and do not need to be saved separately for each unit. Alternatively, you can copy the contexts on disk from the active unit to an external server, and then copy them to disk on the standby unit, where they become available when the unit reloads.

If you enter the write standby command on the active unit, the standby unit clears its running configuration (except for the failover commands used to communicate with the active unit), and the active unit sends its entire configuration to the standby unit.

For multiple context mode, when you enter the write standby command in the system execution space, all contexts are replicated. If you enter the write standby command within a context, the command replicates only the context configuration.

The unit can fail if one of the following events occurs:

? The unit has a hardware failure or a power failure.

? The unit has a software failure.

? Too many monitored interfaces fail.

? The no failover active command is entered on the active unit or the failover active command is entered on the standby unit.

Active/Active Failover

In Active/Active failover, you divide the security contexts on the security appliance into failover groups. A failover group is simply a logical group of one or more security contexts. You can create a maximum of two failover groups on the security appliance. The admin context is always a member of failover group 1. Any unassigned security contexts are also members of failover group 1 by default.

When creating the failover groups, you should create them on the unit that will have failover group 1 in the active state.

Note Active/Active failover generates virtual MAC addresses for the interfaces in each failover group. If you have more than one Active/Active failover pair on the same network, it is possible to have the same default virtual MAC addresses assigned to the interfaces on one pair as are assigned to the interfaces of the other pairs because of the way the default virtual MAC addresses are determined. To avoid having duplicate MAC addresses on your network, make sure you assign each physical interface a virtual active and standby MAC address.

As in Active/Standby failover, one unit in an Active/Active failover pair is designated the primary unit, and the other unit the secondary unit. Unlike Active/Standby failover, this designation does not indicate which unit becomes active when both units start simultaneously. Instead, the primary/secondary designation does two things:

? Determines which unit provides the running configuration to the pair when they boot simultaneously.

? Determines on which unit each failover group appears in the active state when the units boot simultaneously. Each failover group in the configuration is configured with a primary or secondary unit preference. You can configure both failover groups be in the active state on a single unit in the pair, with the other unit containing the failover groups in the standby state. However, a more typical configuration is to assign each failover group a different role preference to make each one active on a different unit, distributing the traffic across the devices.

Note The security appliance also provides load balancing, which is different from failover. Both failover and load balancing can exist on the same configuration.

Which unit each failover group becomes active on is determined as follows:

? When a unit boots while the peer unit is not available, both failover groups become active on the unit.

? When a unit boots while the peer unit is active (with both failover groups in the active state), the failover groups remain in the active state on the active unit regardless of the primary or secondary preference of the failover group until one of the following:

- A failover occurs.

- You manually force the failover group to the other unit with the no failover active command.

- You configured the failover group with the preempt command, which causes the failover group to automatically become active on the preferred unit when the unit becomes available.

? When both units boot at the same time, each failover group becomes active on its preferred unit after the configurations have been synchronized.

After both units are running, commands are replicated from one unit to the other as follows:

? Commands entered within a security context are replicated from the unit on which the security context appears in the active state to the peer unit.

? Commands entered in the system execution space are replicated from the unit on which failover group 1 is in the active state to the unit on which failover group 1 is in the standby state.

? Commands entered in the admin context are replicated from the unit on which failover group 1 is in the active state to the unit on which failover group 1 is in the standby state.

Note In Release 8.0 and later, some configuration elements for Web××× (such as bookmarks and customization) use the ××× failover subsystem, which is part of Stateful Failover. You must use Stateful Failover to synchronize these elements between the members of the failover pair. Stateless (regular) failover is not recommended for Web×××.

When a failover occurs, all active connections are dropped. Clients need to reestablish connections when the new active unit takes over.

When Stateful Failover is enabled, the active unit continually passes per-connection state information to the standby unit. After a failover occurs, the same connection information is available at the new active unit. Supported end-user applications are not required to reconnect to keep the same communication session.

The following Web××× features are not supported with Stateful Failover:

? Smart Tunnels

? Port Forwarding

? Plugins

? Java Applets

? IPv6 clientless or Anyconnect sessions

? Citrix authentication (Citrix users must reauthenticate after failover)

Note If failover occurs during an active Cisco IP SoftPhone session, the call remains active because the call session state information is replicated to the standby unit. When the call is terminated, the IP SoftPhone client loses connection with the Cisco CallManager. This occurs because there is no session information for the CTIQBE hangup message on the standby unit. When the IP SoftPhone client does not receive a response back from the Call Manager within a certain time period, it considers the CallManager unreachable and unregisters itself.

For ××× failover, ××× end-users should not have to reauthenticate or reconnect the ××× session in the event of a failover. However, applications operating over the ××× connection could lose packets during the failover process and not recover from the packet loss.

Unit Health Monitoring

The security appliance determines the health of the other unit by monitoring the failover link. When a unit does not receive three consecutive hello messages on the failover link, the unit sends an ARP request on all interfaces, including the failover interface. The action the security appliance takes depends on the response from the other unit. See the following possible actions:

? If the security appliance receives a response on the failover interface, then it does not fail over.

? If the security appliance does not receive a response on the failover link, but receives a response on another interface, then the unit does not failover. The failover link is marked as failed. You should restore the failover link as soon as possible because the unit cannot fail over to the standby while the failover link is down.

? If the security appliance does not receive a response on any interface, then the standby unit switches to active mode and classifies the other unit as failed.

You can configure the frequency of the hello messages and the hold time before failover occurs. A faster poll time and shorter hold time speed the detection of unit failures and make failover occur more quickly, but it can also cause “false” failures due to network congestion delaying the keepalive packets.

Note If a failed unit does not recover and you believe it should not be failed, you can reset the state by entering the failover reset command. If the failover condition persists, however, the unit will fail again.

Interface Monitoring

You can monitor up to 250 interfaces divided between all contexts. You should monitor important interfaces, for example, you might configure one context to monitor a shared interface (because the interface is shared, all contexts benefit from the monitoring).

When a unit does not receive hello messages on a monitored interface for half of the configured hold time, it runs the following tests:

1. Link Up/Down test-A test of the interface status. If the Link Up/Down test indicates that the interface is operational, then the security appliance performs network tests. The purpose of these tests is to generate network traffic 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 the next test is used.

2. Network Activity test-A received network activity test. The unit counts all received packets for up to 5 seconds. If any packets are received at any time during this interval, the interface is considered operational and testing stops. If no traffic is received, the ARP test begins.

3. ARP test-A reading of the unit ARP cache for the 2 most recently acquired entries. One at a time, the unit sends ARP requests to these machines, attempting to stimulate network traffic. After each request, the unit counts all received traffic for up to 5 seconds. If traffic is received, the interface is considered operational. If no traffic is received, an ARP request is sent to the next machine. If at the end of the list no traffic has been received, the ping test begins.

4. Broadcast Ping test-A ping test that consists of sending out a broadcast ping request. The unit then counts all received packets for up to 5 seconds. If any packets are received at any time during this interval, the interface is considered operational and testing stops.

If all network tests fail for an interface, but this interface on the other unit continues to successfully pass traffic, then the interface is considered to be failed. If the threshold for failed interfaces is met, then a failover occurs. If the other unit interface also fails all the network tests, then both interfaces go into the “Unknown” state and do not count towards the failover limit.

An interface becomes operational again if it receives any traffic. A failed security appliance returns to standby mode if the interface failure threshold is no longer met.

You cannot configure failover with the following type of IP addresses:

? IP addresses obtained through DHCP

? IP addresses obtained through PPPoE

? IPv6 addresses

Additionally, the following restrictions apply:

? Stateful Failover is not supported on the ASA 5505 adaptive security appliance.

? Active/Active failover is not supported on the ASA 5505 adaptive security appliance.

? You cannot configure failover when Easy ××× remote is enabled on the ASA 5505 adaptive security appliance.

? ××× failover is not supported in multiple context mode.

? CA server is not supported. If you have a CA server configured on the active unit, the CA server functionality will be lost when the unit fails over. The crypto ca server command and associated commands are not synchronized or replicated to the peer unit.

To allow HTTP connections to be included in the state information replication, you need to enable HTTP replication. Because HTTP connections are typically short-lived, and because HTTP clients typically retry failed connection attempts, HTTP connections are not automatically included in the replicated state information. Enter the following command in global configuration mode to enable HTTP state replication when Stateful Failover is enabled: hostname(config)# failover replication http

In Active/Standby failover, the MAC addresses for the primary unit are always associated with the active IP addresses. If the secondary unit boots first and becomes active, it uses the burned-in MAC address for its interfaces. When the primary unit comes online, the secondary unit obtains the MAC addresses from the primary unit. The change can disrupt network traffic.

You can configure virtual MAC addresses for each interface to ensure that the secondary unit uses the correct MAC addresses when it is the active unit, even if it comes online before the primary unit. If you do not specify virtual MAC addresses the failover pair uses the burned-in NIC addresses as the MAC addresses.

Note You cannot configure a virtual MAC address for the failover or Stateful Failover links. The MAC and IP addresses for those links do not change during failover.

Note Using the asr-group command to configure asymmetric routing support is more secure than using the static command with the nailed option.

The asr-group command does not provide asymmetric routing; it restores asymmetrically routed packets to the correct interface.

Prerequisites

You must have to following configured for asymmetric routing support to function properly:

? Active/Active Failover

? Stateful Failover-passes state information for sessions on interfaces in the active failover group to the standby failover group.

? replication http-HTTP session state information is not passed to the standby failover group, and therefore is not present on the standby interface. For the security appliance to be able re-route asymmetrically routed HTTP packets, you need to replicate the HTTP state information.

You can configure the asr-group command on an interface without having failover configured, but it does not have any effect until Stateful Failover is enabled.

Because configuration commands are replicated from the active unit or context to the standby unit or context, you can use the failover exec command to enter configuration commands on the correct unit, no matter which unit you are logged-in to. For example, if you are logged-in to the standby unit, you can use the failover exec active command to send configuration changes to the active unit. Those changes are then replicated to the standby unit. Do not use the failover exec command to send configuration commands to the standby unit or context; those configuration changes are not replicated to the active unit and the two configurations will no longer be synchronized.