Cisco Security Appliance Command Line Configuration Guide, Version 7.2

Configuring DHCP, DDNS, and WCCP Services

This chapter describes how to configure the DHCP server, dynamic DNS (DDNS) update methods, and WCCP on the security appliance. DHCP provides network configuration parameters, such as IP addresses, to DHCP clients. The security appliance can provide a DHCP server or DHCP relay services to DHCP clients attached to security appliance interfaces. The DHCP server provides network configuration parameters directly to DHCP clients. DHCP relay passes DHCP requests received on one interface to an external DHCP server located behind a different interface.

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.

WCCP specifies interactions between one or more routers, Layer 3 switches, or security appliances and one or more 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.

This chapter includes the following sections:

•Configuring a DHCP Server

•Configuring DHCP Relay Services

•Configuring Dynamic DNS

•Configuring Web Cache Services Using WCCP

Configuring a DHCP Server

This section describes how to configure DHCP server provided by the security appliance. This section includes the following topics:

•Enabling the DHCP Server

•Configuring DHCP Options

•Using Cisco IP Phones with a DHCP Server

Enabling the DHCP Server

The security appliance can act as a DHCP server. DHCP is a protocol that supplies network settings to hosts including the host IP address, the default gateway, and a DNS server.

Note The security appliance DHCP server does not support BOOTP requests.

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.

To enable the DHCP server on a given security appliance interface, perform the following steps:

Step 1 Create a DHCP address pool. Enter the following command to define the address pool:

hostname(config)# dhcpd address ip_address-ip_address interface_name

The security appliance assigns a client one of the addresses from this pool to use for a given length of time. These addresses are the local, untranslated addresses for the directly connected network.

The address pool must be on the same subnet as the security appliance interface.

Step 2 (Optional) To specify the IP address(es) of the DNS server(s) the client will use, enter the following command:

hostname(config)# dhcpd dns dns1 [dns2]

You can specify up to two DNS servers.

Step 3 (Optional) To specify the IP address(es) of the WINS server(s) the client will use, enter the following command:

hostname(config)# dhcpd wins wins1 [wins2]

You can specify up to two WINS servers.

Step 4 (Optional) To change the lease length to be granted to the client, enter the following command:

hostname(config)# dhcpd lease lease_length

This lease equals the amount of time (in seconds) the client can use its allocated IP address before the lease expires. Enter a value between 300 to 1,048,575. The default value is 3600 seconds.

Step 5 (Optional) To configure the domain name the client uses, enter the following command:

hostname(config)# dhcpd domain domain_name

Step 6 (Optional) To configure the DHCP ping timeout value, enter the following command:

hostname(config)# dhcpd ping_timeout milliseconds

To avoid address conflicts, the security appliance sends two ICMP ping packets to an address before assigning that address to a DHCP client. This command specifies the timeout value for those packets.

Step 7 (Transparent Firewall Mode) Define a default gateway. To define the default gateway that is sent to DHCP clients, enter the following command.

hostname(config)# dhcpd option 3 ip gateway_ip

If you do not use the DHCP option 3 to define the default gateway, DHCP clients use the IP address of the management interface. The management interface does not route traffic.

Step 8 To enable the DHCP daemon within the security appliance to listen for DHCP client requests on the enabled interface, enter the following command:

hostname(config)# dhcpd enable interface_name

For example, to assign the range 10.0.1.101 to 10.0.1.110 to hosts connected to the inside interface, enter the following commands:

hostname(config)# dhcpd address 10.0.1.101-10.0.1.110 inside

hostname(config)# dhcpd dns 209.165.201.2 209.165.202.129

hostname(config)# dhcpd wins 209.165.201.5

hostname(config)# dhcpd lease 3000

hostname(config)# dhcpd domain example.com

hostname(config)# dhcpd enable inside

Configuring DHCP Options

You can configure the security appliance to send information for the DHCP options listed in RFC 2132. The DHCP options fall into one of three categories:

•Options that return an IP address.

•Options that return a text string.

•Options that return a hexadecimal value.

The security appliance supports all three categories of DHCP options. To configure a DHCP option, do one of the following:

•To configure a DHCP option that returns one or two IP addresses, enter the following command:

hostname(config)# dhcpd option code ip addr_1 [addr_2]

•To configure a DHCP option that returns a text string, enter the following command:

