Chapter 4: Configuring IP Connectivity

This chapter covers the following topics:
• Deploying DHCP Services -- This section covers how an ASA can operate as a DHCP
server and a DHCP relay. These functions support dynamic addressing for protected hosts,
either by the ASA or by an external dedicated DHCP server.
• Using Routing Information -- This section presents an overview of the various sources
of routing information and how an ASA can use them.
• Configuring Static Routing -- This section covers manual configuration of static routes,
as well as static route tracking, which can make static routes respond to changing conditions.
• Routing with RIPv2 -- This section covers the Routing Information Protocol (RIP) version 2 dynamic routing protocol.
• Routing with EIGRP -- This section covers the Enhanced Interior Gateway Routing Protocol (EIGRP) and how it can provide an ASA with dynamic routing information.
• Routing with OSPF -- This section covers the Open Shortest Path First (OSPF) dynamic
routing protocol and how an ASA can interact with other OSPF routers.
• Verifying the Routing Table -- This section provides an overview of some tools you can
use to verify the information in an ASA’s routing table and the relationship with neighboring routers.
--------------------------------------------------------------------------------------------------------------------

3-2: Configuring Routing

A firewall is a Layer 3 device, even though it inspects packets at many layers. Packets are forwarded based on their Layer 3 destination IP addresses, so the firewall must know how to reach the various destination IP networks. (This is true unless a firewall is configured for transparent firewall mode, where it operates only on Layer 2 information.)

A firewall knows about the subnets directly connected to each of its interfaces. These are shown as routes with a CONNECT (PIX 6.3) or directly connected (ASA or FWSM) identifier in output from the show route command.

To exchange packets with subnets not directly connected, a firewall needs additional routing information from one of the sources listed in Table 3-3.

Table 3-3: Routing Information Sources
Open table as spreadsheet

Route Type	Administrative Distance	Learning Method
Static	1	Manually configured
EIGRP summary route	5	Dynamically learned or advertised
RIP	120	Dynamically learned or advertised
EIGRP	90 (internal) 170 (external)	Dynamically learned or advertised
OSPF	110	Dynamically learned or advertised

The various routing protocols go about learning and advertising route information with different techniques. Because of this, some routing protocols are generally considered more trustworthy than others. The degree of trustworthiness is given by the administrative distance, an arbitrary value from 0 to 255. Routes with a distance of 0 are the most trusted, while those with a distance of 255 are the least trusted. The default values are generally accepted and are the same as those used on routers.

Administrative distance comes in handy when the same route has been learned in multiple ways. For example, suppose the route 10.10.0.0/16 has been learned by RIP (administrative distance of 120) and OSPF (administrative distance of 110). Each of the routing protocols might come up with different next-hop addresses for the route, so which one should the firewall trust? The protocol with the lowest distance value—OSPF.

Notice from Table 3-3 that static routes have a distance of 1, which makes them more trusted than any other routing protocol. If you configure a static route, chances are you are defining the most trusted information about that route. Only directly connected routes with a distance of 0, containing the subnets configured on the firewall interfaces, are more trusted.

As soon as routes are known, packets can be forwarded to other routers or gateways that in turn forward the packets toward their destinations.

A default route is useful on the firewall’s outside interface, where the most general subnets and destination networks are located. Usually, the networks located on the inside and other higher-security interfaces are specific and well-known. Remember that the firewall has to learn about the inside networks through some means.

Using Routing Information to Prevent IP Address Spoofing

A packet’s destination address normally is used to determine how it gets forwarded. If the destination address can be found in the routing table, the firewall can forward the packet out the appropriate interface to the destination or to a next-hop router.

Packet forwarding seems straightforward, but it makes certain assumptions about a packet and its sender. For example, the address or location of a packet’s source normally is not part of the forwarding decision. That might be fine if all senders and the packets they send can be trusted implicitly. When your network is connected to a public network, full of untrusted and unknown users, however, there should be no trust at all.

A common exploit used in a denial-of-service attack involves spoofed IP addresses. A malicious user sends packets toward a target host to initiate connections or use up a resource on the target. However, the sender disguises itself by inserting a bogus source address into the packets. Either the source address does not exist, or it might be a legitimate address of some other host on some other network. The idea is to prevent any return traffic from reaching the malicious user, protecting his identity and location.

Cisco firewalls can use Reverse Path Forwarding (RPF) to detect spoofed source addresses in most cases. As soon as RPF is enabled, a firewall examines the source address of each packet arriving on an interface. It tries to find the reverse path, or the path back toward the source, in its routing table. In other words, the firewall acts as if it will send something back to the source to verify its location. If a route to the source address or network can be found, the outbound interface must match the interface where the packet originally arrived.

If a route cannot be found, or the reverse-path interface does not match the arriving interface, the packet is simply dropped, and a logging message is generated.

Normally, a firewall has specific routing information about all the IP networks on the inside or protected (nonpublic) interfaces, because those networks are known to exist and are controlled. Therefore, RPF checks to see whether packets sourced from a protected network are easily and accurately performed.

The outside or public network is a different story. The firewall usually cannot know about every IP network that exists in the outside world, so it makes do with a default route. The same is true of RPF on the outside interface. When a packet arrives on the outside interface, if the specific route to the source cannot be found, the firewall uses the default route to verify the reverse path.

You can enable RPF with the following configuration command:

Firewall(config)# ip verify reverse-path interface if_name

Notice that RPF is configured on a per-interface basis, only on the interface named if_name (inside, for example). You can repeat this command to enable RPF on multiple interfaces. Remember that RPF works by checking packets that arrive on an interface—not packets that are leaving.

Note

It might seem odd or inadvisable that the default route is used for RPF tests on the outside interface. After all, the majority of source address spoofing would probably be found on the outside public network. Unfortunately, this is mostly true, because a firewall cannot know everything about the outside network. The vast majority of IP addresses are found “somewhere out there” on the public Internet, on the outside interface. However, RPF can detect when source addresses from the outside are spoofed with addresses that are used on an inside or protected interface. In other words, if someone tries to masquerade as a trusted user, using a trusted IP address, the firewall recognizes that the address is appearing on the wrong interface, and it drops the packet. This happens before a connection is formed and before any further access lists or stateful inspection are performed, preserving the firewall resources.

Figure 3-8 illustrates the RPF process. RPF has been enabled on the outside interface, to check packets arriving from the outside. The firewall’s routing table is shown, providing information that RPF can use about the known inside networks. The only thing known about the outside network is the default route.

Figure 3-8: Unicast RPF Operation

When an outside host tries to masquerade as the address 192.168.10.7, the firewall finds a matching route located on the inside network. Clearly, the outside host is spoofing that address, so the packet is dropped.

During the RPF process, each ICMP packet is examined individually. UDP and TCP packets are examined too, but only the first packet in a connection. All subsequent packets in the connection receive a quick check for the correct source interface; the route lookup and reverse path check are skipped.

You can use the following command to display RPF counters related to one or all firewall interfaces:

Firewall# show ip verify statistics [interface if_name]

For example, in the following firewall output, 3312 packets were dropped as they arrived on the inside interface because of spoofed source addresses:

Firewall# show ip verify statistics
interface outside: 170 unicast rpf drops
interface inside: 3312 unicast rpf drops
interface dmz: 3 unicast rpf drops
Firewall#

To reset the statistics counters, you can use the clear ip verify statistics command.

Configuring Static Routes

Static routes can be manually configured on a firewall. These routes are not learned or advertised; the routes you configure are the only routes the firewall knows unless a routing protocol is also being used.

The firewall uses static routing information, as shown in Figure 3-9.

Figure 3-9: Static Routes Used by a Firewall

You can define static routes by following these configuration steps:

1. Define a static route to a specific subnet:

   Firewall(config)# route if_name ip_address netmask gateway_ip [distance]

   The IP subnet defined by ip_address and netmask (a standard dotted-decimal subnet mask) can be reached by forwarding packets out the firewall interface named if_name (inside or outside, for example). The packets are forwarded to the next-hop gateway at IP address gateway_ip.

   By default, a static route receives an administrative distance of 1. You can override this behavior by specifying a distance value (1 to 255).

   Tip

   You can also define the static route with the firewall’s own interface IP address as the gateway address. If the next-hop gateway address is not known or if it is subject to change, you can simply have the firewall use the interface where the gateway is connected. When packets are forwarded toward the gateway, the firewall sends ARP requests for the destination address. The next-hop router must be configured to use proxy ARP so that it responds with its own MAC address as the destination. This is not a recommended approach, however. You should use it only in cases where the next-hop router is subject to change or is unknown. Proxy ARP is generally considered a risk, because it exposes a firewall to memory exhaustion during certain types of denial-of-service attacks.

   If you have configured IPv6 operation on a firewall, you can also configure static IPv6 routes. The command syntax is very similar to the IPv4 form:

   Firewall(config)# ipv6 route if_name ipv6_prefix/prefix_length
    ipv6_gateway [distance]

2. Define a default static route:

   Firewall(config)# route if_name 0.0.0.0  0.0.0.0 gateway_ip [distance]

   You can define a default route so that the firewall knows how to reach any network other than those specifically defined or learned. The default network and subnet mask are written as 0.0.0.0 0.0.0.0 to represent any address. They can also be given more simply as 0 0 to save typing.

   The firewall assumes that the next-hop router or gateway at IP address gateway_ip knows how to reach the destination. You can configure up to three different default routes on a firewall. If more than one default route exists, the firewall distributes outbound traffic across the default route gateways to load balance the traffic.

   You can remove a static route by repeating this command beginning with the no keyword.

Tip

You can verify a firewall’s routing information by using the show route EXEC command. The output shows routes learned by any possible means, whether directly connected, static, or through a dynamic routing protocol. Static routes are shown as routes with an OTHER static identifier in output from the PIX 6.3 show route command, or with an S identifier in the ASA or FWSM show route command. For example, the default route in the following output has been configured as a static route: Firewall# show route O IA 192.168.167.1 255.255.255.255 [110/11] via 192.168.198.4, 82:39:36, inside C 192.168.198.0 255.255.255.0 is directly connected, inside C 128.163.93.128 255.255.255.128 is directly connected, outside S* 0.0.0.0 0.0.0.0 [1/0] via 128.163.93.129, outside Firewall# Static routes and routes learned from a routing protocol are shown with square brackets containing two values. The first value is the administrative distance, and the second value is the metric derived or used by the routing protocol. For example, the OSPF route to 192.168.167.1 has [110/11]—OSPF uses administrative distance 110, while this specific route has an OSPF metric of 11.

