Chapter 11: Switching Secured Content

Cisco Press

1 2 3 4 Page 4
Page 4 of 4

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

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-sticky—Active-FTP is the most common application to use reverse- sticky.

Example 11-13 IP Reverse-Sticky

sticky 77 netmask 255.255.255.255 address destination timeout 100

vserver out-connections
 virtual 0.0.0.0 0.0.0.0 any
 vlan 20
 serverfarm in-firewalls
 sticky 100 group 77
 inservice 

vserver web-vip
 virtual 10.1.20.100 255.255.255.0 www
 vlan 21
 serverfarm web-farm
 reverse-sticky 77
 inservice

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

Figure 11-6

Single-CSM FWLB

Example 11-14 gives a single-CSM FWLB configuration.

Example 11-14 Configuring FWLB with a Single CSM

mod csm 4
 vlan 10 client
 description *** Client's initiate connections from VLAN 10
 ip address 10.1.10.1 255.255.255.0

 vlan 20 server 
 description *** VLAN 20 contains the firewalls outside interfaces  ip address 10.1.20.1 255.255.255.0

 vlan 30 server
 description *** VLAN 30 contains the firewalls inside interfaces
 ip address 10.1.30.1 255.255.255.0

 vlan 40 server 
 description *** Internal subnet for web servers  ip address 10.1.40.1 255.255.255.0

serverfarm forward
 no nat server 
 no nat client
 predictor forward

serverfarm in-firewalls
 description ** Contains the inside interfaces of the firewalls **  no nat server
 no nat client
 predictor hash address source 255.255.255.255
 real 10.1.20.10
 inservice
 real 10.1.20.11
 inservice

serverfarm out-firewalls
description ** Contains the outside interfaces of the firewalls **
 no nat server
 no nat client
 predictor hash address destination 255.255.255.255
 real 10.1.30.10
 inservice
 real 10.1.30.11
 inservice

serverfarm web-farm
 description ** Contains the web servers **
 nat server
 no nat client
 real 10.1.40.10
 inservice
 real 10.1.40.11
 inservice

vserver in-connections
 description ** Distributes incoming connections across the two firewalls **
 virtual 10.1.40.0 255.255.255.0 any
 vlan 10
 serverfarm out-firewalls
 inservice

vserver out-conns-20
 description ** Routes outgoing connections from the web servers from VLAN 20 to the Internet according to the routing table **
 virtual 0.0.0.0 0.0.0.0 any
 serverfarm forward
 vlan 20
 inservice

vserver out-conns-40
 description ** Distributes outgoing connections from the web servers from VLAN 40 across the two firewalls **
 virtual 0.0.0.0 0.0.0.0 any
 vlan 40
 serverfarm in-firewalls
 inservice

vserver web-vip
 description ** Distributes incoming connections from the Internet from VLAN 30 across the two web servers **
 virtual 10.1.40.100 255.255.255.0 www
 vlan 30
 serverfarm web-farm
 inservice

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 real—return 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.


Note - To configure stealth-mode FWLB, refer to your product documentation on Cisco.com.


VPN Load Balancing on the CSM

You can load balance VPN connections across the CSM to increase the performance and provide redundancy to your VPN termination devices. Example 11-15 gives a dispatch-mode CSM VPN load balancing configuration.

Example 11-15  Configuring VPN Load Balancing on the CSM

serverfarm vpn-farm
 no nat server
 no nat client
 real 10.1.10.10
  inservice
 real 10.1.10.12
  inservice

 sticky 5 netmask 255.255.255.255 timeout 60

 policy vpn-policy
 sticky-group 5
 serverfarm vpn-farm

vserver vpn-ah
 virtual 10.1.10.100 51
 slb-policy vpn-policy
 inservice

 vserver vpn-esp
 virtual 10.1.10.100 50
 slb-policy vpn-policy
 inservice

vserver vpn-ike
 virtual 10.1.10.100 udp 500
 slb-policy vpn-policy
 inservice

Note - The CSS does not support VPN load balancing because it does not understand the IPSec protocols.


