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 (PIX 7.x) 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 following sources: Static routes (manually configured) RIP (dynamically learned or advertised) OSPF (dynamically learned or advertised)
As soon as other 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. 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 doesn't 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 can't be found, or the reverse-path interface doesn't 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 can't 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 can't 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 interfacenot 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 can't 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 [metric]
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, which is metric router hops away from the firewall. (The default is 1.)
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 isn't 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 [metric]
| 2. | Define a default static route:
Firewall(config)# route if_name 0.0.0.0 0.0.0.0 gateway_ip [metric]
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. This default gateway is located metric router hops away from the firewall (The default is 1.)
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 PIX 7.x 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 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
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 typea 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-10. Figure 3-10. 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.
- a. 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 doesn't advertise any routes to its internal or protected networks.
- b. 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 (PIX 7.x) 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 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 (LSAs). 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-11 shows this topology. Figure 3-11. 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-12 shows this topology. Figure 3-12. 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 doesn't 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 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 autonomous system (AS). Figure 3-13 shows this topology. Figure 3-13. 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-14 shows this topology. Figure 3-14. 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, don't 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:
%PIX-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 notationa 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 wouldn't want private networks to be advertised toward the outside for security and network translation reasons.
- a. 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). - b. 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.
- a. (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
- b. (Optional) Define a not-so-stubby area:
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).
- c. (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 don't 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.
- a. (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.
- b. (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.
- a. Select the OSPF interface to configure:
FWSM 2.x | Firewall(config)# routing interface if_name | PIX 6.x | Firewall(config)# routing interface if_name | PIX 7.x | Firewall(config)# interface if_name |
The firewall interface named if_name (inside or outside, for example) is configured for OSPF parameters.
- b. (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. - c. (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).
- d. (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).
- e. (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.
- a. 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.
- b. 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.
- c. (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 aren't 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: PIX 6.3 | PIX 7.x |
|---|
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
|
|
