Usage Guidelines

Single-sign-on support, available only for WebVPN, lets users access different secure services on different servers without entering a username and password more than once. The SSO server has a URL that handles authentication requests.

This command applies only to the SiteMinder type of SSO server.

Use the web-agent-url command to configure the ASA to send authentications to this URL. Before configuring the authentication URL, you must create the SSO server using the sso-server command.

For https communication between the security appliance and SSO-server, make sure that the SSL encryption settings match on both sides. On the security appliance, verify this with the ssl encryption command.

Usage Guidelines

The style option is expressed as any valid Cascading Style Sheet (CSS) parameters. Describing these parameters is beyond the scope of this document. For more information about CSS parameters, consult CSS specifications at the World Wide Web Consortium (W3C) website at www.w3.org. Appendix F of the CSS 2.1 Specification contains a convenient list of CSS parameters, and is available at www.w3.org/TR/CSS21/propidx.html.

Here are some tips for making the most common changes to the WebVPN pages—the page colors:

• You can use a comma-separated RGB value, an HTML color value, or the name of the color if recognized in HTML.

• RGB format is 0,0,0, a range of decimal numbers from 0 to 255 for each color (red, green, blue); the comma separated entry indicates the level of intensity of each color to combine with the others.

• HTML format is #000000, six digits in hexadecimal format; the first and second represent red, the third and fourth green, and the fifth and sixth represent blue.

Note	To easily customize the WebVPN pages, we recommend that you use ASDM, which has convenient features for configuring style elements, including color swatches and preview capabilities.

Usage Guidelines

The style option is expressed as any valid Cascading Style Sheet (CSS) parameters. Describing these parameters is beyond the scope of this document. For more information about CSS parameters, consult CSS specifications at the World Wide Web Consortium (W3C) website at www.w3.org. Appendix F of the CSS 2.1 Specification contains a convenient list of CSS parameters, and is available at www.w3.org/TR/CSS21/propidx.html.

Here are some tips for making the most common changes to the WebVPN pages—the page colors:

• You can use a comma-separated RGB value, an HTML color value, or the name of the color if recognized in HTML.

• RGB format is 0,0,0, a range of decimal numbers from 0 to 255 for each color (red, green, blue); the comma separated entry indicates the level of intensity of each color to combine with the others.

• HTML format is #000000, six digits in hexadecimal format; the first and second represent red, the third and fourth green, and the fifth and sixth represent blue.

Note	To easily customize the WebVPN pages, we recommend that you use ASDM, which has convenient features for configuring style elements, including color swatches and preview capabilities.

Usage Guidelines

When an interface uses DHCP IP addressing, the assigned IP address can change when the DHCP lease is renewed. When the interface needs to be reachable using a fully qualified domain name (FQDN), the IP address change can cause the DNS server resource records (RRs) to become stale. Dynamic DNS (DDNS) provides a mechanism to update DNS RRs whenever the IP address or hostname changes. You can also use DDNS for static or PPPoE IP addressing.

DDNS updates the following RRs on the DNS server: the A RR includes the name-to-IP address mapping, while the PTR RR maps addresses to names.