Static Route Example

The following static routes are to be configured on a firewall:

• A default route points to gateway 192.168.1.1 on the outside interface.

• Network 172.21.0.0/16 can be found through gateway 192.168.254.2 on the inside interface.

• Network 172.30.146.0/24 can be found through gateway 192.168.254.10, also on the inside interface.

The static route configurations are as follows:

Firewall(config)# route outside 0.0.0.0 0.0.0.0 192.168.1.1 1
Firewall(config)# route inside 172.21.0.0 255.255.0.0 192.168.254.2 1
Firewall(config)# route inside 172.30.146.0 255.255.255.0 192.168.254.10 1

Favoring Static Routes Based on Reachability

Normally, if a static route is configured, it stays active until it is manually removed. A static route is simply an unchanging definition of a next-hop destination—regardless of whether that destination is reachable. If a single ISP is the sole means of reaching the outside world, a static default route works nicely to point all outbound traffic to the ISP’s gateway address.

Suppose you had connections to two ISPs; one might be favored over the other, but the default routes to each ISP are equally weighted. In other words, the firewall tries to balance the outbound traffic equally across the connections. Even if the connection to one ISP goes down, the firewall still uses the static route that points to that ISP—effectively sending some outbound traffic into a black hole.

Beginning with ASA 7.2(1), a static route can be conditional. So, if a target address is reachable, the static route remains active; if the target is not reachable, the static route becomes inactive. This allows you to configure multiple static or default routes without worrying about whether one ISP connection is working or not.

To do this, you configure a service level agreement (SLA) monitor process that monitors an arbitrary target address. That process is associated with a static route so that the route tracks the reachability of the target. Use the following steps to configure static address tracking:

1. Define the SLA monitor process:

   Firewall(config)# sla monitor sla-id
   

   The process is known by its sla-id, an arbitrary number from 1 to 2,147,483,647.

2. Define the reachability test:

   Firewall(config-sla-monitor)# type echo protocol ipIcmpEcho target interface if-name
   

   The only test type is echo, which sends ICMP echo request packets to the target IP address found on firewall interface if-name.

   You should select a target address that is a reliable indicator of a route’s reachability. For example, you could use an ISP’s next-hop gateway address as a target to test the ISP connection’s reachability. The target address can be another router, firewall, host, and so on.

   Tip

   Before you configure the ICMP echo target address, you might want to manually test the target’s reachability with the ping target command.

   1. (Optional) Set the test frequency:

      Firewall(config-sla-monitor-echo)# frequency seconds
      

      By default, echo tests are run every 60 seconds. You can set a different time interval as seconds (1 to 604,800 seconds or 7 days).

   2. (Optional) Set the number of ICMP echo packets to send:

      Firewall(config-sla-monitor-echo)# num-packets number
      

      By default, only one ICMP request packet is sent during an echo test. You can define a different number of packets as number (1 to 100).

   3. (Optional) Set the payload size of the ICMP request:

      Firewall(config-sla-monitor-echo)# request-data-size bytes
      

      By default, each ICMP echo request packet has a payload of 28 bytes. You can set the payload size as bytes (0 to 16,384 bytes), although you cannot use a value less than 28. As well, you should not choose a payload size that makes the ICMP echo request packet larger than the path MTU.

   4. (Optional) Set the type of service (TOS) value:

      Firewall(config-sla-monitor-echo)# tos number
      

      By default, each ICMP echo request packet sent has an IP TOS value of 0. You can choose a different value as number (0 to 255). This option can be handy if other routers along the path to the target are configured to enforce quality of service (QoS) policies based on the TOS byte in the IP packet headers.

   5. (Optional) Set the timeout interval:

      Firewall(config-sla-monitor-echo)# timeout milliseconds
      

      By default, the firewall waits 5000 ms (5 seconds) to receive an ICMP echo reply packet in response to its echo test. If a reply packet is received within the timeout interval, the target is reachable. If not, the target is assumed to be unreachable, and the echo test fails.

      You can choose a different timeout interval as milliseconds (0 to 604,000,000 milliseconds, or 7 days). The timeout interval must be longer than the frequency defined with the frequency command.

   6. (Optional) Set the test threshold:

      Firewall(config-sla-monitor-echo)# threshold milliseconds
      

      The firewall also keeps track of a test threshold, which is used as an indicator that the target is getting increasingly hard to reach. The threshold is not used to decide whether the target is reachable. Instead, it can give you an idea of how realistic your choice of the timeout interval is.

      By default, the threshold interval is set to 5000 ms (5 seconds). You can set a different threshold value as milliseconds (0 to 2,147,483,647 ms). Keep in mind that the threshold value must always be less than or equal to the timeout interval value.

      For example, suppose you choose a timeout interval of 10,000 ms (10 seconds) and a threshold value of 5000 ms. After many echo tests are run, you can look at the test statistics to see how often the threshold is exceeded. If it is rarely exceeded, you might decide to reduce the timeout value to something at or below the current threshold value. If you decide to reduce the timeout value, you should also reduce the threshold value.

3. Schedule the SLA monitor test:

   Firewall(config)# sla monitor schedule sla-id [life {forever | seconds}] [start-time
   {hh:mm[:ss] [month day | day month] | pending | now | after hh:mm:ss}] [ageout seconds]
   [recurring]

   The test can begin in one of the following ways:

   Open table as spreadsheet

   Starting Time	Keyword
   Wait indefinitely	pending (the default)
   At a specific time	start-time with time and day
   Start immediately	now
   Wait until	after with a time interval
   Recur daily	recurring every day at the time given

   You can specify the lifetime of the test with the life keyword, followed by forever (infinite lifetime) or seconds. By default, a test runs for 3600 seconds or 1 hour.

   For continuing reachability tests, you should use the following command syntax:

   Firewall(config)# sla monitor sla-id life forever now
   

   The test continues to run until you manually remove it from the firewall configuration with the no sla monitor sla-id command.

4. Enable reachability tracking:

   Firewall(config)# track track-id rtr sla-id reachability
   

   The SLA monitor test identified by sla-id is used to track reachability information. Each track process is known by its track-id index, an arbitrary value from 1 to 500. You should define a unique track index for each SLA monitor test that you configure, so that each test can be tracked independently.

5. Apply tracking to a static route:

   Firewall(config)# route if_name ip_address netmask gateway_ip [distance] track
   track-id
   

   The normal static route command syntax is used, along with the track keyword. Track process number track-id is used to provide reachability information for the static route. If the test target is reachable (it returns ICMP echo replies as expected), the static route remains active in the routing table.

   If the target is not reachable (ICMP echo replies are not received as expected), the static route remains in the running configuration, but is not active in the routing table.

6. Monitor static route tracking:

   You can monitor the status of a tracking process with any of the following EXEC commands:

   Firewall# show track
   Firewall# show route
   Firewall# debug track
   Firewall# debug sla monitor trace
   

Reachable Static Route Example

A firewall has two paths to the outside Internet, using two independent ISPs, as shown in Figure 3-10. The firewall can be configured with two default routes that point to the two ISP routers, 10.1.1.100 and 10.1.1.200. Outbound traffic toward the Internet is balanced across the two default routes, and across the two ISPs.

Figure 3-10: An Example Network Using Reachability Information

The firewall is also configured to track the reachability of each ISP, so that the appropriate static route can be deactivated if an ISP connection is down. SLA monitor test 1 is configured to perform echo tests on the ISP1 router at 10.1.1.100, while SLA test 2 checks the ISP2 router at 10.1.1.200. The following commands can be used to configure the reachability tests and static routes:

Firewall(config)# sla monitor 1
Firewall(config-sla-monitor)# type echo protocol ipIcmpEcho 10.1.1.100 interface outside
Firewall(config-sla-monitor-echo)# frequency 30
Firewall(config-sla-monitor-echo)# threshold 1000
Firewall(config-sla-monitor-echo)# timeout 3000
Firewall(config-sla-monitor-echo)# exit
Firewall(config-sla-monitor)# exit
Firewall(config)# sla monitor schedule 1 life forever now
!
Firewall(config)# track 1 rtr 1 reachability
!
Firewall(config)# sla monitor 2
Firewall(config-sla-monitor)# type echo protocol ipIcmpEcho 10.1.1.200 interface outside
Firewall(config-sla-monitor-echo)# frequency 30
Firewall(config-sla-monitor-echo)# threshold 1000
Firewall(config-sla-monitor-echo)# timeout 3000
Firewall(config-sla-monitor-echo)# exit
Firewall(config-sla-monitor)# exit
Firewall(config)# sla monitor schedule 2 life forever now
!
Firewall(config)# track 2 rtr 2 reachability
!
Firewall(config)# route 0.0.0.0 0.0.0.0 10.1.1.100 track 1
Firewall(config)# route 0.0.0.0 0.0.0.0 10.1.1.200 track 2

Notice that each static route uses a different tracking process. That means either static route can be deactivated depending on the status of its respective next-hop router. Static route tracking is a rather silent process, and the firewall will not give you any obvious signs that it is actually testing the reachability.

To see this in action, you can use the show route command to display the current routing table contents. If both ISP router targets are reachable, then both static routes are shown, as in the following output:

Firewall# show route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
      D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
      N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
      E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
      i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
      * - candidate default, U - per-user static route, o - ODR
      P - periodic downloaded static route

Gateway of last resort is 10.1.1.100 to network 0.0.0.0

C    127.0.0.0 255.255.0.0 is directly connected, cplane
C    192.168.100.0 255.255.255.0 is directly connected, inside
S*   0.0.0.0 0.0.0.0 [1/0] via 10.1.1.100, outside
                    [1/0] via 10.1.1.200, outside

Here, both static routes are listed, although no indication that they are conditional is listed. You can always confirm the static route configuration with the show run route command:

