Chapter 11: Switching Secured Content

Cisco Press

1 2 3 4 Page 3
Page 3 of 4
ssl-proxy vlan 99
 ipaddr 10.1.99.3 255.255.255.0 
 gateway 10.1.99.1
 admin

ssl-proxy vlan 20
 ipaddr 10.1.10.10 255.255.255.0
 gateway 10.1.10.1

ssl-proxy service ssl-termination
 virtual ipaddr 10.1.10.100 protocol tcp port 443 secondary
 server ipaddr 10.1.10.1 protocol tcp port 80
 no nat server
 certificate rsa mycontent-trustpoint certs-key
 inservice

Here are some notes to help you understand the configuration in Example 11-8.

  • The ssl-proxy service command creates the virtual server called "ssl-termination." Virtual servers on the daughter card function in the same manner as on content switches. You must assign the same IP address and port to the virtual server. When the SSL proxy receives packets that match the virtual server, it decrypts the packets and sends them to the configured real server using the server command, which is simply its default gateway (that is, the CSM-S IP address 10.1.10.1). If there were multiple CSM-Ss, you would add them using the server command.

  • Because this is a dispatch-mode configuration, you should disable server DNAT on the SSL daughter card using the no nat server command; otherwise, the request will be DNATed from the VIP to the IP address of the CSM.

  • Specify the RSA certificate that you want to assign to the service by using the certificate rsa command. This example uses the certificate "mycontent-trustpoint" imported in Example 11-6.

  • Because the SSL daughter card is in bridge-mode and is configured with the same virtual IP as the CSM-S, it receives the same ARP requests from the MSFC that the CSM-S receives. The secondary keyword prevents the SSL daughter card from responding to these ARP requests.

Configuring URL and Header Rewrite on the CSM

To enable the SSL daughter card to insert HTTP headers to inform the server that the SSL daughter card is proxying the connection, you can create an HTTP header policy on the SSL daughter card. Example 11-9 illustrates how to create an HTTP header policy and assign it to an SSL proxy service.

Example 11-9 Creating an HTTP Header Policy

ssl-proxy policy http-header insert-session-info
 session

ssl-proxy service ssl-termination
 virtual ipaddr 10.1.10.100 protocol tcp port 443 secondary
 server ipaddr 10.1.10.1 protocol tcp port 80
 no nat server
 certificate rsa mycontent-trustpoint certs-key
 policy http-header insert-session-info
 inservice

Similar to the CSS SSL daughter card, if your servers send HTTP 300 series redirects to your clients, then you should configure your CSM-S to rewrite the "http://" reference in the "Location:" header. To inspect the "Location:" header and replace "http://" with "https://" on the SSL daughter card, you can use the configuration in Example 11-10.

Example 11-10 Creating an HTTP URL Rewrite Policy

ssl-proxy policy url-rewrite rewrite-redirects
 url *.cisco.com 
 url http://www.cisco.*
 url http://www.cisco.com sslport 444 
 url http://www.cisco.com sslport 444 clearport 81

ssl-proxy service ssl-termination
 virtual ipaddr 10.1.10.100 protocol tcp port 443 secondary
 server ipaddr 10.1.10.1 protocol tcp port 80
 no nat server
 certificate rsa mycontent-trustpoint certs-key
 policy url-rewrite rewrite-redirects
 inservice

Firewall Load Balancing

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

Figure 11-3

CSS Firewall Load Balancing