The ASA supports the following DDNS update methods: Standard DDNS (see the ddns command) and Web (using the web update-url command). The Web update method uses the DynDNS Remote API specification (https://help.dyn.com/remote-access-api/). With this method when the IP address or hostname changes, the ASA sends an HTTP request directly to a DNS provider with which you have an account.

Usage Guidelines

When an interface uses DHCP IP addressing, the assigned IP address can change when the DHCP lease is renewed. When the interface needs to be reachable using a fully qualified domain name (FQDN), the IP address change can cause the DNS server resource records (RRs) to become stale. Dynamic DNS (DDNS) provides a mechanism to update DNS RRs whenever the IP address or hostname changes. You can also use DDNS for static or PPPoE IP addressing.

DDNS updates the following RRs on the DNS server: the A RR includes the name-to-IP address mapping, while the PTR RR maps addresses to names.

The ASA supports the following DDNS update methods: Standard DDNS (see the ddns command) and Web (using the web update-url command). The Web update method uses the DynDNS Remote API specification (https://help.dyn.com/remote-access-api/). With this method when the IP address or hostname changes, the ASA sends an HTTP request directly to a DNS provider with which you have an account.

You can also specify the address types (IPv4 or IPv6) that you want to update using the web update-type command.

The web method for DDNS also requires you to identify the DDNS server root CA to validate the DDNS server certificate for the HTTPS connection. For example:

crypto ca trustpoint DDNS_Trustpoint
   enrollment terminal
crypto ca authenticate DDNS_Trustpoint nointeractive
   MIIFWjCCA0KgAwIBAgIQbkepxUtHDA3sM9CJuRz04TANBgkqhkiG9w0BAQwFADBH
   MQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExM
   [...]
   quit

Usage Guidelines

This WebVPN mode lets you configure global settings for WebVPN. WebVPN mode, which you enter from either group-policy mode or username mode, lets you customize a WebVPN configuration for specific users or group policies. The ASA clientless SSL VPN configuration supports only one http-proxy and one https-proxy command each.

Note	You must enable browser caching for WebVPN to work.

Usage Guidelines

Webvpn mode, which you enter from global configuration mode, lets you configure global settings for WebVPN. The webvpn command in group-policy attributes configuration mode or username attributes configuration mode applies the settings specified in the webvpn command to the group or user specified in the parent command. In other words, webvpn mode, described in this section, and which you enter from group-policy or username mode, lets you customize a WebVPN configuration for specific users or group policies.

The webvpn attributes that you apply for a specific group policy in group-policy attributes mode override those specified in the default group policy. The WebVPN attributes that you apply for a specific user in username attributes mode override both those in the default group policy and those in the group policy to which that user belongs. Essentially, these commands let you tweak the settings that would otherwise be inherited from the default group or the specified group policy. For information about the WebVPN settings, see the description of the webvpn command in global configuration mode.

The following table lists the attributes you can configure in webvpn group-policy attributes and username attributes mode. See the individual command descriptions for details.

Usage Guidelines

Identify the traffic you want to whitelist using the class-map type inspect scansafe command. Use the inspection class map in the policy-map type inspect scansafe command, and specify the whitelist action for the class. Call the inspection policy map in the inspect scansafe command.

Usage Guidelines

The who command allows you to display the TTY_ID and IP address of each Telnet client that is currently logged into the ASA.

Usage Guidelines

The tcp-map command is used along with the Modular Policy Framework infrastructure. Define the class of traffic using the class-map command and customize the TCP inspection with tcp-map commands. Apply the new TCP map using the policy-map command. Activate TCP inspection with service-policy commands.

Use the tcp-map command to enter tcp-map configuration mode. Use the window-variation command in tcp-map configuration mode to drop all connections with a window size that has been shrunk.

The window size mechanism allows TCP to advertise a large window and to subsequently advertise a much smaller window without having accepted too much data. From the TCP specification, “shrinking the window” is strongly discouraged. When this condition is detected, the connection can be dropped.

Usage Guidelines

Every time you issue the wins-server command you overwrite the existing setting. For example, if you configure WINS server x.x.x.x and then configure WINS server y.y.y.y, the second command overwrites the first, and y.y.y.y becomes the sole WINS server. The same holds true for multiple servers. To add a WINS server rather than overwrite previously configured servers, include the IP addresses of all WINS servers when you enter this command.

Usage Guidelines

This command prevents the Hostscan application of Cisco Secure Desktop from running on the endpoint if the user enters a URL in the url-group list configured on this connection profile (called a tunnel group in the CLI). Entering this command prevents the detection of endpoint conditions for these sessions, so you may need to adjust the dynamic access policy (DAP) configuration.

Usage Guidelines

This command is not supported within a security context. Context startup configurations are identified by the config-url command in the system configuration. If you want to delete a context configuration, you can remove the file manually from the remote server (if specified) or clear the file from Flash memory using the delete command in the system execution space.

For the ASA virtual, this command restores the deployment configuration (the initial virtual deployment settings) after a reload . To erase the configuration completely, use the clear configure all command. To erase the deployment configuration and apply the same factory default configuration as for the ASA appliances, see configure factory-default .

Note	The ASA virtual boots the current running image, so you are not reverted to the original boot image.Do not save the configuration before you reload.

For the ASA virtual in a failover pair, first power off the standby unit. To prevent the standby unit from becoming active, you must power it off. If you leave it on, when you erase the active unit configuration, then the standby unit becomes active. When the former active unit reloads and reconnects over the failover link, the old configuration will sync from the new active unit, wiping out the deployment configuration you wanted. After the active unit reloads, you can power on the standby unit. The deployment configuration will then sync to the standby unit.

Usage Guidelines

The running configuration is the configuration currently running in memory, including any changes you made at the command line. Changes are only preserved between reboots if you save them to the startup configuration, which is the configuration loaded into running memory at startup. The location of the startup configuration for single context mode and for the system in multiple context mode can be changed from the default location (a hidden file) to a location of your choosing using the boot config command. For multiple context mode, a context startup configuration is at the location specified by the config-url command in the system configuration.

In multiple context mode, you can enter the write memory command in each context to save the current context configuration. To save all context configurations, enter the write memory all command in the system execution space. Context startup configurations can reside on external servers. In this case, the ASA saves the configuration back to the server specified by the config-url command, except for HTTP and HTTPS URLs, which do not allow you to save the configuration back to the server. After the ASA saves each context with the write memory all command, the following message appears:

‘Saving context ‘b’ ... ( 1/3 contexts saved ) ’

Sometimes, a context is not saved because of an error. See the following information for errors:

• For contexts that are not saved because of low memory, the following message appears:

The context 'context a' could not be saved due to Unavailability of resources

• For contexts that are not saved because the remote destination is unreachable, the following message appears:

The context 'context a' could not be saved due to non-reachability of destination

• For contexts that are not saved because the context is locked, the following message appears:

Unable to save the configuration for the following contexts as these contexts are locked.
context ‘a’ , context ‘x’ , context ‘z’ .

A context is only locked if another user is already saving the configuration or in the process of deleting the context.

• For contexts that are not saved because the startup configuration is read-only (for example, on an HTTP server), the following message report is printed at the end of all other messages:

Unable to save the configuration for the following contexts as these contexts have read-only config-urls:
context ‘a’ , context ‘b’ , context ‘c’ .

• For contexts that are not saved because of bad sectors in the Flash memory, the following message appears:

The context 'context a' could not be saved due to Unknown errors

Because the system uses the admin context interfaces to access context startup configurations, the write memory command also uses the admin context interfaces. The write net command, however, uses the context interfaces to write a configuration to a TFTP server.

The write memory command is equivalent to the copy running-config startup-config command.

Usage Guidelines

The running configuration is the configuration currently running in memory, including any changes you made at the command line.

In multiple context mode, this command saves only the current configuration; you cannot save all contexts with a single command. You must enter this command separately for the system and for each context. The write net command uses the context interfaces to write a configuration to a TFTP server. The write memory command, however, uses the admin context interfaces to save to the startup configuration because the system uses the admin context interfaces to access context startup configurations.

The write net command is equivalent to the copy running-config tftp command.

Usage Guidelines

You should only use this command if the configuration on the standby unit or failover group becomes out-of-sync with the configuration of the active unit or failover group. This typically happens when commands are entered on the standby unit or failover group directly.

For Active/Standby failover, the write standby command entered on the active unit writes the running configuration of the active failover unit to the running configuration on the standby unit.

For Active/Active failover, the write standby command behaves as follows:

• If you enter the write standby command in the system execution space, the system configuration and the configurations for all of the security contexts on the ASA are written to the peer unit. This includes configuration information for security contexts that are in the standby state. You must enter the command in the system execution space on the unit that has failover group 1 in the active state.

• If you enter the write standby command in a security context, only the configuration for the security context is written to the peer unit. You must enter the command in the security context on the unit where the security context appears in the active state.

The write standby command replicates the configuration to the running configuration of the peer unit; it does not save the configuration to the startup configuration. To save the configuration changes to the startup configuration, use the copy running-config startup-config command on the same unit that you entered the write standby command. The command will be replicated to the peer unit and the configuration saved to the startup configuration.

When Stateful Failover is enabled, the write standby command also replicates state information to the standby unit after the configuration replication is complete. In multiple context mode, enter write standby within the context to replicate state information.

Note	After you enter the write standby command, the failover interfaces will go down momentarily while the configuration becomes re-synchronized. This can also cause a temporary failure of the failover state interface to be detected.

Usage Guidelines

This command is equivalent to the show running-config command.

Usage Guidelines

For carrier-grade or large-scale PAT, you can allocate a block of ports for each host, rather than have NAT allocate one port translation at a time (see RFC 6888). If you allocate a block of ports, subsequent connections from the host use new randomly-selected ports within the block. If necessary, additional blocks are allocated if the host has active connections for all ports in the original block. Blocks are freed when the last xlate that uses a port in the block is removed.

Port blocks are allocated in the 1024 - 65535 range only. Thus, if an application requires a low port number (1 - 1023), it might not work. For example, an application requesting port 22 (SSH) will get a mapped port within the range of 1024-65535 and within the block allocated to the host.

The xlate block-allocation command configures the characteristics of these port blocks. Use the block-allocation keyword on the nat command to enable port block allocation per PAT rule when using a PAT pool.

Usage Guidelines

The per-session PAT feature improves the scalability of PAT and, for clustering, allows each member unit to own PAT connections; multi-session PAT connections have to be forwarded to and owned by the master unit. At the end of a per-session PAT session, the ASA sends a reset and immediately removes the xlate. This reset causes the end node to immediately release the connection, avoiding the TIME_WAIT state. Multi-session PAT, on the other hand, uses the PAT timeout, by default 30 seconds. For “hit-and-run” traffic, such as HTTP or HTTPS, the per-session feature can dramatically increase the connection rate supported by one address. Without the per-session feature, the maximum connection rate for one address for an IP protocol is approximately 2000 per second. With the per-session feature, the connection rate for one address for an IP protocol is 65535/average-lifetime .

By default, all TCP traffic and UDP DNS traffic use a per-session PAT xlate. For traffic that can benefit from multi-session PAT, such as H.323, SIP, or Skinny, you can disable per-session PAT be creating a per-session deny rule.

When you add a per-session PAT rule, the rule is placed above the default rules, but below any other manually-created rules. Be sure to create your rules in the order you want them applied.

Usage Guidelines

You can assign multiple interfaces to a traffic zone , which lets traffic from an existing flow exit or enter the ASA on any interface within the zone. This capability allows Equal-Cost Multi-Path (ECMP) routing on the ASA as well as external load balancing of traffic to the ASA across multiple interfaces.

Zones allow traffic to and from any interface in the zone, but the security policy itself (access rules, NAT, and so on) is still applied per interface, not per zone. If you configure the same security policy for all interfaces within the zone, then you can successfully implement ECMP and load balancing for that traffic.

You can create a maximum of 256 zones.

Usage Guidelines

If the primary Zone Labs Integrity Firewall Server does not respond to the ASA, the ASA still establishes VPN client connections to the private network by default. It also maintains open, existing connections. This ensures that the enterprise VPN is not disrupted by the failure of a firewall server. If, however, you do not want the VPN connections to remain operational if the Zone Labs Integrity Firewall Server fails, use the zonelabs-integrity fail-close command.

To return to the default condition whereby the ASA maintains client VPN connections if the connection to the Zone Labs Integrity Firewall Server fails, use the zonelabs-integrity fail-open command.

Usage Guidelines

If the primary Zone Labs Integrity Firewall Server does not respond to the ASA, the ASA still establishes VPN client connections to the private network by default. It also maintains existing open connections. This ensures that the enterprise VPN is not disrupted by the failure of a firewall server. If, however, you do not want the VPN connections to remain operational if the Zone Labs Integrity Firewall Server fails, use the zonelabs-integrity fail-close command. To then return to the default condition whereby the ASA maintains client VPN connections if the connection to the Zone Labs Integrity Firewall Server fails, use the zonelabs-integrity fail-open command or the no zonelabs-integrity fail-open command.

Usage Guidelines

If the ASA waits for the specified number of seconds without a response from the Zone Labs server, the server is declared nonresponsive. Connections to VPN clients either remain open by default or if configured to do so with the zonelabs-integrity fail-open command. If, however, the zonelabs-integrity fail-close command has been issued, the connections will close when the ASA declares the Integrity server unresponsive.

Usage Guidelines

The ASA listens to the Zone Labs Integrity Firewall Server on the port and interface configured with the zonelabs-integrity port and zonelabs-integrity interface commands respectively.

Note	The current release of the ASA supports one Integrity Server at a time even though the user interfaces support the configuration of up to five Integrity Servers. If the active Server fails, configure another Integrity Server on the ASA and then reestablish the client VPN session.

Usage Guidelines

With this release, you can configure one Zone Labs Integrity Firewall Server. If that server fails, configure another Integrity Server first and then reestablish the client VPN session.

To specify a server by hostname, you must first configure the Zone Labs server name using the name command. Before using the name command, use the names command to enable it.

Note	The current release of the security appliance supports one Integrity Server at a time even though the user interfaces support the configuration of up to five Integrity Servers. If the active Server fails, configure another Integrity Server on the ASA and then reestablish the client VPN session.

Usage Guidelines

For SSL communications between the ASA and the Zone Labs Integrity Firewall Server, the ASA is the SSL server and the Zone Labs server is the SSL client. When initiating an SSL connection, the certificate of the SSL server (ASA) must be authenticated by the client (Zone Labs server). The zonelabs-integrity ssl-certificate-port command specifies the port to which the Zone Labs server connects when requesting the SSL server certificate.

Usage Guidelines

For SSL communications between the ASA and the Zone Labs Integrity Firewall Server, the ASA is the SSL server and the Zone Labs server is the SSL client. When initiating an SSL connection, the certificate of the SSL server (ASA) must be authenticated by the client (Zone Labs server). Authentication of the client certificate is optional, however. You use the zonelabs-integrity ssl-client-authentication command to enable or disable ASA authentication of the Zone Lab server (SSL client) certificate.

Usage Guidelines

Configure all interface parameters including the name, IP address, and security level. The first interface that you add to a zone determines the security level of the zone. All additional interfaces must have the same security level. To change the security level for interfaces in a zone, you must remove all but one interface, and then change the security levels, and re-add the interfaces.

When you assign an interface to a zone, any connections on that interface are deleted. The connections must be reestablished.

If you remove an interface from a zone, any connections that have the interface as the primary interface are deleted. The connections must be reestablished. If the interface is the current interface, the ASA moves the connections back to the primary interface. The zone route table is also refreshed.

You can add the following types of interfaces to a zone:

• Physical

• VLAN

• EtherChannel

• Redundant

You cannot add the following types of interfaces:

• Management-only

• Management-access

• Failover or state link

• Cluster control link

• Member interfaces in an EtherChannel or redundant interface

An interface can be a member of only one zone.

You can include up to 8 interfaces per zone.