Firewall# show run route
route outside 0.0.0.0 0.0.0.0 10.1.1.100 track 1
route outside 0.0.0.0 0.0.0.0 10.1.1.200 track 2
Firewall#

You can also see the current status of a track process with the show track [track-id] command:

Firewall# show track 1
Track 1
 Response Time Reporter 1 reachability
 Reachability is Up
 1 change, last change 00:01:03
 Latest operation return code: OK
 Latest RTT (millisecs) 1
 Tracked by:
   STATIC-IP-ROUTING 0
Firewall#

You can also enable debugging output for the tracking process. Use the debug sla monitor trace command to get some real-time indication of SLA probes as they are sent. However, to see messages indicating a change in reachability, you can use the debug track command, as in the example that follows. After each reachability change is announced, the routing table is shown for clarity. Notice how the static route to ISP2 is missing after track process 2 announces that the target is unreachable, and how the static route returns when the target comes up again.

Firewall# debug track
Firewall#
Firewall#
Firewall# Track: 2 Change #1 rtr 2, reachability Up->Down
Firewall# show route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
      D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
      N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
      E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
      i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
      * - candidate default, U - per-user static route, o - ODR
      P - periodic downloaded static route

Gateway of last resort is 10.1.1.100 to network 0.0.0.0

C    127.0.0.0 255.255.0.0 is directly connected, cplane
C    192.168.100.0 255.255.255.0 is directly connected, inside
S*   0.0.0.0 0.0.0.0 [1/0] via 10.1.1.100, outside
Firewall#
Firewall#
Firewall# Track: 2 Change #2 rtr 2, reachability Down->Up
Firewall#
Firewall# show route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
      D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
      N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
      E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
      i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
      * - candidate default, U - per-user static route, o - ODR
      P - periodic downloaded static route

Gateway of last resort is 10.1.1.100 to network 0.0.0.0

C    127.0.0.0 255.255.0.0 is directly connected, cplane
C    192.168.100.0 255.255.255.0 is directly connected, inside
S*   0.0.0.0 0.0.0.0 [1/0] via 10.1.1.100, outside
                    [1/0] via 10.1.1.200, outside
Firewall#

Configuring RIP to Exchange Routing Information

Cisco firewalls can passively listen to RIP updates (either version 1 or 2) to learn routing information. Routing advertisements from the firewall are limited to one type—a firewall interface as a default route. RIP can be used in either of the following versions:

• RIP version 1, which supports only classful networks. Advertisements are broadcast unencrypted.

• RIP version 2, which supports classless networks. Advertisements can be authenticated by a cryptographic function for security purposes.

RIP routing information is used by the firewall as shown in Figure 3-11.

Figure 3-11: Firewall Using RIP for Routing Information

You can configure RIP on a firewall by following these configuration steps:

1. Passively listen to RIP updates from other routers.

   1. Listen to RIP version 1 updates:

      Firewall(config)# rip if_name passive [version 1]
      

      Any networks advertised in RIPv1 updates received on the firewall interface named if_name are added to the routing table. To protect information about the internal networks, the firewall does not advertise any routes to its internal or protected networks.

   2. Listen to RIP version 2 updates:

      Firewall(config)# rip if_name passive version 2 [authentication
      [text | md5 key (key_id)]]

      Any networks advertised in RIPv2 updates received on the firewall interface named if_name are added to the routing table.

      If RIPv2 authentication is being used by other routers, the firewall must use the same method. Advertisements can be authenticated with a cleartext text key (up to a 16-character text string) that is passed within the routing update. Naturally, having the authentication key pass across the network in the clear (unencrypted) is not very secure.

      You can also use message digest 5 (MD5) authentication. An md5 key (up to a 16-character text string) can be defined on each router. The key is not sent as a part of the routing updates. Instead, it is kept hidden and is used only to validate the MD5 hash value that is computed on each routing advertisement and the key. MD5 also supports multiple keys, referenced by a key_id (1 to 255). Both the key ID and the key itself must match between neighboring RIPv2 routers.

2. Advertise a firewall interface as a default route:

   Firewall(config)# rip if_name default version [1 | 2] [authentication
    [text | md5 key key_id]]

   The only route that a firewall can advertise is a default route, with its own interface named if_name as the gateway address. The default route is advertised using RIP version 1 or 2. An optional authentication can be used with RIPv2, as a cleartext text key or an md5 key.

Tip

You can verify the RIP configuration commands that have been entered with the show rip [if_name] (PIX 6.3) or show running-config rip (ASA or FWSM) EXEC command. To see RIP update activity, you can also use the debug rip command. In the following example, the firewall has received one route advertisement: %PIX-7-711001: RIP: received packet from interface inside [pif=2] (192.168.198.4:520) %PIX-7-711001: RIP: interface inside received v2 update from 192.168.198.4 %PIX-7-711001: RIP: update contains 1 routes %PIX-7-711001: RIP: Advertise network 192.168.167.0 mask 255.255.255.0 gateway 192.168.198.4 metric 1 If RIP routes do not appear in the routing table as expected, there could be a misconfiguration involving RIPv2 authentication. In this case, the debug output would show a message like this: %PIX-1-107001: RIP auth failed from 192.168.198.4: version=2, type=ffff, mode=3, sequence=13 on interface inside You can also display the current routing table to see routes that RIP has learned. Those entries are marked with an R indicator, as in the following example: Firewall# show route S 0.0.0.0 0.0.0.0 [1/0] via 128.163.93.129, outside C 128.163.93.128 255.255.255.128 is directly connected, outside R 192.168.167.0 255.255.255.0 [1/0] via 192.168.198.4, inside C 192.168.198.0 255.255.255.0 is directly connected, inside Firewall#

RIP Example

A firewall is to use RIP version 2 to learn routing information on its inside interface. The firewall also advertises its inside interface as the default gateway. MD5 authentication is being used on other internal RIPv2 routers, using key number 1, mysecretkey. The configuration is as follows:

Firewall(config)# rip inside passive version 2 authentication md5 mysecretkey 1
Firewall(config)# rip inside default version 2 authentication md5 mysecretkey 1

Configuring EIGRP to Exchange Routing Information

The Enhanced Interior Gateway Routing Protocol (EIGRP) is new to ASA 8.0. As its name implies, EIGRP is based on Interior Gateway Routing Protocol (IGRP), but with many enhancements. EIGRP is a distance vector routing protocol, and its routing metrics are based on a combination of delay, bandwidth, reliability, load, and MTU.

EIGRP uses a neighbor discovery mechanism that works by sending “hello” messages to directly connected neighboring routers. Neighbors can be dynamically discovered or statically configured. All EIGRP messages, including the hello protocol, are sent as multicast packets to address 224.0.0.10, the all EIGRP routers address, using IP protocol 88.

EIGRP supports variable-length subnet masks (VLSM) and route summarization, providing plenty of flexibility in its routing information. It also uses the Diffusing Update Algorithm (DUAL) to compute and maintain routing information from all of its neighbors. The ASA (or any other EIGRP router) always uses a feasible successor, or a neighboring router with the lowest cost path to a destination.

EIGRP routers do not send periodic routing updates. Rather, routing information is exchanged only when a route’s metric changes, based on information from neighboring routers. If you have routers running EIGRP in your network, you might want to run EIGRP on your ASA, too, so that the ASA can benefit from dynamic routing information. You can use the following steps to configure EIGRP; if you are familiar with configuring EIGRP on a Cisco router, you should find that the ASA commands are identical.

1. Enable an EIGRP process:

   Firewall(config)# router eigrp as-num
   

   EIGRP routers can exchange routing information if they each belong to the same autonomous system. You can define the autonomous system number as as-num, a number from 1 to 65535. Make sure the autonomous system number matches that of other EIGRP routers in your network.

2. Associate a network with the EIGRP process:

   asa(config-router)# network ip-addr [mask]

   EIGRP must know which interfaces are to participate in routing updates and which interface subnets to advertise. If an interface address falls within the subnet ip-addr and mask, then EIGRP uses it in its operation.

   If you want the interface subnet to be advertised, but you do not want the interface to participate in EIGRP routing exchanges, you can use the following command:

   asa(config-router)# passive-interface if_name
   

3. (Optional) Use stub routing for a firewall with a single exit point:

   asa(config-router)# eigrp stub {receive-only | [connected] [redistributed] [static]
   [summary]}

   If the firewall has a single connection to the outside world through a distribution router, it can become an EIGRP stub router. As a stub, it can receive routes (usually a default route) from its neighbor, but advertises only specific routes of its own.

   With the receive-only keyword, the firewall receives updates but does not advertise anything. Otherwise, you can specify one or more route types to advertise. Use the connected keyword to advertise routes that are directly connected to the firewall, the redistributed keyword to advertise any routes that the firewall has redistributed into its EIGRP process, the static keyword to advertise static routes defined on the firewall, or the summary keyword to advertise summary addresses defined on the firewall.

4. (Optional) Define a specific EIGRP neighbor:

   Normally, the firewall discovers other EIGRP neighbors by exchanging multicast hello messages. If a neighbor is located across a network that does not support multicast traffic, you can statically define the neighbor. At that point, the firewall communicates with the neighbor via unicast traffic. Use the following EIGRP configuration command to define a neighbor:

   asa(config-router)# neighbor ip-addr interface if_name
   

   The neighbor is located at ip-addr over the specified interface.

5. (Optional) Filter EIGRP updates to suppress specific networks:

   asa(config-router)# distribute-list acl {in | out} [interface if_name]

   Routes or subnets that are permitted by access list acl are filtered from EIGRP updates. The in keyword filters the routes as they are received from other EIGRP routers, while the out keyword filters the routes in EIGRP advertisements from the firewall.

   You can use the interface keyword to filter routes on a specific interface.

6. (Optional) Control route summarization:

   By default, EIGRP automatically summarizes subnet routes into classful network routes when they are advertised. If you have contiguous subnets that are separated among firewall interfaces or across EIGRP routers, you should disable route summarization with the following EIGRP configuration command:

   asa(config-router)# no auto-summary
   

   Otherwise, you can configure a summary address that is advertised on an interface. This can be handy if you need a summary address that does not fall cleanly within a network boundary. In addition, if you have already disabled automatic summarization, the firewall can still advertise a summary address that is manually configured. You can configure a summary address with the following commands:

   asa(config)# interface if_name
   asa(config-if)# summary-address eigrp as-num address mask [distance]

   The summary address given by address mask is advertised by EIGRP autonomous system number as-num. You can specify an administrative distance to override the default value of 5 for summary addresses.

