Firewalls can realize performance benefits from Cisco content switching by using Firewall Load Balancing (FWLB) technologies. Although most firewalls can be scaled inherently by supporting stateful failover to a standby unit, you can increase performance by load balancing requests across multiple active firewalls using the CSS or CSM.
CSS Firewall Load Balancing
To control traffic flowing in both directions across a group of firewalls, you must sandwich the group within two CSSs. The CSSs distribute requests over the firewalls and maintain the connection state flowing through the firewalls. The content switches use the state to intelligently switch packets from existing connections to the same firewall. Figure 11-3 illustrates how you can sandwich your firewalls between two CSSs.
Figure 11-3. CSS Firewall Load Balancing
You can provide CSS redundancy by installing two CSSs on both the inside and outside of the firewall group and configure the highly available features that you learned about in Chapter 10. This way you avoid having two single points of failure with the CSSs that are shown in Figure 11-3.
In Figure 11-3, consider an incoming TCP SYN segment from the Internet:
Configuring FWLB differs slightly from configuring standard server load balancing (SLB) because the traffic is not destined to the firewall, but to services behind the firewall. To configure firewalls on the CSS, use the command:
ip firewall index local_firewall_address remote_firewall_address remote_switch_address
You must configure the same index values on both CSSs. To add routes to back-end servers that you want to load balance across your firewalls, use the command:
ip route ip_address subnet_mask firewall index distance
Example 11-11 gives a sample FWLB configuration based on the topology in Figure 11-3.
Example 11-11. CSS FWLB
Firewalls have drastically improved in performance over the past few years. The content switch must be at least X times more powerful than the firewalls being balanced, where X is the number of firewalls being balanced. Although the CSS supports FWLB, the CSM is preferable for FWLB for new deployments because its performance is better than the CSS in terms of bandwidth and flow-handling capabilities. Also, the CSS does not support reverse sticky for Active-FTP, as you will learn in the next section.
CSM Firewall Load Balancing
As you will quickly learn, with the CSM in router-mode, virtual servers are required for any traffic to pass through it. As a result, the configurations are generally more complicated than those of the CSS, but can be much more flexible. For example, the CSM enables you to configure complex designs, including single-CSM FWLB and stealth-firewall load balancing, which are not possible with the CSS.
Figure 11-4 gives a basic dual-CSM FWLB topology.
Figure 11-4. Dual-CSM FWLB
To achieve the FWLB design in Figure 11-4, you can use the configuration in Example 11-12.
Example 11-12. Dual-CSM FWLB
In Figure 11-4, CSM A and CSM B are installed within the same chassis as the MSFC, in slots five and six, respectively.
When a client initiates a connection from the Internet to the web server virtual IP (VIP) 10.1.20.100 on CSM B, CSM A is the first CSM to receive the packet and performs a virtual server lookup, matching the client's TCP SYN packet to the VIP called in-connections. This VIP distributes incoming connections from clients across the available firewalls in the server farm "out-firewalls" using the least connections predictor, which will produce even more distribution across your firewalls than source IP hashing. Single-connection TCP protocols, such as SMTP and BGP, require only one TCP connection for the application to work. As a result, you do not require hashing or sticking of subsequent application requests that occur over different TCP connections to the originally selected firewall.
The server farm "out-firewalls" contains the outside IP addresses of the firewalls you are load balancing. For example, say that CSM A selects Firewall B for the new connection. Then, CSM A creates a new connection in its connection table and forwards the packet to Firewall B. Firewall B also creates a new connection in its connection table and forwards the packet to CSM B. CSM B creates a new connection in its connection table and performs a virtual server lookup, matching the virtual server called "web-vip." CSM B then performs delayed binding with the client and eventually load balances the request to a real web server (for example, Web01). Web01 responds with a TCP SYN-ACK that traverses the same firewall as the original SYN did due to the existing connection entry in CSM B's connection table.
If your firewalls support stateful failover, you can use the backup real real server configuration command to specify the backup firewall.
When either back-end web server requires the initiation of a connection to the Internet, CSM B first receives the TCP SYN segment (assuming you configure the reals with CSM B as their default gateway), performs a virtual server lookup, and matches its VIP called "out-connections." This VIP distributes connections initiated from web servers across the available firewalls in the server farm "in-firewalls" using destination IP address hashing. As with using source hashing for incoming requests, you should use destination hashing for outgoing requests to distribute the connections across the firewalls more evenly.
The CSM also supports UDP-based protocols for FWLB.
Similar to "out-firewalls" configured on CSM A, the server farm "in-firewalls" on CSM B contains the inside IP addresses of the firewalls you are load balancing. In this case, say that CSM B chooses Firewall A. Then both CSM B and Firewall A create a connection state entry for the new connection in their connection tables and forward the segment upstream. When CSM A receives the TCP SYN, it matches the segment with the VIP called "out-connections" and forwards the packet to the Internet using its internal routing table, as the server farm "forward" stipulates.
Configuring Reverse Stickiness
Recall the sticky features that you learned in Chapter 10. You can configure stickiness when you require load balancing multiple TCP flows of a session to the same server as the original flow, to retain information stored about the flow on the server. The same principle is true with FWLB. For applications that require multiple connections in the same direction within the same application session, such as HTTP and Passive-FTP, you can use IP session stickiness or distribution via address hashing to ensure that multiple TCP sessions stick to the same firewall. That is, you can apply the same "forward" sticky configuration that you learned in Chapter 10 to FWLB.
However, for applications that open connections in both directions within the same session, such as Active-FTP, you must use IP reverse-sticky to ensure that TCP connections in the reverse direction take the same firewall. In the previous example, CSM A chose Firewall B for the client connection, but CSM B chose Firewall A for the server-initiated connection. With applications such as Active-FTP, you will require CSM B to choose Firewall B so that your firewall can reconcile the FTP data and control "buddy" connections for security purposes. Refer to Figure 11-5 to understand how IP reverse-sticky works.
Figure 11-5. IP Reverse-Sticky
Configuring IP reverse-sticky on CSMB enables it to store a sticky entry in its sticky table during the initial connection made by the client. IP reverse-sticky forces CSMB to override its normal load balancing decision-making process for subsequent connection requests made by the real servers to clients located in its sticky database.
To configure IP reverse-sticky on CSMB, you can use the configuration in Example 11-13, as applicable to the previous HTTP configuration on CSM B; however, HTTP virtual servers do not normally require reverse-stickyActive-FTP is the most common application to use reverse-sticky.
Example 11-13. IP Reverse-Sticky
In Figure 11-5 you can see that, when the incoming client connection via Firewall B matches the virtual server "web-vip," CSM B creates a sticky entry with the client's source IP address (10.1.10.99) and the real server (Firewall B) in the sticky database. Subsequent TCP connections from the back-end real servers trigger CSM B to perform a sticky table lookup on the destination IP address of the request. If a real server initiates a connection to 10.1.10.99, CSM B forwards the TCP SYN request through Firewall B, thus overriding the normal outgoing load-balancing method of destination hashing.
Configuring Single-CSM FWLB
In a single-CSM FWLB configuration, as Figure 11-6 suggests, you must connect the inside and outside interfaces of the firewalls directly to the CSM.
Figure 11-6. Single-CSM FWLB
Example 11-14 gives a single-CSM FWLB configuration.
Example 11-14. Configuring FWLB with a Single CSM
When the CSM receives a client TCP SYN segment from the client VLAN 10 for the VIP 10.1.40.100, it performs a virtual server lookup and matches it to virtual server "in-connections." The CSM then load balances the request across the two firewalls that are shown in Figure 11-6 and chooses Firewall B. The CSM forwards the request out on VLAN 20, and Firewall B forwards it back on VLAN 30. The CSM receives the request on VLAN 30, performs another virtual server lookup, and matches the virtual server called "web-vip." The CSM load balances the request to the realreturn traffic from the real flows through the same firewall given the existing CSM connection table entry.
Server-originated connections arrive to the CSM from VLAN 40, match the VIP "out-conns-40," and are load balanced to the firewalls. The firewalls forward the outgoing connection requests back to the CSM on VLAN 20. The CSM matches the VIP "out-conns-20" and forwards the request to the client using its routing table.
To configure stealth-mode FWLB, refer to your product documentation on Cisco.com.