To configure your CSM for VPN load balancing, you must create virtual servers for the Authentication Header (AH), Encrypted Security Payload (ESP), and Internet Key Exchange (IKE) protocols. Similar to SSL, IPsec-based VPNs use multiple TCP connections to establish VPN sessions. Therefore, to ensure that clients stick to the same VPN concentrator across TCP connections, you should configure source IP address stickiness using the sticky netmask command.


Note - If you want to configure directed-mode VPN load balancing, simply enter the command nat server in server farm configuration mode. Be cautious when rewriting fields within VPN traffic on your content switch because many VPN protocols have security features that protect the integrity of VPN messages.


Preventing Connection Table Flooding using SYN-Cookies

To avoid filling up its connection table during SYN-flood-based Denial of Service (DoS) attacks, the CSM uses SYN-cookies, which were covered briefly in Chapter 4. With SYN-flood attacks, the attacker sets random source IP addresses in numerous SYN packets that it sends to its victim. The victim receives the SYN packet, creates an entry in its connection table, responds with a TCP SYN-ACK packet, and awaits the final ACK segment from the sender. The final segment never arrives. Thus, the victim's connection fills very quickly with incomplete TCP connection entries.

However, with SYN-cookies, instead of allocating a record for every SYN segment from its clients, the CSM sends SYN-ACK segments with carefully constructed sequence numbers generated as a hash of connection's 4-tuple, the Maximum Segment Size, and a secret that continuously changes as time goes by. The connection 4-tuple contains the source and destination IP addresses and source and destination ports. When valid clients respond to the SYN-ACK with an ACK, they will include this special sequence number, which the CSM can verify before creating the connection entry. Without SYN-cookies, the CSM creates connection entries when it receives the initial SYN packet from clients. With SYN-cookies, the CSM creates the connection when it verifies the client's ACK segment to complete the connection. Because SYN-flood attackers typically do not respond to SYN-ACK segments, the SYN-flood traffic will not flood the CSM's connection table. Figure 11-7 illustrates SYN-cookies in practice.

Figure 11.7

Figure 11-7

Using SYN-Cookies to Prevent SYN-Flood Traffic from Flooding the CSM Connection Table

Summary

In this chapter, you learned how to configure the following technologies on your content switches:

  • Secure Sockets Layers (SSL) Termination—You learned how to configure your CSS and CSM to terminate SSL connections on behalf of clients.

  • Firewall Load Balancing (FWLB)—You learned how to configure your CSS and CSM to distribute client traffic across multiple firewalls.

  • Virtual Private Network (VPN) Load Balancing (FWLB)—You learned how to configure your CSM to distribute client traffic across multiple VPN concentrators.

  • SYN-Cookies for SYN-Flood Protection—You learned how the CSM uses SYN-cookies to prevent SYN-flood attacks from flooding the CSM's connection table.

Content switching enables you to increase the performance of your SSL, firewall, and VPN devices, in terms of packets per second, connections per second, and bandwidth. You can also increase the scalability of these devices with content switching technologies.

Review Questions

  1. What sticky configuration should you perform in an SSL termination environment?

  2. What is the purpose of HTTP header insertion and URL rewriting?

  3. What is the purpose of IP reverse-sticky?

  4. Why should you "sandwich" your firewalls with content switches when performing FWLB?

  5. In Example 11-12, why should you configure source IP address hashing on incoming requests and destination hashing on requests initiated by the web servers?

  6. How would you apply reverse-sticky in the single-CSM example in Example 11-14?

Recommended Reading

Chandra Kopparapu, Load Balancing Servers, Firewalls, and Caches. Wiley, 2002

RFC 2402. "IP Authentication Header, IETF." http://www.ietf.org/rfc/rfc2402.txt, 1998

RFC 2406. "IP Encapsulating Security Payload (ESP)." IETF, http://www.ietf.org/rfc/rfc2406.txt, 1998

RFC 2409. "The Internet Key Exchange (IKE)." IETF, http://www.ietf.org/rfc/rfc2409.txt, 1998

Copyright © 2007 Pearson Education. All rights reserved.

l>

Learn more about this topic

 
Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Related:

Copyright © 2008 IDG Communications, Inc.

1 2 3 4 Page 4
Page 4 of 4
SD-WAN buyers guide: Key questions to ask vendors (and yourself)