7. (Optional) Redistribute routing information from other sources:

   If the firewall is running other routing protocols like RIP or OSPF, you can redistribute routes learned from those methods into EIGRP. First, you should configure a route map to filter routing information from one routing protocol into EIGRP.

   You can define a default metric for all routes that are redistributed into EIGRP, because metrics from the different route sources are not equivalent. Use the following EIGRP configuration command:

   asa(config-router)# default-metric bandwidth delay reliability loading mtu
   

   Specify the composite default metric as the combination of bandwidth (1 to 4294967295 kbps), delay (1 to 4294967295 in tens of microseconds), reliability (0 to 255, ranging from low to high), loading (1 to 255, ranging from low to high link usage), and mtu (1 to 65535 bytes).

   If a default metric is not defined, you can configure a metric as a part of route redistribution.

   To redistribute routes that were learned by RIP, were statically defined, or are directly connected, use the following EIGRP configuration command:

   asa(config-router)# redistribute {rip | static | connected} [metric bandwidth delay
   reliability load mtu] [route-map map_name]

   To redistribute routes learned from OSPF, use the following EIGRP configuration command:

   asa(config-router)# redistribute ospf pid [match {internal | external [1 | 2] | nssa-
   external [1 | 2]}] [metric bandwidth delay reliability load mtu] [route-map map_name]

   Identify the OSPF process as pid. You can match against OSPF internal, type 1 or 2 OSPF external, or external type 1 or 2 Not So Stubby Area (nssa-external) routes.

8. (Optional) Secure EIGRP updates with neighbor authentication:

   asa(config)# interface if_name
   asa(config-if)# authentication mode eigrp as-num md5
   asa(config-if)# authentication key eigrp as-num key-string key-id key-id
   

   The ASA can use the MD5 hash algorithm to verify a neighbor router’s authentication key. Define the ASA’s key as the text string key-string, also known as key number key-id (a number from 1 to 255). As soon as authentication is enabled, any EIGRP neighbors that fail to present the correct key are ignored.

9. (Optional) Adjust EIGRP timers:

   By default, the firewall sends hello messages every 5 seconds and expects neighbors to hold its neighbor state if they do not receive its hello messages for 15 seconds before they consider it to be unreachable. You should adjust these timers to match the values used by neighboring routers, only if those routers are not using the default values. You can use the following interface configuration commands to adjust the timers for EIGRP autonomous system number as-num:

   asa(config)# interface if_name
   asa(config-if)# hello-interval eigrp as-num seconds
   asa(config-if)# hold-time eigrp as-num seconds
   

10. (Optional) Adjust the interface delay used in EIGRP metric calculations:

    Each firewall interface has a delay value that is used in EIGRP metric calculations. By default, the delay is set to a value that is inversely proportional to the bandwidth of the interface. You can display the current delay value with the show interface command, as in the following example:

    Firewall# show interface
    Interface GigabitEthernet0/0 "outside", is up, line protocol is up
    Hardware is i82546GB rev03, BW 1000 Mbps, DLY 1000 usec
    Auto-Duplex(Full-duplex), Auto-Speed(100 Mbps)

    You can adjust the delay value with the following interface configuration command:

    asa(config)# interface if_name
    asa(config-if)# delay value
    

An EIGRP Configuration Example

A firewall is positioned so that its interface ethernet0/1 faces the outside public network, while ethernet0/0 faces the inside protected network. EIGRP is being used on the internal network, because of the network’s size. The firewall participates in EIGRP so that it can receive dynamic updates about internal IP subnets.

Because the firewall has only a single path to the outside world, it can become an EIGRP stub router. Also, the outside interface does not need to participate in routing updates because no trusted EIGRP neighbor exists there.

You can use the following configuration commands to set up EIGRP on the firewall:

Firewall(config)# router eigrp 101
Firewall(config-router)# network 10.0.0.0
Firewall(config-router)# network 192.168.1.0
Firewall(config-router)# eigrp stub
Firewall(config-router)# passive-interface ethernet0/1
Firewall(config-router)# exit
Firewall(config)# route outside 0.0.0.0 0.0.0.0 10.0.1.2 1
!
Firewall(config)# interface ethernet 0/1
Firewall(config-if)# nameif outside
Firewall(config-if)# security-level 0
Firewall(config-if)# ip address 10.0.1.1 255.255.255.0
Firewall(config-if)# exit
!
Firewall(config)# interface ethernet 0/0
Firewall(config-if)# nameif inside
Firewall(config-if)# security-level 100
Firewall(config-if)# ip address 192.168.1.1 255.255.255.0
Firewall(config-if)# authentication mode eigrp 101 md5
Firewall(config-if)# authentication key eigrp 101 secret123 key-id 1
Firewall(config-if)# exit

Configuring OSPF to Exchange Routing Information

OSPF is a link-state routing protocol. The routing domain is partitioned into areas. Area 0 is always considered the backbone area of the OSPF domain or autonomous system.

When an OSPF router connects to two or more different areas, it is called an Area Border Router (ABR). When an OSPF router connects an area to a non-OSPF domain and it imports routing information from other sources into OSPF, it is called an Autonomous System Boundary Router (ASBR).

OSPF routers build a common database of the status of all links in the area by exchanging link-state advertisements (LSA). The routers build their routing tables by computing the shortest path first (SPF) algorithm based on that database.

OSPF Routing Scenarios with a Firewall

When a firewall is configured to use OSPF, consider its role in the scenarios described in the following sections.

OSPF Used Only on the Inside

The firewall becomes an ASBR, bordering an OSPF area with a non-OSPF public network. Figure 3-12 shows this topology.

Figure 3-12: Using OSPF Only on the Inside of the Firewall

On the outside, only static routes can be configured. On the inside, OSPF LSAs are exchanged with other neighboring routers. The static routes to outside destinations can be redistributed into OSPF so that they are advertised within the inside area. There is no danger or possibility that the firewall will advertise inside to the outside (unsecure) world.

OSPF Used Only on the Outside

The firewall is an ASBR, bordering an OSPF area on the outside with a non-OSPF inside network. Figure 3-13 shows this topology.

Figure 3-13: Using OSPF Only on the Outside of the Firewall

On the inside, only static routes can be configured. On the outside, OSPF LSAs are exchanged with other neighboring routers. The static routes to inside networks can be redistributed to the outside area. If you need to do that, you should carefully consider filtering the information so that no inside network details are revealed to the outside. As well, if NAT is being used at the outside firewall interface, it does not make sense to advertise inside private IP subnets.

To filter redistributed routes toward the outside, you should configure a route map on the firewall. Be sure to deny any internal network addresses and permit any global or public network addresses.

OSPF Used on Both Sides of the Firewall (Same Autonomous System)

Here, the firewall is an ABR because it borders an OSPF area with the OSPF backbone area. Because both areas are within the same autonomous system (AS), the firewall is positioned more like a traditional ABR. This situation might be needed if your organization maintains the inside and outside networks (except for the public Internet) and the firewall protects only a subset of the whole AS. Figure 3-14 shows this topology.

Figure 3-14: Using OSPF on Both Sides of the Firewall (ABR)

On the inside, the firewall exchanges OSPF LSAs with other inside routers in that area. On the outside, the firewall exchanges LSAs with other corporate routers in the OSPF backbone area. This topology makes it easy to maintain dynamic routing information on the routers and the firewall for a large network.

Routes from the OSPF backbone (outside) are advertised toward the inside area. This poses no real problem, because the outside networks are less secure and are expected to be known. The firewall also advertises inside routes toward the backbone area (outside).

To filter routes that are advertised toward the backbone area, you should configure a prefix list on the firewall. Be sure to deny any internal networks with private IP addresses and permit any others that should be known to the outside. (A prefix list is needed because the inside routes are not redistributed to the outside; rather, they are simply advertised within OSPF.)

OSPF Used on Both Sides of the Firewall (Different Autonomous Systems)

This is a unique case, because the firewall separates two distinct autonomous systems, each with its own OSPF backbone area. Now the firewall must become an ASBR for both the inside and the outside. In other words, two separate OSPF processes must run, each supporting a different AS (inside and outside). Figure 3-15 shows this topology.

Figure 3-15: Using OSPF on Both Sides of the Firewall (ASBR)

A Cisco firewall can run up to two unique OSPF processes, which makes this scenario possible. Each one runs under a different process ID or number. On the outside, LSAs are exchanged with other neighboring routers. On the inside, a different set of LSAs is exchanged with internal neighbors. By default, no routing information is advertised from the inside to the outside, and vice versa.

You can configure one OSPF process to redistribute routes from another OSPF process; however, for example, the inside process can redistribute routes from the outside process. This is usually acceptable because public routes can be freely advertised and used.

You can also redistribute routes from the inside process into the outside process. If that is necessary, you should configure a route map to filter any internal routing information that should not become public knowledge. Be sure to deny any internal networks with private IP addresses and permit others that should be known to the outside.

Configuring OSPF

OSPF is a complex, robust routing protocol. This also means that it is very flexible but can be tedious to configure. You should be well acquainted with OSPF as an advanced IP routing topic before you attempt to configure and use it on a firewall; however, do not be overwhelmed by the number of configuration command possibilities. Instead, try to configure OSPF according to other existing routers in your network. Break it into these basic functions:

• Configure the OSPF process. Define networks and areas.

• Configure authentication if needed.

• Configure a prefix list if the firewall will be an ABR.

• Configure summary routes, and tune OSPF only if you feel comfortable doing this.

• Configure route redistribution only if you need to inject routes from one side of the firewall to another.

In very large or complex network topologies, the firewall might connect to an OSPF stub or Not So Stubby Area (NSSA). The firewall might also be involved in a virtual link. If these situations apply, you can work through those configuration steps, too.

The configuration commands needed for each of the OSPF functions are presented in the following list. Follow them in order, skipping over the ones that are obviously not needed in your network scenario.