hostname(config)# dhcpd option code ascii text

•To configure a DHCP option that returns a hexadecimal value, enter the following command:

hostname(config)# dhcpd option code hex value 

Note The security appliance does not verify that the option type and value that you provide match the expected type and value for the option code as defined in RFC 2132. For example, you can enter the dhcpd option 46 ascii hello command and the security appliance accepts the configuration although option 46 is defined in RFC 2132 as expecting a single-digit, hexadecimal value. For more information about the option codes and their associated types and expected values, refer to RFC 2132.

Table 10-1 shows the DHCP options that are not supported by the dhcpd option command.

Specific options, DHCP option 3, 66, and 150, are used to configure Cisco IP Phones. See the "Using Cisco IP Phones with a DHCP Server" section topic for more information about configuring those options.

Using Cisco IP Phones with a DHCP Server

Enterprises with small branch offices that implement a Cisco IP Telephony Voice over IP solution typically implement Cisco CallManager at a central office to control Cisco IP Phones at small branch offices. This implementation allows centralized call processing, reduces the equipment required, and eliminates the administration of additional Cisco CallManager and other servers at branch offices.

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.

Cisco IP Phones might include both option 150 and 66 in a single request. In this case, the security appliance DHCP server provides values for both options in the response if they are configured on the security appliance.

You can configure the security appliance to send information for most options listed in RFC 2132. The following example shows the syntax for any option number, as well as the syntax for commonly-used options 66, 150, and 3:

•To provide information for DHCP requests that include an option number as specified in RFC-2132, enter the following command:

hostname(config)# dhcpd option number value

•To provide the IP address or name of a TFTP server for option 66, enter the following command:

hostname(config)# dhcpd option 66 ascii server_name

•To provide the IP address or names of one or two TFTP servers for option 150, enter the following command:

hostname(config)# dhcpd option 150 ip server_ip1 [server_ip2]

The server_ip1 is the IP address or name of the primary TFTP server while server_ip2 is the IP address or name of the secondary TFTP server. A maximum of two TFTP servers can be identified using option 150.

•To set the default route, enter the following command:

hostname(config)# dhcpd option 3 ip router_ip1 

Configuring DHCP Relay Services

A DHCP relay agent allows the security appliance to forward DHCP requests from clients to a router connected to a different interface.

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.

•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.

Note 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.

Note 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.

To enable DHCP relay, perform the following steps:

Step 1 To set the IP address of a DHCP server on a different interface from the DHCP client, enter the following command:

hostname(config)# dhcprelay server ip_address if_name

You can use this command up to 4 times to identify up to 4 servers.

Step 2 To enable DHCP relay on the interface connected to the clients, enter the following command:

hostname(config)# dhcprelay enable interface

Step 3 (Optional) To set the number of seconds allowed for relay address negotiation, enter the following command:

hostname(config)# dhcprelay timeout seconds

Step 4 (Optional) To change the first default router address in the packet sent from the DHCP server to the address of the security appliance interface, enter the following command:

hostname(config)# dhcprelay setroute interface_name

This action allows the client to set its default route to point to the security appliance even if the DHCP server specifies a different router.

If there is no default router option in the packet, the security appliance adds one containing the interface address.

The following example enables the security appliance to forward DHCP requests from clients connected to the inside interface to a DHCP server on the outside interface:

hostname(config)# dhcprelay server 201.168.200.4

hostname(config)# dhcprelay enable inside

hostname(config)# dhcprelay setroute inside

Configuring Dynamic DNS

This section describes examples for configuring the security appliance to support Dynamic DNS. DDNS update integrates DNS with DHCP. The two protocols are complementary—DHCP centralizes and automates IP address allocation, while dynamic DNS update automatically records the association between assigned addresses and hostnames. When you use DHCP and dynamic DNS update, this configures a host automatically for network access whenever it attaches to the IP network. You can locate and reach the host using its permanent, unique DNS hostname. Mobile hosts, for example, can move freely without user or administrator intervention.

DDNS provides address and domain name mappings so hosts can find each other even though their DHCP-assigned IP addresses change frequently. The DDNS name and address mappings are held on the DHCP server in two resource records: the A RR contains the name to IP address mapping while the PTR RR maps addresses to names. Of the two methods for performing DDNS updates—the IETF standard defined by RFC 2136 and a generic HTTP method—the security appliance supports the IETF method in this release.

