Case Studies
| In this section, we discuss two important features of FWSM in detail:
Case Study 1: Multiple SVI for FWSMIn this case study, you will learn the concept of SVI interfaces on the MSFC and the need for configuring multiple SVI interfaces. As previously stated, SVI stands for Switched Virtual Interface. It represents a logical Layer 3 interface on a switch. For Catalyst Operating System (CatOS) versions earlier than 7.6(1) and Cisco IOS Software releases earlier than 12.2(14)SY, only one SVI is allowed as part of the Firewall VLANs. In other words, only one Layer 3 interface can be configured between the FWSM and Multilayer Switch Feature Card (MSFC). Attempting to configure multiple SVIs produces a command-line interface (CLI) error message. For CatOS Versions 7.6(1) and later and Cisco IOS Software releases 12.2(14)SY and later, the FWSM supports multiple SVIs. By default, only one SVI is supported. To enable support for multiple SVIs on your switch on Native IOS, use the following command: Cat6509(config)# firewall multiple-vlan-interfaces Warning: enabling multiple VLAN interfaces may result in traffic bypassing the F WSM - use with caution! Cat6509(config)# On the hybrid mode, you can use the following command to turn on the multiple SVI interface: Cat6509# set firewall multiple-vlan-interfaces {enable | disable} Traffic is sent to the Firewall Services Module (FWSM) by way of Virtual LANs (VLAN) exclusively. The FWSM has no concept of physical ports of its own. Instead, you need to map VLANs to the FWSM interface. For instance, VLAN 30 in Figure 4-7 is mapped to the inside interface, whereas VLAN 20 represents the outside interface. Physical switchports are then placed into either VLAN, and hosts connect to those ports. When communication occurs between VLANs 20 and 30, the FWSM is the only available path, forcing traffic to be inspected statefully. Figure 4-7. One SVI Interface Typical Setup In Figure 4-7, the default gateway for the two hosts on VLAN 30 exists only on the FWSM. In other words, no interface VLAN 30 is ever created on the MSFC. VLAN 30 is mapped directly to the inside interface on the FWSM. Software that supports the FWSM (CatOS 7.5(1) or higher; Supervisor IOS 12.1(13)E or higher) automatically includes a built-in security check that prevents a user from creating a second connection to the MSFC, interface VLAN 30. If a user can create such an interface, traffic from the hosts can bypass the FWSM as shown in Figure 4-8. Figure 4-8. Host Bypassing in Multiple SVI Interfaces In Figure 4-8, interface VLAN 30 is created on the MSFC and is assigned an IP address 10.1.30.2/24. Hosts at the bottom of the figure also reside in VLAN 30. Either accidentally or intentionally, the inside users may bypass the FWSM altogether. Besides, discovering these multiple paths may be achieved without much grief, if insiders have bad intentions. The more serious problem is whether outside traffic from non-secure VLAN 10 can reach the inside subnet directly through the MSFC, which creates a major security breach. Why Change the Existing Model?As discussed earlier, the automatic check preventing more than one VLAN interface between the MSFC and the FWSM is extremely valuable to prevent accidental security holes. However, there are a few scenarios in which being able to bypass that check is required. CatOS release 7.6(1) or higher and Supervisor IOS 12.2(14)SY has the option of turning on the ability of multiple SVI interfaces to bypass the check. The commands used for both CatOS and Sup IOS are listed in Table 4-5.
Scenario One: DHCP Helper with FWSM 1.1(x)When running release 1.1(x), the FWSM drops incoming UDP broadcasts. Protocols such as DHCP (RFC 2131) rely on such packets extensively, and the lack of DHCP helper functionality in the FWSM can be problematic in certain designs. This section explains how the multiple VLAN interfaces can work around that shortcoming. Take a look at the sample topology depicted in Figure 4-9. Suppose two hosts on VLAN 30 (inside screened subnet) would like to acquire an IP address using DHCP. The enterprise's DHCP server is located off another screened subnet on VLAN 10. VLAN 20 represents the outside network and binds the MSFC to the FWSM. Finally, VLAN 500 connects the Catalyst 6500 switch to the "outside world." Figure 4-9. Hosts Bypassing In Multiple SVI Interfaces for DHCP First, enable the multi-VLAN knob. Then create an interface VLAN 20 on the MSFC and assign the IP address 10.1.20.1/24 to it. You can also create an interface VLAN 30 and assign 10.1.30.254/24 to it. By doing this, you have actually connected the inside subnet directly to the MSFC. This means that your two hosts can bypass the firewall. To prevent this, apply an inbound access-list to interface VLAN 30 to allow only DHCP requests. Here is a quick background on the operation of the DHCP protocol:
DHCP messages from a client to a server are sent to the UDP port 67, and DHCP messages from a server to a client are sent to UDP port 68. Therefore, in the scenario, a simple input access-list needs to be applied to VLAN 30 on the MSFC to allow only UDP broadcasts where source port=68 and destination port=67. This takes care of allowing client-sourced messages to reach the DHCP server. You then add an IP helper-address statement to point to the DHCP server, as shown in Example 4-27. Example 4-27. Configuring ip helper-address on MSFC
You also need to tell the MSFC how to reach the DHCP server (via the Firewall). Example 4-28 shows the route configuration that is needed to accomplish this. Example 4-28. Route Needed on the MSFC
This configuration allows the MSFC to receive UDP broadcasts on VLAN 30 and transform them into IP unicast requests destined to 10.1.10.200 (source IP address 10.1.30.254). You need to verify that this traffic is allowed to cross the firewall. This takes care of the traffic between the client and the server. What about the opposite direction? The server unicasts its replies back to the relay agent's IP address, always. In this case, these packets look like that shown in Table 4-6.
Firewalls in general do not support asymmetric routing. That is, in this case, you have to force the DHCP offer from the DHCP server to go back out VLAN 20, even though VLAN 30 is connected directly. You need to add the route shown in Example 4-29. Example 4-29. Route Needed for Proper Routing
Return traffic from the DHCP server enters VLAN 10 and is routed onto VLAN 20 directly by the firewall. The relay agent receives the offer packet and in turns hands out an IP address to the DHCP client. There is still one problem that needs to be solved, however. We have to ensure that traffic originated from the core (off VLAN 500) that is destined to the inside screened subnet (VLAN 30) does not bypass the firewall. By default, it will bypass the firewall because the MSFC has an interface connected to VLAN 30 (admin distance 0). Policy routing comes to the rescue. Apply an incoming policy routing rule on interface VLAN 500 that reads any traffic destined to 10.1.30.0/24, your next-hop is 10.1.20.2. Example 4-30 shows the configuration for policy routing. Example 4-30. Configuration Needed For Policy Routing
Scenario Two: Alternate ConfigurationAn alternate configuration is depicted in Figure 4-10. Figure 4-10. Host Bypassing in Multiple SVI Interfaces for DHCP It is also possible to instruct the relay agent (10.30.1.254) to send packets destined to the DHCP back out interface VLAN 30. This is done by configuring this static route on the MSFC as shown in Example 4-31. Example 4-31. Route Configuration Needed on the MSFC
This way, the inside interface of the FWSM receives all traffic sourced from 10.99.99.254 this time, in contrast to the previous example in which that traffic comes in via interface VLAN 20. This means the static route previously installed on the FWSM can be removed, as shown in Example 4-32. Example 4-32. Route Removal on MSFC
That is because traffic returning from the DHCP server will naturally prefer the directly connected interface to reach 10.99.99.254. The router access-list needs to be slightly modified to resemble Example 4-33, to allow DHCP offer and ack messages sent by the DHCP server. Example 4-33. Access-list Needed on the MSFC
The policy routing configuration still applies. Case Study 2: Understanding Access-List Memory UtilizationAs stated previously, the Network Processors for the FWSM are used as hardware assistants to the generic CPU, relieving it from heavy packet processing such as access-list verification, network address translation, TCP sequence number randomization, and so on. One of these three network processorsnamely NP3is responsible for permitting or rejecting initial packets depending on the rules specified by the security policy. In other words, NP3 enforces access-list decisions in hardware. To do so, access-lists encoded via the command line interface (CLI) or graphical user interfaces (GUI) are compiled into a form that the hardware can recognize. NP3 comes equipped with 20MB of on-board memory (non-expandable) reserved for rules storage. Those 20MB are reserved for security policy rules exclusively:
It is worth noting that translation entries or connection entries do not borrow from that memory space. The goal of this application note is to provide further details regarding the way access-lists are stored and processed on the FWSM. The Compilation Process: Active and Backup TreesNP3 carves that 20MB memory space differently depending on the operating mode (single or multiple mode). With the FWSM running in single mode (release 1.1(x) or 2.2(x)), NP3 uses a dual-tree structure and halves the 20MB into two equal-sized chunks. One tree is called the active tree, and the other is called the backup tree. A tree contains a certain number of nodes. A node is a 64-byte data structure used to store IP addresses and masks, and a corresponding action (permit/deny). Shortly after a new access-list entry has been entered, modified or deleted, a compilation process is run on the generic CPU to transform the human-readable ACL into a form that the hardware can digest. The compilation process is automatically started by defaultthat is, once an access-list entry has been entered, it is shortly thereafter compiled into NP3. The following sequence captured from the CLI illustrates this: FWSM(config)# access-list test permit udp host 10.1.1.1 any eq 69 Access Rules Download Complete: Memory Utilization: < 1% FWSM(config)# At the end of a successful compilation, rules are pushed down to NP3. During the compilation process, it is important that through-traffic still undergoes security checks using the access-list entries already in place. This is the reason for the backup tree. The backup tree is a mirror of the active tree. It is switched to active mode once the compilation process is running, so the compilation can run in the background without interrupting traffic currently switched by the FWSM. Once the compilation is finished, trees are switched back again. How Memory Is Allocated: Release 1.1(x) or 2.2(1) in Single ModeWith release 1.1(x) or when running 2.2(1) in Single mode, the 20MB memory space is carved up evenly into two 10MB chunks. When the FWSM is running in single mode, a maximum theoretical limit of 63078 ACEs can be configured out of a total of 82819 rules (see Example 4-34 for the breakdowns of this number). Example 4-34. Breakdowns in the Number of Nodes in NP3 Processors for Memory
Note In 2.2 Single mode, there are 2 extra partitions reserved for downloadable ACLs (one active and one backup). Note that connection entries or NAT translations do not borrow from this memory space. When a modification is made to an ACE (new entry, deletion, modification), the entire tree is recompiled. This is the reason for the sustained high CPU utilization when a substantial amount of ACE is present. The compilation task runs on the generic CPU, but the final result is pushed down to the hardware. Note that the mapping between ACE and node utilization is not necessarily one-to-one. This means that some ACEs such as permit udp 10.0.0.0 255.0.0.0 172.16.0.0 255.255.0.0 can expand into multiple nodes in a tree, resulting in fewer than 63078 total ACEsyour mileage may vary. Optimizations for certain types of ACEs were brought into release 2.2(1.11), significantly reducing the expansion of ACEs using wildcards such as permit udp any any. How memory is Allocated: Release 2.2(1) in Multiple ModeWhen running in Virtual Firewall mode, both the carving scheme and the compilation process are slightly different and optimized for larger configurations. Instead of a dual tree structure, the memory is organized into 15 trees. Out of these 15 trees, two are used for user-downloadable ACE (one active + one backup). This leaves 13 trees: 12 active and one backup. The 20MB are divided unevenly between the 15 trees: trees 13 and 14 are smaller (3071 entries) because they are reserved for user-downloadable ACEs. Within each one of the 13 other trees, space is allocated as shown in Example 4-35. Example 4-35. Allocation of Memory Space on One of the Thirteen Trees
Where 1.1(x) and 2.2(1) single mode offered a total of 82819 rule entries, multiple mode nearly doubles that figure: (12 x 12766) + (2 x 3071) = 159334. That is normal because the allocation scheme no longer reserves an entire 10MB of space for the backup tree. Each tree being now much smaller, a backup size of 1/13 of the total space is sufficient. This also implies that in multiple mode each tree is compiled independently. The following formula generally works to compute the maximum number of rules available per FWSM:
With 12 active trees X = 13 (because of the backup tree), so the maximum number of rules per tree with 12 active trees is 160K/13 = roughly 12300. Keep in mind that this includes the number of filter, AAA, ICMP, Telnet rules, and so on. Table 4-7 records the exact maximum numbers per partition.
Trees and contexts: A Matter of MappingAs contexts (virtual firewalls) are created, they are assigned to an ACL memory pool in a round-robin fashion. Although this satisfies a large majority of applications, in some cases this fixed 12-tree allocation of memory space is no longer optimum. Examine the following examples:
FWSM release 2.3 brings a better ACL partition management scheme to better address the three scenarios just discussed. FWSM Release 2.3: The ACL Partition ManagerStarting with release 2.3, the system administrator is given the possibility to modify the ACL memory space-carving scheme. Instead of the default 12-pool model plus two trees for downloadable ACLs, the administrator can choose to divide the space into only three large chunks, or eight, or only one, depending on the needs of a particular configuration. Suppose, for instance, that it has been determined that there are never going to be more than six contexts on this FWSM: the super-user can opt for a six-pool allocation scheme. A new command line interface is introduced for this purpose. It is available only from the system context, for obvious reasons. Note that the module must be reloaded before a new allocation scheme takes effect. Up to 12 partitions can be created, and if you try to create more than 12, following message will be displayed: FWSM(config)# resource acl-partition 144 ERROR: Incorrect number of partitions. Allowed range is 1 - 12 Usage: resource acl-partition <number-of-partitions> The following example shows allocating three partitions: FWSM(config)# resource acl-partition 3 WARNING: This command leads to re-partitioning of ACL Memory. It will not take affect until you save the configuration and reboot. FWSM(config)# write memory FWSM(config)# reload When the system comes back online, the command in Example 4-36 displays the context-to-partition mapping. Note that even though three partitions were specified via the CLI, six partitions are actually created: three as required by the administrator, one backup, and two for downloadable ACLs. By default, a round-robin scheme is applied to map contexts to ACL partitions: Example 4-36. Resource Allocation for ACL after Changing the ACL-partition to 3
However, contexts can be manually mapped to a given partition. This is achieved in the context definition, as shown in Example 4-37. Example 4-37. Allocating Different Partitions from the Context
Examples of ACL CompilationStarting from a clean, empty configuration (Version 1.112.2 single mode), the ACL statistics report 0 is as follows: FWSM(config)# show np 3 acl stats ---------------------------- ACL Tree Statistics ---------------------------- Rule count : 0 Bit nodes (PSCB's): 0 Leaf nodes : 0 Total nodes : 0 (max 157696) Leaf chains : 0 Total stored rules: 0 Max rules in leaf : 0 Node depth : 0 ---------------------------- FWSM(config)# A simple ACL usually translates to one entry in the hardware, as illustrated in Example 4-38. Example 4-38. ACL Stats After Creating Just A Single ACL
ACEs that use object-groups expand in multiple lines. Example 4-39 results in 12 actual ACEs (3 hosts x 4 ports): Example 4-39. ACL Statistics Using Object Groups in the ACL
One ACE expands into 432 entries, using relatively simple object-groups. This is normal because the ACL would require 432 individual ACEs anyway, if object-grouping was not used: FWSM(config)# show access-list | include elem access-list simple; 432 elements FWSM(config)# Access-lists: Best PracticesThe following is a list of rules of thumb that will help you reduce the hardware resources occupied by ACEs:
The time it takes to compile a tree is largely irrelevant because while the compilation is taking place, the "old" tree is still in place. Given that compilation time is not a critical factor, the use of a single partition is recommended. For backward compatibility, 2.3(1) ships with 12+2 partitions by default. |
EAN: 2147483647
Pages: 190