1. Define an OSPF process:

   Firewall(config)# router ospf pid
   

   The OSPF process is identified by its process ID pid (an arbitrary number from 1 to 65535). Up to two separate OSPF processes can be run on a firewall. This allows each process to exchange routing information independently, although a single routing table is maintained in the firewall. (The process ID is only locally significant; it is not passed or matched among routers and firewalls.)

2. (Optional) Uniquely identify the OSPF router ID:

   Firewall(config-router)# router-id ip_address
   

   By default, OSPF uses the numerically highest IP address defined on any firewall interface as the router ID. For example, an interface with IP address 192.168.1.2 is considered to be higher than one that uses 10.1.1.1 or even 192.168.1.1. This value identifies the “router” in any OSPF exchanges with its neighbors.

   If the highest address on your firewall is a private address (172.28.4.1, for example), you might not want to divulge the private network information to other parties. In this case, you can configure the firewall to use an interface that has a global or public IP address ip_address.

3. (Optional) Generate logging messages when OSPF neighbor states change:

   Firewall(config-router)# log-adj-changes [detail]

   By default, the firewall generates logging messages to indicate when an OSPF neighbor adjacency goes up or down. In other words, the log-adj-changes command is present in the configuration by default.

   You can add the detail keyword to generate logging messages for each OSPF neighbor state change, not just for neighbor up and down states. To disable adjacency logging, you can precede the command with the no keyword.

   For example, when adjacency logging is enabled, messages similar to the following are generated:

   %ASA-5-503001: Process 1, Nbr 192.168.167.1 on inside from FULL to DOWN,
    Neighbor Down: Dead timer expired

4. Assign and activate a network to an OSPF area:

   Firewall(config-router)# network ip_address netmask area area_id
   

   The OSPF process exchanges routing information on any firewall interface that falls within the address range specified here. As well, the network assigned to that interface is advertised by OSPF.

   The range of addresses is defined by ip_address and netmask (a normal dotted-decimal subnet mask, not a wildcard mask as in IOS). If an interface subnet falls within that range, it is also assigned to OSPF area area_id (a decimal number 0 to 4294967295, or an IP subnet written in dotted-decimal format).

   Tip

   An OSPF area can be referred to by a decimal number or by a subnet notation. This is possible because the area number is stored as one 32-bit number (0 to 4294967295). You might also think of the area as always having a subnet notation—a decimal area number is always preceded by three octets of 0s. For example, area 5 can also be written as 0.0.0.5, area 100 is 0.0.0.100, and area 0 is 0.0.0.0. Using subnet notation for OSPF areas is handy when you have a specific subnet by itself in one area. Also remember that OSPF must have one backbone area, called area 0 or area 0.0.0.0.

5. (Optional) Authenticate OSPF exchanges with other neighbors in an area:

   Firewall(config-router)# area area_id authentication [message-digest]

   OSPF peers can authenticate information from each other using cleartext passwords (by default) or MD5 (with the message-digest keyword). If authentication is enabled on one device, it must be enabled on all the neighboring devices in the same area.

   In addition, the actual authentication keys are defined on each OSPF interface. This is done in Step 12b.

6. (Optional; ABR only) Keep the private network from being advertised to an outside area.

   If a firewall is configured as an ABR, it sends type 3 LSAs between the areas it touches. This means that the networks in each area are advertised into other areas. Naturally, you would not want private networks to be advertised toward the outside for security and network translation reasons.

   1. Define a prefix list for filtering routes:

      Firewall(config)# prefix-list list_name [seq seq_number] {permit | deny}
      prefix/len [ge min_value] [le max_value]

      The prefix list named list_name (an arbitrary text string) is defined for filtering routes. You can repeat this command to add more conditions to the list. By default, prefix list entries are automatically numbered in increments of 5, beginning with sequence number 5. Match entries are evaluated in sequence, starting with the lowest defined sequence number. By giving the sequence number seq_number here, you can wedge a new statement between two existing ones.

      A prefix list entry can either permit or deny the advertisement of matching routes in type 3 LSAs. A prefix list entry matches an IP route address against the prefix (a valid IP network address) and len (the number of leftmost bits in the address) values. The ge (greater than or equal to a number of bits) and le (less than or equal to a number of bits) keywords can also be used to define a range of the number of prefix bits to match. A range can provide a more specific matching condition than the prefix/len values alone.

      For example, to permit advertisements of routes with a prefix of 172.16.0.0/16 but having any mask length between 16 and 24 bits, you could use the following command:

      Firewall(config)# prefix-list MyRoutes permit 172.16.0.0/16 ge 16 le 24
      

      Note

      Prefix lists are configured in regular configuration mode first. Then, they can be applied to the OSPF process from within OSPF router configuration mode (after the router ospf pid command is entered).

   2. Use the prefix list to filter LSAs into or out of an area:

      Firewall(config-router)# area area_id filter-list prefix
      prefix_list_name [in | out]

      If you want to suppress advertisement of an internal network, you can apply the prefix list for LSAs going in or out of the area area_id. This means you can stop the advertisements from leaving a private area by applying the prefix list to the private area_id in the out direction. Or you can filter the advertisements on the public area area_id side in the in direction.

7. (Optional) Advertise a default route:

   Firewall(config-router)# default-information originate [always]
    [metric value] [metric-type {1 | 2}] [route-map name]

   The firewall can advertise a default route as an external route. If you use the always keyword, a default route is advertised even if one has not been specifically configured. The route is advertised with a metric of value (0 to 16777214; the default is 1). By default, the route is advertised as an external type 2 route (metric-type 2). You can also configure a route map separately and apply it with the route-map keyword to filter the default route that is advertised.

8. (Optional) Define a special case area.

   1. (Optional) Define a stub area:

      Firewall(config-router)# area area_id stub [no-summary]

      If a stub area is defined, all OSPF neighbors in that area must configure it as a stub. You can include the no-summary keyword to create a totally stubby area; OSPF prevents the introduction of any external or interarea routes into the stub area.

      or

   2. (Optional) Define an NSSA:

      Firewall(config-router)# area area_id nssa [no-redistribution]
      [default-information-originate [metric-type 1 | 2]
      [metric metric_value]]

      An NSSA is a stub area that allows external routes to be transported through. You can use the no-redistribution keyword on an ABR firewall if you want external routes to be redistributed only into normal areas, not into any NSSAs.

      Use the default-information-originate keyword to generate a default route into the NSSA. If that is used, you can define the default route as an external route type 1 (route cost plus the internal OSPF metric) or 2 (route cost without the internal OSPF metric). You can also specify a default route metric as metric_value (0 to 16777214).

   3. (Optional) Set the default route cost:

      Firewall(config-router)# area area_id default-cost cost
      

      In a stub area or an NSSA, the firewall sends other area routers a default route in place of any external or interarea routes. You can set the cost of this default route as cost (0 to 65535; the default is 1).

9. (Optional) Restore backbone area connectivity with a virtual link:

   Firewall(config-router)# area area_id virtual-link router_id
    [authentication [message-digest | null]] [hello-interval seconds]
    [retransmit-interval seconds] [transmit-delay seconds]
    [dead-interval seconds] [authentication-key password]
    [message-digest-key id md5 password]

   If the backbone area becomes discontiguous during a router or link failure, OSPF routers can use a virtual link to reconnect the backbone area. You can manually configure a virtual link ahead of time so that it is used as a redundant connection in case an area loses connectivity to the backbone.

   Here, area_id is the transit area, or the area that must be crossed to reach the backbone from the firewall. The router_id is the IP address of the far-end router that completes the virtual link.

   Because this is an extension of the backbone area, the virtual link must have many other authentication and timer values defined. These values normally are defined for the OSPF process and OSPF interfaces on the firewall. Use those values here as well as appropriate.

10. (Optional; ABR only) Summarize routes between areas:

    Firewall(config-router)# area area_id range ip_address netmask
     [advertise | not-advertise]

    An ABR can reduce the number of routes it sends into an area (area_id) by sending a summary address. The summary address is sent in place of any route that falls within the range defined by ip_address and netmask, and the advertise keyword is assumed (the default). If you do not want the summary address advertised, add the not-advertise keyword.

    For example, you could use the following command to send a summary route into backbone area 0 for all hosts and subnets within 172.18.0.0/16:

    Firewall(config)# area 0 range 172.18.0.0 255.255.0.0
    

11. (Optional) Tune OSPF.

    1. (Optional) Set the administrative distance for OSPF routes:

       Firewall(config-router)# distance ospf [intra-area d1]
       [inter-area d2] [external d3]

       By default, all OSPF routes have an administrative distance of 110. This is consistent with Cisco routers. You can change the distance for intra-area routes (within an OSPF area) to d1. You can change the distance for inter-area routes (from one area to another) to d2. You can change the distance for external routes (from another routing protocol into the OSPF area) to d3. If you set these distances differently, the firewall can choose one type of route over another without comparing the OSPF metrics.

    2. (Optional) Change the route calculation timers:

       Firewall(config-router)# timers {spf spf_delay spf_holdtime |
        lsa-group-pacing seconds}

       You can configure the OSPF process to wait a delay time of spf_delay (0 to 65535 seconds; the default is 5) after receiving a topology change before starting the SPF calculation. The firewall waits spf_holdtime (0 to 65535 seconds; the default is 10) between two consecutive calculations.

       You can also tune the calculation process with the lsa-group-pacing keyword. LSAs are gathered and processed at intervals of seconds (10 to 1800 seconds; the default is 240).