The two most common DDNS update configurations are:

•The DHCP client updates the A RR while the DHCP server updates PTR RR.

•The DHCP server updates both the A and PTR RRs.

In general, the DHCP server maintains DNS PTR RRs on behalf of clients. Clients may be configured to perform all desired DNS updates. The server may be configured to honor these updates or not. To update the PTR RR, the DHCP server must know the Fully Qualified Domain Name of the client. The client provides an FQDN to the server using a DHCP option called Client FQDN.

The following examples present these common scenarios:

•Example 1: Client Updates Both A and PTR RRs for Static IP Addresses

•Example 2: Client Updates Both A and PTR RRs; DHCP Server Honors Client Update Request; FQDN Provided Through Configuration

•Example 3: Client Includes FQDN Option Instructing Server Not to Update Either RR; Server Overrides Client and Updates Both RRs.

•Example 4: Client Asks Server To Perform Both Updates; Server Configured to Update PTR RR Only; Honors Client Request and Updates Both A and PTR RR

•Example 5: Client Updates A RR; Server Updates PTR RR

Example 1: Client Updates Both A and PTR RRs for Static IP Addresses

The following example configures the client to request that it update both A and PTR resource records for static IP addresses. To configure this example, perform the following steps:

Step 1 To define a DDNS update method called ddns-2 that requests that the client update both the A and PTR RRs, enter the following commands:

hostname(config)# ddns update method ddns-2

hostname(DDNS-update-method)# ddns both

Step 2 To associate the method ddns-2 with the eth1 interface, enter the following commands:

hostname(DDNS-update-method)# interface eth1

hostname(config-if)# ddns update ddns-2

hostname(config-if)# ddns update hostname asa.example.com

Step 3 To configure a static IP address for eth1, enter the following commands:

hostname(config-if)# ip address 10.0.0.40 255.255.255.0

Example 2: Client Updates Both A and PTR RRs; DHCP Server Honors Client Update Request; FQDN Provided Through Configuration

The following example configures 1) the DHCP client to request that it update both the A and PTR RRs, and 2) the DHCP server to honor the requests. To configure this example, perform the following steps:

Step 1 To configure the DHCP client to request that the DHCP server perform no updates, enter the following command:

hostname(config)# dhcp-client update dns server none

Step 2 To create a DDNS update method named ddns-2 on the DHCP client that requests that the client perform both A and PTR updates, enter the following commands:

hostname(config)# ddns update method ddns-2

hostname(DDNS-update-method)# ddns both

Step 3 To associate the method named ddns-2 with the security appliance interface named Ethernet0, and enable DHCP on the interface, enter the following commands:

hostname(DDNS-update-method)# interface Ethernet0

hostname(if-config)# ddns update ddns-2

hostname(if-config)# ddns update hostname asa.example.com

hostname(if-config)# ip address dhcp

Step 4 To configure the DHCP server, enter the following command:

hostname(if-config)# dhcpd update dns

Example 3: Client Includes FQDN Option Instructing Server Not to Update Either RR; Server Overrides Client and Updates Both RRs.

The following example configures the DHCP client to include the FQDN option instructing the DHCP server not to update either the A or PTR updates. The example also configures the server to override the client request. As a result, the client backs off without performing any updates.

To configure this scenario, perform the following steps:

Step 1 To configure the update method named ddns-2 to request that it make both A and PTR RR updates, enter the following commands:

hostname(config)# ddns update method ddns-2

hostname(DDNS-update-method)# ddns both

Step 2 To assign the DDNS update method named ddns-2 on interface Ethernet0 and provide the client hostname (asa), enter the following commands:

hostname(DDNS-update-method)# interface Ethernet0

hostname(if-config)# ddns update ddns-2

hostname(if-config)# ddns update hostname asa.example.com

Step 3 To enable the DHCP client feature on the interface, enter the following commands:

hostname(if-config)# dhcp client update dns server none

hostname(if-config)# ip address dhcp

Step 4 To configure the DHCP server to override the client update requests, enter the following command:

hostname(if-config)# dhcpd update dns both override

Example 4: Client Asks Server To Perform Both Updates; Server Configured to Update PTR RR Only; Honors Client Request and Updates Both A and PTR RR