Note - 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:

  1. The CSS A decides which firewall to switch the request to, based on the configured SLB policy (for example, round-robin or hashing the source and destination IP addresses).

  2. CSS A creates a connection entry for the request in its state table.

  3. The selected firewall processes the request, creates a connection entry in its connection table, and forwards the TCP SYN segment to the CSS B.

  4. CSS B simply forwards the packet to the destination: If the destination is a virtual server, the request is load-balanced to the server according to the rules specified for the server farm; otherwise, the packet is routed using the content switch's routing table.

  5. CSS B also creates a connection entry in its connection table.

  6. The server processes the request and sends a TCP SYN-ACK response back to CSS B.

  7. CSS B looks up the connection in its connection table based on the information in the IP and TCP headers in the response, and updates the connection state with the SYN-ACK.

  8. CSS B forwards the packet to the appropriate firewall based on the existing entry in its connection table.

  9. The firewall updates its state with the SYN-ACK packet and forwards it to CSS A.

  10. CSS A routes the request to the Internet per normal routing and updates its connection state.

  11. The client's ACK then completes the TCP full-handshake over the same path as the original SYN segment.

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

CSS A
ip firewall 1 10.1.10.2 10.1.20.2 10.1.20.1
ip route 10.1.30.0/24 firewall 1

ip firewall 2 10.1.10.3 10.1.20.3 10.1.20.1
ip route 10.1.30.0/24 firewall 2

interface e1 
 bridge vlan 10

interface e2 
 bridge vlan 10 

circuit vlan 10
 ip address 10.1.10.1 255.255.255.0
CSS B
ip firewall 1 10.1.20.2 10.1.10.2 10.1.10.1
ip route 0.0.0.0/0 firewall 1

ip firewall 2 10.1.20.3 10.1.10.3 10.1.10.1
ip route 0.0.0.0/0 firewall 2

interface e1 
 bridge vlan 20

interface e2 
 bridge vlan 20 

interface e3 
 bridge vlan 30 

circuit vlan 20
 ip address 10.1.20.1 255.255.255.0

circuit vlan 30
 ip address 10.1.30.1 255.255.255.0

Note - 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

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

! MSFC shared by both CSMs
interface vlan 10
 ip address 10.1.10.4 255.255.255.0
 no shutdown
! CSM A
mod csm 5
vlan 10 client
 ip address 10.1.10.1 255.255.255.0
 gateway 10.1.10.4

vlan 11 server
 ip address 10.1.10.1 255.255.255.0

serverfarm forward
 description ** Used to forward outgoing connections from the web servers **
 no nat server 
 no nat client
 predictor forward

serverfarm out-firewalls
 description ** Contains the outside interfaces of the firewalls **
 no nat server
 no nat client
 predictor hash address source 255.255.255.255
 real 10.1.10.2
 backup real 10.1.10.3
 inservice
 real 10.1.10.3
 backup real 10.1.10.2
 inservice

vserver in-connections
 description ** Distributes incoming connections from clients across firewalls ** 
 virtual 10.1.20.0 255.255.255.0 any
 vlan 10
 serverfarm out-firewalls
 inservice 

vserver out-connections
 description ** Forwards outgoing connections from the web servers according to routing table **
 virtual 0.0.0.0 0.0.0.0 any
 serverfarm forward
 vlan 11
 inservice
! CSM B
mod csm 6

vlan 20 client
 ip address 10.1.20.1 255.255.255.0

vlan 21 server
 ip address 10.1.20.1 255.255.255.0

serverfarm in-firewalls
 description ** Contains the inside firewall interfaces **
 no nat server
 no nat client
 predictor leastconns 
 real 10.1.20.2
 backup real 10.1.20.3
 inservice
 real 10.1.20.3
 backup real 10.1.20.2
 inservice

serverfarm web-farm
 description ** Contains the two web servers **
 nat server
 no nat client
 real 10.1.20.10
 
 inservice
 real 10.1.20.11
 inservice
vserver out-connections
 description ** Distributes outgoing connections initiated from the web servers across the available firewalls **
 virtual 0.0.0.0 0.0.0.0 any
 vlan 20
 serverfarm in-firewalls
 inservice 

vserver web-vip
 description ** Distributes incoming connections initiated from external clients across web servers ** 
 virtual 10.1.20.100 255.255.255.0 www
 vlan 21
 serverfarm web-farm
 inservice

Note - 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.


Note - 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.


Note - 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.

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