12. (Optional) Configure an OSPF interface.

    1. Select the OSPF interface to configure:

       PIX 6.3	Firewall(config)# routing interface if_name
       ASA, FWSM	Firewall(config)# interface if_name

       Open table as spreadsheet

       The firewall interface named if_name (inside or outside, for example) is configured for OSPF parameters.

    2. (Optional) Use authentication:

       Firewall(config-if)# ospf authentication-key key
       

       or

       Firewall(config-if)# ospf message-digest-key key-id md5 key
       Firewall(config-if)# ospf authentication message-digest
       

       If authentication has been enabled for an OSPF area, you must also set up the authentication key on each interface in that area. For simple cleartext authentication, use the authentication-key keyword along with a preshared key (up to eight characters with no white space). This key is sent in the clear within the OSPF LSAs.

       You can use the more secure MD5 method instead by using the message-digest keyword. MD5 keys are used to validate the MD5 hash value that is computed from each OSPF LSA and the key itself. Only the MD5 hash value is sent in the OSPF LSAs. You can define several keys by repeating the command. Each key is known by a key-id index (1 to 255). The actual MD5 key is a string of up to 16 text characters.

       Tip

       The key string found at index key-id on one router or firewall must match the same key at key-id on all other neighboring routers or firewalls. You can change the keys periodically by defining a new key at a new key-id index. The old key continues to be used even though a new one has been defined. As soon as all neighboring routers have the new key too, OSPF rolls over and uses the new authentication key. At that time, you should remove the old MD5 keys with the no ospf message-digest key-id routing interface configuration command.

    3. (Optional) Set the OSPF interface priority:

       Firewall(config-if)# ospf priority number
       

       When multiple OSPF routers are connected to a single VLAN or broadcast domain, one of them must be elected as the designated router (DR) and another as the backup designated router (BDR). This is done by comparing the interface priority values; the highest priority wins the election. By default, the priority is 1, but you can set it to number (0 to 255; 0 prevents the router from becoming a DR or BDR).

    4. (Optional) Adjust the OSPF timers:

       • Set the hello interval:

         Firewall(config-if)# ospf hello-interval seconds
         

         The time between successive hello updates is set to seconds (1 to 65535; the default is 10 seconds). If this is changed, the hello interval must be set identically on all neighboring OSPF routers.

       • Set the dead interval:

         Firewall(config-if)# ospf dead-interval seconds
         

         If no hello updates are received from a neighboring OSPF router in seconds (1 to 65535 seconds; the default is 4 times the hello interval, or 40 seconds), that neighbor is declared to be down. If this is changed, the dead interval must be set identically on all neighboring OSPF routers.

       • Set the retransmit interval:

         Firewall(config-if)# ospf retransmit-interval seconds
         

       • If an LSA must be retransmitted to a neighbor, the firewall waits seconds (1 to 65535; the default is 5 seconds) before resending the LSA.

       • Set the transmit delay time:

         Firewall(config-if)# ospf transmit-delay seconds
         

       • The firewall keeps an estimate of how long it takes to send an LSA on an interface. The transmission delay is set to seconds (1 to 65535; the default is 1 second).

    5. (Optional) Set the interface cost:

       Firewall(config-if)# ospf cost interface_cost
       

       The unitless OSPF cost for the interface becomes interface_cost (0 to 65535; the default is 10). The higher the interface bandwidth, the lower the cost value becomes. A firewall has a default cost of 10 for all interfaces, regardless of their speeds. This behavior is different from Cisco routers running Cisco IOS Software, where both Fast Ethernet and Gigabit Ethernet have a cost of 1.

Redistributing Routes from Another Source into OSPF

When a firewall redistributes routes from any other source into OSPF, it automatically becomes an ASBR by definition. You can (and should) use a route map to control which routes are redistributed into OSPF. To configure a route map, follow these steps:

1. Use a route map to filter redistributed routes.

   1. Define the route map:

      Firewall(config)# route-map map_tag [permit | deny] [seq_num]

      The route map named map_tag (an arbitrary text string) either permits or denies a certain action. You can repeat this command if you need to define several actions for the same route map. In this case, you should assign a sequence number seq_num to each one.

      Use the permit keyword to define an action that redistributes routes into OSPF. The deny keyword defines an action that is processed but does not redistribute routes.

   2. Define one or more matching conditions.

      If you configure multiple match statements, all of them must be met.

      • Match against a firewall’s next-hop outbound interface:

        Firewall(config-route-map)# match interface interface_name
        

        Routes with their next hop located out the specified firewall interface name are matched.

      • Match against a route’s metric:

        Firewall(config-route-map)# match metric metric_value
        

        The metric_value is used to match the OSPF metric of each route.

      • Match against the IP address of the route itself:

        Firewall(config-route-map)# match ip address acl_id
        

        An access list named acl_id is used to match each route’s network address. The access list must be configured separately and before this command is used. It should contain permit entries for source addresses that represent the IP route.

      • Match against the type of route:

        Firewall(config-route-map)# match route-type {local | internal |
         [external [type-1 | type-2]]}

        Routes are matched according to their type: local (locally generated), internal (OSPF intra-area and interarea), external type-1 (OSPF Type 1 external), and external type-2 (OSPF Type 2 external).

      • Match against external routes in an NSSA:

        Firewall(config-route-map)# match nssa-external [type-1 | type-2]

        For an NSSA, routes are matched according to OSPF external type 1 or type 2 (the default).

      • Match against the IP address of the next-hop router:

        Firewall(config-route-map)# match ip next-hop acl_id [...acl_id]

        Routes with the next-hop router addresses that are permitted by one or more access lists are matched. If multiple access list names are listed, they are evaluated in the order given.

      • Match against the IP address of the advertising router:

        Firewall(config-route-map)# match ip route-source acl_id
         [...acl_id]

        Routes that have been advertised by a router with IP addresses permitted by one or more access lists are matched. If multiple access list names are listed, they are evaluated in the order given.

   3. (Optional) Define attributes to be set when matched:

      • Set the next-hop IP address for a route:

        Firewall(config-route-map)# set ip next-hop ip-address
         [ip-address]

        The next-hop router address for the matched route is replaced with the IP addresses specified. These addresses correspond to adjacent or neighboring routers.

      • Set the route metric:

        Firewall(config-route-map)# set metric value
        

        The redistributed route is assigned the specified metric value (0 to 4294967295). You can also specify the metric value as a plus or minus sign with a number (−2147483647 to +2147483647), causing the metric to be adjusted by that value. Lower metric values signify preferred routes.

      • Set the route metric type:

        Firewall(config-route-map)# set metric-type {internal | external |
         type-1 | type-2}

        The metric type of the redistributed routes can be internal (internally generated), external (the default is OSPF type 2), type-1 (OSPF type 1), or type-2 (OSPF type 2).

2. (Optional) Redistribute static routes into OSPF:

   Firewall(config-router)# redistribute {static | connected} [metric
    metric_value] [metric-type metric_type] [route-map map_name] [tag
    tag_value] [subnets]

   Either static routes (configured with the route command) or connected routes (subnets directly connected to firewall interfaces) can be redistributed into the OSPF process. Use the connected keyword only when you have firewall interfaces that are not configured to participate in OSPF (as configured by the network OSPF command). Otherwise, OSPF automatically learns directly connected interfaces and their subnets from the OSPF configuration.

   Routes that are redistributed can be matched and altered by the route-map named map_name. If the route-map keyword is omitted, all routes are distributed.

   You can also set fixed values for the metric_value (0 to 16777214), the metric_type (internal, external, type-1, or type-2), and the route tag tag_value (an arbitrary number from 0 to 4294967295, used to match routes on other ASBRs) for all routes, not just ones matched by a route map.

   By default, only routes that are not subnetted (classful routes) are redistributed into OSPF unless the subnets keyword is given.

3. Redistribute routes from one OSPF process into another:

   Firewall(config-router)# redistribute ospf pid [match {internal | external
    [1 | 2] | nssa-external [1 | 2]}] [metric metric_value] [metric-type
    metric_type] [route-map map_name] [tag tag_value] [subnets]

   Routes from the other OSPF process ospf_pid can be redistributed into the OSPF process being configured. You can conditionally redistribute routes by using a route-map named map_name. If you omit the route-map keyword, all routes are redistributed.

   If you do not use a route map, you can still redistribute only routes with specific metric types by using the match keyword. The types include internal (internally generated), external (OSPF type 1 or 2), and nssa-external (OSPF type 1 or 2 coming into an NSSA).

   You can also set fixed values for the metric_value (0 to 16777214), metric_type (internal, external, type-1, or type-2), and the route tag tag_value (an arbitrary number 0 to 4294967295, used to match routes on other ASBRs) for all routes, not just ones matched by a route map.

   By default, only routes that are not subnetted (classful routes) are redistributed into OSPF unless the subnets keyword is given.

OSPF Example

A firewall is situated so that it connects to OSPF area 0 on its outside interface and to OSPF area 100 on its inside interface. Therefore, the firewall is an ABR. The outside interface is 172.19.200.2/24, and the inside interface is 192.168.1.1/24. One subnet on the inside has a public IP address range 128.163.89.0/24, and all the other inside networks fall within 192.168.0.0.

Because the inside firewall interface has a higher IP address, OSPF uses that address as its router ID by default. It might be better practice to use an outside address for exchanges with OSPF neighbors on the outside backbone area. Therefore, the router ID is configured for the outside interface address.

Network 172.19.200.0/24 falls in OSPF area 0, and 192.168.0.0/16 falls in OSPF area 100 on the inside. MD5 authentication is used for both the inside and outside OSPF areas.

The internal network 192.168.0.0 has private IP addresses and probably should not be advertised toward the outside. Therefore, a prefix list named InsideFilter is configured to allow only the internal subnet 128.163.89.0/24 (a global or public address range) to be advertised. In this case, the prefix list is applied to area 0 so that it filters routing information coming in to that area. The configuration to accomplish this is as follows:

Open table as spreadsheet

PIX 6.3

ASA

Firewall(config)# ip address inside 192.168.1.1 255.255.255.0 Firewall(config)# ip address outside 172.19.200.2 255.255.255.0 Firewall(config)# prefix-list InsideFilter 10 deny 192.168.0.0/16 Firewall(config)# prefix-list InsideFilter 20 permit 128.163.89.0/24 Firewall(config)# router ospf 1 Firewall(config-router)# router-id 172.19.200.2 Firewall(config-router)# network 172.19.200.0 255.255.255.0 area 0 Firewall(config-router)# network 192.168.0.0 255.255.0.0 area 100 Firewall(config-router)# area 0 authentication message-digest Firewall(config-router)# area 0 filter- list prefix InsideFilter in Firewall(config-router)# area 100 authentication message-digest Firewall(config-router)# exit Firewall(config)# routing interface outside Firewall(config-routing)#ospf message- digest-key 1 md5 myoutsidekey Firewall(config)# routing interface inside Firewall(config-routing)#ospf message- digest-key 1 md5 myinsidekey