The following example configures the server to perform only PTR RR updates by default. However, the server honors the client request that it perform both A and PTR updates. The server also forms the FQDN by appending the domain name (example.com) to the hostname provided by the client (asa).

To configure this scenario, perform the following steps:

Step 1 To configure the DHCP client on interface Ethernet0, enter the following commands:

hostname(config)# interface Ethernet0

hostname(config-if)# dhcp client update dns both

hostname(config-if)# ddns update hostname asa

Step 2 To configure the DHCP server, enter the following commands:

hostname(config-if)# dhcpd update dns

hostname(config-if)# dhcpd domain example.com

Example 5: Client Updates A RR; Server Updates PTR RR

The following example configures the client to update the A resource record and the server to update the PTR records. Also, the client uses the domain name from the DHCP server to form the FQDN.

To configure this scenario, perform the following steps:

Step 1 To define the DDNS update method named ddns-2, enter the following commands:

hostname(config)# ddns update method ddns-2

hostname(DDNS-update-method)# ddns

Step 2 To configure the DHCP client for interface Ethernet0 and assign the update method to the interface, enter the following commands:

hostname(DDNS-update-method)# interface Ethernet0

hostname(config-if)# dhcp client update dns

hostname(config-if)# ddns update ddns-2

hostname(config-if)# ddns update hostname asa

Step 3 To configure the DHCP server, enter the following commands:

hostname(config-if)# dhcpd update dns

hostname(config-if)# dhcpd domain example.com

Configuring Web Cache Services Using WCCP

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.

This section includes the following topics:

•WCCP Feature Support

•WCCP Interaction With Other Features

•Enabling WCCP Redirection

WCCP Feature Support

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.

WCCP Interaction With Other Features

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.

•If you have two WCCP services and they use two different redirection ACLs that overlap and match the same packets (with a deny or a permit action), the packets behave according to the first service-group found and installed rules. The packets are not passed thorugh all service-groups.

Enabling WCCP Redirection

There are two steps to configuring WCCP redirection on the security appliance. The first involves identifying the service to be redirected with the wccp command, and the second is defining on which interface the redirection occurs with the wccp redirect command. The wccp command can optionally also define which cache engines can participate in the service group, and what traffic should be redirected to the cache engine.

WCCP redirect is supported only on the ingress of an interface. The only topology that the security appliance supports is when client and cache engine are behind the same interface of the security appliance and the cache engine can directly communicate with the client without going through the security appliance.

The following configuration tasks assume you have already installed and configured the cache engines you wish to include in your network.

To configure WCCP redirection, perform the following steps:

Step 1 To enable a WCCP service group, enter the following command:

hostname(config)# wccp {web-cache | service_number} [redirect-list access_list] 
[group-list access_list] [password password]

The standard service is web-cache, which intercepts TCP port 80 (HTTP) traffic and redirects that traffic to the cache engines, but you can identify a service number if desired between 0 and 254. For example, to transparently redirect native FTP traffic to a cache engine, use WCCP service 60. You can enter this command multiple times for each service group you want to enable.

The redirect-list access_list argument controls traffic redirected to this service group. The access-list argument should consist of a string of no more than 64 characters (name or number) that specifies the access list.

The group-list access_list argument determines which web cache IP addresses are allowed to participate in the service group. The access-list argument should consist of a string of no more than 64 characters (name or number) that specifies the access list.

The password password argument specifies MD5 authentication for messages received from the service group. Messages that are not accepted by the authentication are discarded.

Step 2 To enable WCCP redirection on an interface, enter the following command:

hostname(config)# wccp interface interface_name {web-cache | service_number} redirect in

The standard service is web-cache, which intercepts TCP port 80 (HTTP) traffic and redirects that traffic to the cache engines, but you can identify a service number if desired between 0 and 254. For example, to transparently redirect native FTP traffic to a cache engine, use WCCP service 60. You can enter this command multiple times for each service group you want to participate in.

For example, to enable the standard web-cache service and redirect HTTP traffic that enters the inside interface to a web cache, enter the following commands:

hostname(config)# wccp web-cache

hostname(config)# wccp interface inside web-cache redirect in

For example, to enable WCCP to participate in a service group, enter the following command:

hostname(config)# wccp web-cache redirect-list jeeves group-list wooster password whatho