LinkProof And Load Balancing Technical Application Note May 2008 North America Radware Inc. 575 Corporate Dr. Suite 205 Mahwah, NJ 07430 Tel 888 234 5763 International Radware Ltd. 22 Raoul Wallenberg St. Tel Aviv 69710, Israel Tel 972 3 766 8666 www.radware.com
Page - 2- Table of Contents Introduction...3 Overview...3 in IP networks...3 - IPsec and IKE...3 IPSEC...3 IKE...4 Network Traffic Associated with IPsec and IKE...4 LinkProof, Firewalls and...5 Load Balancing...5 Multicast...8 Load Balancing Clear Client Table...9 Load Balancing Client Table Overwrite...11
Page - 3- Introduction (Virtual Private Networks) enables connectivity between one or more network site (physical or virtual). To Local users, administrators and servers working with, it is as if connecting to one s own LAN extension. The name Virtual describes a common scenario where connected networks can be on 2 sides of the Internet (or WAN) and connect via 2 specific gateways in a manner that makes the connection transparent. The word Private comes from the idea that the data shared between the networks can be encrypted, tunneled or both, to ensure that it is private and not shared by unwanted parties. describes 2 networks which are connected over public networks (Internet or WAN) that encrypt traffic. Only these 2 sites can decrypt and share information between them. Overview in IP networks has many implementations (Layer 3, Layer 2, SSL etc). In this document Load Balancing scenarios are explained, as well as in IPsec / IKE as stated in the following RFCs (RFC 2409 IKE & RFC 2401 IPsec). The LinkProof proposed scenarios and solutions were tested using the above protocols. Common vendors use Routers, Firewalls, Gateways or a specially designed encryption device in order to provide the ability to the customers. The traffic uses IP protocols and encrypted algorithms based on common algorithms such as DES, 3DES and AES. Radware also provides connectivity to the LinkProof Branch product line. - IPsec and IKE IPSEC encryption uses the IPsec (IP Security) as stated in the above RFC. IPsec encrypts the data but also includes the entire packet and adds new IP and ESP headers with a new source and destination (usually the encryption / decryption devices). In order to ensure encryption and authenticity of the data passing through the connection, a set of IPsec encryption keys is agreed upon between the encrypting traffic.
Page - 4- IKE The management and exchange of the encryption keys is a lengthy task if done manually. A negotiation protocol IKE (Internet Key Exchange) has been devised (formerly known as ISKAMP / OAKLEY) which lessens the process. The IKE protocol (essentially an IPsec support protocol) performs the initial negotiations between the encryption parties regarding how to encrypt, what to encrypt and also when the encryption keys need to change. Network Traffic Associated with IPsec and IKE 2 gateways encrypting traffic using IKE / IPsec, appears as follows: UDP port 500 (IKE negotiation) (L4 type Traffic) o 6 packets 'main mode' A.K.A Phase 1 o 3 packets 'quick mode' A.K.A Phase 2 IPsec (L3 type traffic) o AH (authentication Header) & ESP (Encapsulated Security Payload) The traffic described above shows the 1st few packets that perform an IKE session with port number UDP 500. After the IKE session has finished IPSec starts working and L3 becomes visible (AH and ESP). Usually IKE traffic is not visible in such a session unless phase 1 has been re-negotiated, or the traffic breaks and the gateways try to establish new connections. Note: The above description is a general one and does not take into consideration the various flavors of IKE / IPsec, such as the Aggressive mode which is not in the scope of this document. For further information please refer to the appropriate RFCs.
Page - 5- LinkProof, Firewalls and LinkProof as a Link availability aware device is usually installed behind the Routers and in Front of the Firewalls. This creates a number of challenges regarding load balancing deployment scenarios. The challenges are usually associated with the fact that LinkProof does not sync and does not obtain data from the Firewall / devices. This is a concern especially during a Load Balancing L4 and L3 session, where LinkProof does not always know where the traffic is coming from and where it is destined. The main goal of LinkProof is not only providing High Availability connectivity but also better utilization of existing WAN / Internet services and providing better Load Balancing of the traffic between them. LinkProof does differentiate between a regular Router and a Firewall in terms of the following: A Router is always considered an exit point to the network whilst a Firewall can be one (but does not have to be). Firewalls are considered Proxys for L7 traffic redirection whilst a Router not. For more information on the subject please refer to the LinkProof User Guide. The following sets of features were developed especially in order to support Load Balancing especially in complex network scenarios but not only. Load Balancing When supporting advanced LinkProof & Firewall configurations there are special considerations with regards to traffic flow. Figure 1 describes a network topology called a Firewall "Sandwich". In this topology the problem is the direction of traffic flow inbound and outbound as it is routed in and out by the LinkProof devices through the Firewalls. The technical issue is when a tunnel exists, having the return traffic use the same path of the original tunnel.
Page - 6- Branch Branch LAN Gateway 3 H.Q. Gateway 1 LinkProof Gateway 1 LinkProof Router LAN A LAN C LAN B Figure 1 - There are 2 possible options to describe in Figure1: 4. The network session starts from the H.Q to the branch. Traffic returning from the branch uses the same path. In case that a new traffic session originates from the branch to the H.Q, it must use the same server tunnel as the one used by the traffic from the H.Q to the branch 5. The network session starts from the branch to the H.Q. Traffic returning from the H.Q uses the same path.
Page - 7- In case that a new traffic session originates from the H.Q to the branch, it must use the same server tunnel as the one used by the traffic from the branch to the H.Q. Figure 2 describes the 2 alternative paths that the traffic can flow. Branch Branch LAN Gateway 3 H.Q. LinkProof Gateway 1 Gateway 1 LinkProof Path A Path B Router LAN A LAN C LAN B Figure 2 The Traffic flow (Branch to H.Q) is as follows: I) Branch LAN II) Gateway 3 III) 1 st LinkProof IV) Gateway 1 V) 2 nd LinkProof VI) Router LAN A
Page - 8- Return path should be exactly the opposite (VI to I). Since LinkProof is unable to determine which Gateway the tunnel needs to use (The tunnel is maintained via one Gateway only), then the traffic is routed via the wrong path and the connection is dropped by the other Gateway. In order to resolve the above issue a new dispatch method is available when configuring a Firewall Farm. This Dispatch method is called Multicast. Multicast Consider scenario A (described above) in Figure 2. A session is open from the Branch Office to the H.Q following the red path. When the Multicast Dispatch method is used, the return packet reaches the lower LinkProof device, and then sends a Multicast with the return packet to both Gateways. Whichever responds 1 st is the one with the already established session (red path), LinkProof forwards the traffic to that Gateway and the session is not broken. To Configure the Multicast Dispatch Method using WBM (When creating a new Firewall Farm) 1. Select LinkProof -> Farms -> FW Farms Table -> Create 2. From the Dispatch Method drop-down list select Multicast. 3. Click Set. To Configure the Multicast Dispatch Method using CLI (lp farms firewall -farms add <farm name> -dm multicast> command).
Page - 9- Load Balancing Clear Client Table Consider the scenario below in Figure 3 H.Q Network L3 Switch / Router LinkProof 1 LinkProof 2 L2 Switch 1 Gateway 1 L2 Switch 3 L2 Switch 2 Gateway 2 L2 Switch 4 LinkProof 3 LinkProof 4 L3 Switch / Router Branch A Branch B Figure 3
Page - 10- Scenario (1) In the event that switch No. 3 goes down, then LinkProof No.4 handles the session. If Switch No.3 comes up again, LinkProof No.3 responds to the traffic again and sends the traffic to both gateways ( No.1 and No.2) because multicast mode has been set. The LinkProof No.3 does not have a Client Table entry any more. LinkProof No.1 still sends traffic to No.1 and this in turn creates a persistency issue, because LinkProof No.3 and LinkProof No.1 have different entries in their client table. Scenario (2) Another problem arises was when both backup and regular servers (Firewalls) are configured. In case both servers are active, then traffic goes through the regular server. With the regular server is not in service, all its associated Client Table entries are deleted and traffic is sent through the backup server. Once the regular server is up, the old sessions that are already in the Client Table are sent through the backup server eventhough the regular is up. Only new sessions are sent through the regular server. Solution: Clear Client Table Scenario (1) A new flag is added to the farm that indicates when a client entry as part of a farm needs to be deleted when the server of that farm comes up again. This assures persistency is maintained. Scenario (2) To solve the second described scenario, an additional value has been added to the field which provides an option to delete the farm related client entries in the event that the first regular server is up. This assures that no session goes through the backup server if there is a regular server available. Each farm contains a new field called Client Table Clear Condition, which is explained in the following configurations: To Configure the ' LB Clear Client Table' Option using WBM Once a Firewall farm has been created 1) Select >LinkProof -> Farms -> FW Farms Table -> FW Farm Table Update. 2) From the Clear Client Table Condition drop-down list select one of the following parameters. None (default) Functionality is ignored (previous behavior continues) Any Server Up - Indicates when a server of a particular is up again. All client entries are deleted which Hare part of that farm.
Page - 11-1st Regular Server Up This value indicates when a regular server goes up and when it is the first regular server for that farm to go up. All the Client Table entries associated with that server selection from that farm are deleted. 3) Click Set. To Configure the ' LB Clear Client Table' Option using CLI 1) (lp farms firewall-farms set <Farm Name> -tc <1 (default), 2 or 3> command). 2) Press Enter. Note: The options above can also be set while creating the Firewall Server Farm. Load Balancing Client Table Overwrite This is another feature that helps deal with the same scenario as No.1 above: In the event that switch No. 3 goes down, then LinkProof No.4 handles the session. If Switch No.3 comes up again, LinkProof No.3 responds to the traffic again and sends the traffic to both gateways ( No.1 and No.2) because multicast mode has been set. The LinkProof No.3 does not have a Client Table entry any more. LinkProof No.1 still sends traffic to No.1 and this in turn creates a persistency issue, because LinkProof No.3 and LinkProof No.1 have different entries in their client table. In order to solve the described case, a new flag was added to the farm, which indicates whether to delete the client entries that relate to this farm in case a server of that farm just went up. Note: Since the 2 LinkProofs are not synchronized and won t recognize that the server is up/down at the same time, persistency issues can still remain. The following are such examples until overwritten by the Client Table Overwrite feature: 1. This persistency problem is not overcome until the Client Table entry is deleted. The server that was chosen when the packet arrived from a different server is not overwritten. (Firewall).
Page - 12-2. When a new server is from a different Farm of the original server then the server selection is not overridden. 3. The server selection is not overridden when IP translations (NAT) of any sort are involved. To Configure the LB Client Table Overwrite using WBM Once a Firewall farm has been created 1) Select LinkProof -> Global Configuration -> Client Table -> Server Selection Override. 2) From the Server Selection Override drop-down list select Disable or Enable. To Configure the LB Client Table Overwrite using CLI 1) (lp global client-table server-selection-override set <disable (default) or enable> command) 2) Press Enter.