Firewall(config)# interface gigabitethernet1 Firewall(config-if)# nameif inside Firewall(config-if)# ip address 192.168.1.1 255.255.255.0 Firewall(config)# interface gigabitethernet0 Firewall(config-if)# nameif outside Firewall(config-if)# ip address outside 172.19.200.2 255.255.255.0 Firewall(config-if)# exit Firewall(config)# prefix-list InsideFilter 10 deny 192.168.0.0/16 Firewall(config)# prefix-list InsideFilter 20 permit 128.163.89.0/24 Firewall(config)# router ospf 1 Firewall(config-router)# router-id 172.19.200.2 Firewall(config-router)# network 172.19.200.0 255.255.255.0 area 0 Firewall(config-router)# network 192.168.0.0 255.255.0.0 area 100 Firewall(config-router)# area 0 authentication message-digest Firewall(config-router)# area 0 filter- list prefix InsideFilter in Firewall(config-router)# area 100 authentication message-digest Firewall(config-router)# exit Firewall(config)# interface gigabitethernet1 Firewall(config-if)# ospf message- digest-key 1 md5 myoutsidekey Firewall(config-if)# interface gigabitethernet0 Firewall(config-if)# ospf message- digest-key 1 md5 myinsidekey Firewall(config-if)# exit

3-3: DHCP Server Functions

A firewall can act as a DHCP server, assigning IP addresses dynamically to requesting clients. A firewall DHCP server returns its own interface address as the client’s default gateway. The interface subnet mask is returned for the client to use as well.

Cisco firewalls support up to 256 active clients at any one time. (The Cisco PIX 501 supports either 32, 128, or 256 clients, depending on the user license.)

No provisions are available for configuring static address assignments. A firewall can manage only dynamic address assignments from a pool of contiguous IP addresses.

Beginning with ASA 7.2(1), a firewall can generate dynamic DNS information based on the DHCP server. This allows DNS records to be updated dynamically, as hosts acquire an IP address. The dynamic DNS feature is covered in detail in the “Updating Dynamic DNS from a DHCP Server” section later in this chapter.

A firewall can also act as a DHCP relay, forwarding DHCP requests received on one interface to DHCP servers found on another interface. DHCP relay is similar to the ip helper-address command on routers and switches running Cisco IOS Software.

The DHCP relay service accepts DHCP request broadcast packets and converts them to DHCP request unicast packets. The unicasts are forwarded to the DHCP servers. After DHCP replies are received, they are relayed back to the requesting client.

Using the Firewall as a DHCP Server

Follow these steps to configure the DHCP server feature:

1. Define an address pool for host assignments:

   Firewall(config)# dhcpd address ip1[-ip2] if_name
   

   The pool of available client addresses on the firewall interface named if_name (inside, for example) goes from a lower-limit address ip1 to an upper-limit address ip2. These two addresses must be separated by a hyphen and must belong to the same subnet. In addition, the pool of addresses must reside in the same IP subnet assigned to the firewall interface. In releases before PIX 6.3, only non-outside interfaces were supported. After 6.3, the outside interface can be used, too.

2. Supply clients with domain information.

   1. (Optional) Hand out dynamic information obtained by the firewall:

      Firewall(config)# dhcpd auto_config [outside]

      You can use this command if your firewall is configured to obtain IP address information for its interface from an independent DHCP server. After the DNS and WINS server addresses and the domain name are learned from the DHCP server, the firewall can push those same values out to its own DHCP clients. In this scenario, the firewall usually acts as a DHCP client on its outside interface and as a DHCP server on its inside interface.

      or

   2. (Optional) Hand out DNS server addresses:

      Firewall(config)# dhcpd dns dns1 [dns2]

      You can configure up to two DNS server addresses to hand out to DHCP clients. The server IP addresses are given as dns1 and dns2.

   3. (Optional) Hand out WINS server addresses:

      Firewall(config)# dhcpd wins wins1 [wins2]

      WINS servers are used to resolve Microsoft NetBIOS names into IP addresses. You can configure up to two WINS server addresses to hand out to DHCP clients. The WINS IP addresses are given as wins1 and wins2.

   4. (Optional) Hand out the domain name:

      Firewall(config)# dhcpd domain domain_name
      

      You can configure the domain name that the client will learn and use as domain_name (the fully qualified domain name, such as myexample.com).

3. Define the client lease time:

   Firewall(config)# dhcpd lease lease_length
   

   By default, the firewall supplies DHCP replies with lease times of 3600 seconds (1 hour). You can adjust the lease time to be lease_length seconds (300 to 2,147,483,647 seconds).

   Tip

   If your clients must compete for addresses in a relatively small pool, a shorter lease time is better. After a client is turned off, its lease runs out soon, and another client can be assigned that address. If most of your clients are stable and stay in use most of the day, you can lengthen the lease time. A longer lease time reserves an address for a client, even if that client turns off and returns later. Lease times also affect your ability to correlate workstations and their address assignments with Syslog entries from the firewall. Sometimes, you might need to track down which workstation was using a specific address on a certain day and time. The firewall logs only DHCP assignments, so if the lease times are long, the DHCP log entries are sparse and more difficult to find.

4. (Optional) Hand out options for Cisco IP Phones.

   Cisco IP Phones must receive additional information about their environment through DHCP. This information is sent as DHCP options.

   1. Identify the IP phone TFTP server:

      Firewall(config)# dhcpd option 66 {ascii server_name | ip server_ip}
      Firewall(config)# dhcpd option 150 ip server_ip1 [server_ip2]

      A Cisco IP Phone must find the TFTP server where it can download its configuration. This information is provided as either DHCP option 66 (a single TFTP server) or option 150 (up to two TFTP servers). You can define one or both of these options; the IP phone accepts and tries them both.

      If you use option 66, you can use the ascii keyword to define the TFTP server’s host name as server_name (a text string). Otherwise, you can use the ip keyword to define the server’s IP address as server_ip.

      If you use option 150, you can define one or two TFTP server addresses.

   2. (Optional) Identify the IP phone default routers:

      Firewall(config)# dhcpd option 3 ip router_ip1 [router_ip2]

      By default, the firewall sends its own interface address as the client’s default gateway. In some cases, there might be two potential gateways or routers for Cisco IP Phones to use. You can define these in DHCP option 3 as router_ip1 and router_ip2.

   3. (Optional) Provide a generic DHCP option:

      Firewall(config)# dhcpd option code {ascii string | ip ip_address
       | hex hex_string}

      If you need to provide an arbitrary DHCP option to clients, you can specify the option number as code (0 to 255). The option value can be an ASCII character string, an IP address, or a string of hexadecimal characters (pairs of hex digits with no white space and no leading 0x).

5. (Optional) Adjust the preassignment ping timer:

   Firewall(config)# dhcpd ping_timeout timeout
   

   When the firewall receives a DHCP request from a potential client, it looks up the next available IP address in the pool. Before a DHCP reply is returned, the firewall tests to make sure that the IP address is not already in use by some other host. (This could occur if another host had its IP address statically configured without the firewall’s knowledge.)

   The firewall sends an ICMP echo (ping) request and waits timeout milliseconds (100 to 10000 ms; the default is 750) for a reply. If no reply occurs in that time frame, it assumes that the IP address is indeed available and assigns it to the client. If an ICMP reply is received from that address, the firewall knows that the address is already taken.

6. Enable the DHCP server:

   Firewall(config)# dhcpd enable if_name
   

   The DHCP server starts listening for requests on the firewall interface named if_name (inside, for example). You can define and enable DHCP servers on more than one interface by repeating the sequence of DHCP configuration commands.

Tip

You can display the current DHCP server parameters with the show dhcpd EXEC command. To see the current DHCP client-address bindings, use the show dhcpd bindings EXEC command. To see the number of different DHCP message types received, use the show dhcpd statistics EXEC command. You can also see information about DHCP activity by using the debug dhcpd event command. This can be useful if you think a client is requesting an address but is never receiving a reply.

DHCP Server Example

A PIX Firewall is configured as a DHCP server for clients on its inside interface. Clients are assigned an address from the pool 192.168.200.10 through 192.168.200.200. They also receive DNS addresses 192.168.100.5 and 192.168.100.6, WINS addresses 192.168.100.15 and 192.168.100.16, and a domain name of mywhatastrangeexample.com.

Open table as spreadsheet

PIX 6.3

ASA or FWSM

Firewall(config)# ip address inside 192.168.200.1 255.255.255.0 Firewall(config)# dhcpd address 192.168.200.10-192.168.200.200 inside Firewall(config)# dhcpd dns 192.168.100.5 192.168.100.6 Firewall(config)# dhcpd wins 192.168.100.15 192.168.100.16 Firewall(config)# dhcpd domain mywhatastrangeexample.com Firewall(config)# dhcpd enable inside

Firewall(config)# interface gigabitethernet1 Firewall(config-if)# description inside Firewall(config-if)# ip address 192.168.200.1 255.255.255.0 Firewall(config-if)# exit Firewall(config)# dhcpd address 192.168.200.10-192.168.200.200 inside Firewall(config)# dhcpd dns 192.168.100.5 192.168.100.6 Firewall(config)# dhcpd wins 192.168.100.15 192.168.100.16 Firewall(config)# dhcpd domain mywhatastrangeexample.com Firewall(config)# dhcpd enable inside

Updating Dynamic DNS from a DHCP Server

Traditionally, hostnames and IP addresses have been associated through the use of DNS, requiring static configurations. While this might be practical for servers, which rarely change their hostnames or addresses, it does not lend itself to timely updates for clients that frequently change IP addresses.

Dynamic DNS (DDNS) solves this problem by keeping the DNS function, but allowing records to be updated dynamically, as they change. DDNS is most useful when it is teamed with a DHCP server; as the DHCP server hands out IP addresses to clients, it can send a DDNS update immediately. This allows mobile or transient clients to keep a stable hostname and to always be found through a DNS lookup.

On the ASA platform, the DDNS database can be updated from the following sources:

• The ASA DHCP server, as it provides IP addresses to PC clients

• The ASA DHCP client, as it requests an address from an ISP

• PC clients, as they send a DHCP request; the ASA can relay the DNS information provided by the clients

On the ASA, DDNS uses the IETF standard method defined in RFC 2136. Through DDNS, the following DNS resource records can be updated for a host:

• A resource record— Contains the hostname-to-address mapping (for example, www.cisco.com resolves to 198.133.219.25)

• PTR resource record— Contains the address-to-hostname mapping (for example, 219.133.198.in-addr.arpa resolves to www.cisco.com)

To use DDNS, you must configure either a DHCP client, a DHCP server, or both on the ASA. The DHCP mechanism is always used to send updates to a DNS server that is DDNS-capable. You can use the following steps to configure DDNS support:

1. Identify DNS servers that support DDNS:

   asa(config)# dns server-group DefaultDNS
   asa(config-dns-server-group)# dns name-server ip_address
   [ip_address2]...[ip_address6]
   asa(config-dns-server-group)# exit
   

   You can enter up to six IP addresses of DDNS servers where the ASA can send dynamic updates.

2. Enable DNS use on an interface:

   asa(config)# dns domain-lookup if_name
   

   Identify the ASA interface that is closest to the DNS servers. The ASA sends DDNS updates on that interface.

3. Define an update method:

   asa(config)# ddns update method method_name
   

   The DDNS update method policy is known by the arbitrary method_name string.

4. Specify the update method:

   asa(DDNS-update-method)# ddns [both]

   By default, the ASA attempts to update only the A resource record. You can add the both keyword to make it update both the A and PTR resource records.

5. (Optional) Set the maximum update period:

   asa(DDNS-update-method)# interval maximum days hours minutes seconds
   

   By default, the ASA sends DDNS updates only as they occur, based on the activity of DHCP clients. You can also set a maximum update interval, so that the ASA does not wait more than a defined time before sending another update. The interval is defined as days (0 to 364), hours (0 to 23), minutes (0 to 59), and seconds (0 to 59) and should be chosen to match the requirements of the DDNS servers.

6. (Optional) Send DDNS updates from the ASA DHCP client:

   asa(config)# interface if_name
   asa(config-if)# ddns update method_name
   asa(config-if)# ddns update hostname hostname
   asa(config-if)# ip address dhcp [setroute]

   The DDNS method named method_name (configured in Step 3) is used on the specified ASA interface. When the ASA DHCP client sends a DDNS update, it needs to know its own hostname. You can specify the hostname as hostname, as either a fully qualified domain name (FQDN) or as a hostname that is prepended to the ASA’s domain name (configured with the domain-name command).

   Finally, the ip address dhcp command starts the DHCP client and requests an IP address for the interface. As soon as an address is obtained, the DHCP client attempts to send its DDNS update to bind the IP address to the hostname.

   You can also specify the DDNS policy for the ASA DHCP client with the following interface configuration command:

   asa(config-if)# dhcp client update dns [server {both | none}]

   By default, the ASA DHCP client does not update its DNS record on its own. Issuing this command enables the client to send DDNS updates through the ASA DHCP server, toward the DNS. The client instructs the server to send only PTR updates, unless the server keyword is added, along with either the both (send both A and PTR updates) or none (send no DDNS updates) keyword.

   This command can also be given as a global configuration command, to provide a global policy for all interfaces. You can enter a global and an interface version of the same command; the interface command always overrides the global settings. Be aware that the global version of this command uses a hyphen (dhcp-client), while the interface version does not (dhcp client).

7. (Optional) Send DDNS updates from the ASA DHCP server:

   A DHCP server can be configured on an ASA, usually facing the inside or secure side where client PCs are located. The ASA can send DDNS updates based on the requests made from the clients to the DHCP server. You can configure the ASA DHCP server to send DDNS updates with the following global configuration command:

   asa(config)# dhcpd update dns [both] [override] [interface if_name]

   As soon as this command is given, the ASA DHCP server sends updates for PTR resource records only. You can add the both keyword to send both A and PTR records. If you add the override keyword, the ASA DHCP server overrides the information contained in all DHCP client requests—including the ASA DHCP client configuration. For example, a DHCP client might try to send a PTR record, but the DHCP server can override that by sending both A and PTR records.

   If you want to enable DDNS on only a single ASA interface, you can add the interface keyword. Otherwise, the ASA generates DDNS updates on any interface that has a DHCP server configured.

Tip

The ASA DHCP server generates DDNS updates on any interface that has a DHCP server configured. The ASA attempts a reverse DNS lookup on the DHCP client’s IP address, to find the authoritative DNS for the client’s domain. The Start of Authority (SOA) entry is requested for the client’s IP address. If the DNS does not already have the client’s domain configured, along with the SOA information, the ASA cannot register DDNS updates successfully. In the case of private or RFC 1918 addresses inside the firewall boundary, the DNS does not return a valid SOA for the private subnet unless the DDNS-capable machines in your network are already preconfigured with definitions for your local subnets, along with a correct SOA entry.

Verifying DDNS Operation

Because you can configure both DHCP client and DHCP server on a single ASA, you might become confused about what is actually configured and running on which interfaces. You can use the show dhcpd state command to see where the client and server functions exist, as in the following example.

Firewall# show dhcpd state
Context  Configured as DHCP Server
Interface outside, Configured for DHCP CLIENT
Interface inside, Configured for DHCP SERVER
Interface dmz, Not Configured for DHCP
Interface management, Not Configured for DHCP
Firewall#

You can use the show ddns update method to see the configured method and the show ddns update interface command to see the DDNS method that is applied to each ASA interface. Finally, you can view debugging output by entering the debug ddns command.

As an example, suppose an ASA is to be configured to provide DDNS updates to a DNS server. The ASA should have a policy to allow updates to both the A and PTR resource records, using the update method called myddns. On the outside interface, the ASA uses its DHCP client to obtain an address. The DHCP client also is allowed to send DDNS updates with its hostname (asa.mycompany.com) and its newly obtained IP address.

On the inside interface, the ASA should be configured to run a DHCP server for inside clients. As inside clients send DHCP requests, their hostname and assigned IP addresses are sent on as DDNS updates. The following commands could be used to accomplish these example requirements.

Firewall(config)# hostname asa
Firewall(config)# domain-name mycompany.com
Firewall(config)# ddns update method myddns
Firewall(config)# ddns both
!
Firewall(config)# interface Ethernet0/0
Firewall(config-if)# nameif outside
Firewall(config-if)# security-level 0
Firewall(config-if)# ddns update hostname asa.mycompany.com
Firewall(config-if)# ddns update myddns
Firewall(config-if)# ip address dhcp setroute
!
Firewall(config-if)# interface Ethernet0/1
Firewall(config-if)# nameif inside
Firewall(config-if)# security-level 100
Firewall(config-if)# dhcp client update dns
Firewall(config-if)# ip address 192.168.100.1 255.255.255.0
Firewall(config-if)# exit
!
Firewall(config)# dns domain-lookup outside
Firewall(config)# dns server-group DefaultDNS
Firewall(config-dns-server-group)# name-server 128.163.111.7
Firewall(config-dns-server-group)# domain-name mycompany.com
Firewall(config-dns-server-group)# exit
Firewall(config)# dhcp-client update dns
Firewall(config)# dhcpd dns 128.163.97.5 128.163.3.10
Firewall(config)# dhcpd update dns both
!
Firewall(config)# dhcpd address 192.168.100.10-192.168.100.254 inside
Firewall(config)# dhcpd enable inside

Relaying DHCP Requests to a DHCP Server

Follow these steps to configure a firewall to act as a DHCP relay:

1. Define a real DHCP server:

   Firewall(config)# dhcprelay server dhcp_server_ip server_ifc
   

   A real DHCP server can be found at IP address dhcp_server_ip on the firewall interface named server_ifc (inside, for example). You can repeat this command to define up to four real DHCP servers.

   When DHCP requests (broadcasts) are received on one firewall interface, they are converted to UDP port 67 unicasts destined for the real DHCP servers on another interface. If multiple servers are defined, DHCP requests are relayed to all of them simultaneously.

2. (Optional) Adjust the DHCP reply timeout:

   Firewall(config)# dhcprelay timeout seconds
   

   By default, the firewall waits 60 seconds to receive a reply from a real DHCP server. If a reply is returned within that time, it is relayed back toward the client. If a reply is not returned within that time, nothing is relayed back to the client, and any overdue server reply is simply dropped. You can adjust the timeout to seconds (1 to 3600 seconds).

3. (Optional) Inject the firewall interface as the default gateway:

   Firewall(config)# dhcprelay setroute client_ifc
   

   When DHCP replies are returned by a real DHCP server, a default gateway could be specified in the reply packet. By default, this information is passed on through the firewall so that the client receives it.

   You can configure the firewall to replace any default gateway information with its own interface address. This causes the DHCP reply packet to list the firewall interface closest to the client, the interface named client_ifc, as the default gateway.

4. Enable the DHCP relay service:

   Firewall(config)# dhcprelay enable client_ifc
   

   The DHCP relay service is started only on the firewall interface named client_ifc (inside, for example). This is the interface where DHCP clients are located.

DHCP Relay Example

A DHCP relay is configured to accept DHCP requests from clients on the inside interface and relay them to the DHCP server at 192.168.1.1 on the DMZ interface. The firewall waits 120 seconds for a reply from the DHCP server. The firewall’s inside interface address is given to the clients as a default gateway. You can use the following commands to accomplish this:

Firewall(config)# dhcprelay server 192.168.1.1 dmz
Firewall(config)# dhcprelay timeout 120
Firewall(config)# dhcprelay setroute inside
Firewall(config)# dhcprelay enable inside

Tip

You can monitor DHCP relay activity by looking at the output from the show dhcprelay statistics EXEC command. The output shows the counters of the various DHCP operations relayed to and from the real DHCP server, as in the following example: Firewall# show dhcprelay statistics Packets Relayed BOOTREQUEST 0 DHCPDISCOVER 7 DHCPREQUEST 3 DHCPDECLINE 0 DHCPRELEASE 0 DHCPINFORM 0 BOOTREPLY 0 DHCPOFFER 7 DHCPACK 3 DHCPNAK 0