appdirector solution rev 1.03 - radware

North America Radware Inc. 575 Corporate Dr. Suite 205Mahwah, NJ 07430 Tel 888 234 5763

International Radware Ltd. 22 Raoul Wallenberg St. Tel Aviv 69710, Israel Tel 972 3 766 8666

North America Radware Inc. 575 Corporate Dr. Suite 205Mahwah, NJ 07430 Tel 888 234 5763

International Radware Ltd. 22 Raoul Wallenberg St. Tel Aviv 69710, Israel Tel 972 3 766 8666

Technical Solution Guide

AppDirector

19 March 2007

Revision 1.03

Table of Contents Introduction ........................................................................................................................ 3 Step 1: Defining the Required Type of Solution ................................................................. 4 Step 2: Before Installation .................................................................................................. 6 Step 3: Pre-Installation Tasks ............................................................................................ 9 Step 4: Recommended Scenarios.................................................................................... 22

Scenario 1: AppDirector as a Router in the Datacenter................................................ 23 Scenario 2: AppDirector in One Leg Implementation (One Arm).................................. 30 Scenario 3: AppDirector in Local Triangulation Mode .................................................. 37 Scenario 4: AppDirector with Local and Remote Servers............................................. 45 Scenario 5: AppDirector with AppXcel.......................................................................... 53 Scenario 6: AppDirector with AppXcel – Backend SSL Enabled.................................. 69 Scenario 7: Global Traffic Management with DNS/HTTP Redirection.......................... 85 Scenario 8: AD as a L2 Bridge (VLAN) in the Datacenter .......................................... 110

Step #5: Management Settings...................................................................................... 118 Step #6: Configuring Redundancy in the AppDirector using VRRP............................... 120 Step #7: Advanced Content Switching – Layer 7 ........................................................... 129 Step #8: Client NAT Settings ......................................................................................... 132

Introduction

Introduction This Technical Solution Guide summarizes the official recommended scenarios for installing the AppDirector in your network in order to help you select the best installation scenario for your application requirements.

In this guide you will find the most commonly used AppDirector installation scenarios. According to your application type, you are directed towards the best scenario.

The scenarios include:

• Detailed descriptions of the advantages and limitations • Step-by-step procedures • Reference network diagrams Performing an installation in keeping with the recommended installation scenarios presented in this guide will ensure a fast and smooth installation process and easier troubleshooting in the future.

Note: Use of installation scenarios that are not covered in this guide can lead to unpredictable performance and functionality results.

Applicable Product Versions This Technical Solution Guide is applicable for the following product versions:

Product Hardware Platform Software Version

AppDirector AD1000/256MB RAM 1.00.01

AppXcel AppXcel 4000 1.00.01

APSolute Insite 2.02.03

Document Conventions This guide uses the following documentation conventions:

• Command paths in the GUI are presented as: File > Save As. • Screen displays may differ slightly from those included in this guide,

depending on the system you use. For example, Microsoft Windows screens are different from X-Windows screens.

The following icons are used throughout the document:

Note: Important information that requires additional attention.

To Statement: Detailed operating instructions that explain the step-by-step configuration process.

3

Step 1: Defining the Required Type of Solution

Important Note: Select from the following list of applications the scenario that best fits your requirements. The scenarios are described in detail in Step 4: Recommended Scenarios, page 22. In case more than one scenario is recommended, the scenario with the rating in red stars ( ) should be used.

• AFE (Application Front End) Services for CRM Applications A CRM application in your network requires traffic priority. You cannot let other services on the same AppDirector (AD) consume unlimited bandwidth and slow the CRM communication. Another important requirement for CRM is session persistency for its long sessions. This cannot be achieved with regular L3 session tracking (the Client Table) as the source IP addresses of the clients might be NATed by your internal firewall. The recommended solutions for AFE services for CRM applications are provided in Scenario 1 and Scenario 2.

• AFE Services for Web Applications Web applications are application front-end services. Most of these services are exposed to Internet users and thus need to be highly secured. Different users might need to access different services according to their language, location and type of service. The recommended solutions for AFE services for Web applications are provided in Scenario 1 and Scenario 2.

• AFE Services for Database Applications Database servers are necessary for the application to be available. Without them the application can be available but data cannot be provided to the users or collected from them. Proper application health monitoring configuration allows the application to go down at the time the DB server is not in service. The recommended solutions for database servers are provided in Scenario 1 and Scenario 2.

• AFE Services for Streaming Applications Streaming applications require narrow bandwidth for the request but very wide bandwidth for the server's response (the streaming data). In order to gain more bandwidth capabilities the AppDirector can be installed in a way that the response will pass directly from the servers to the access router bypassing AppDirector. Theoretically there is no bandwidth limitation for this kind of setup. The recommended solution for AFE services for streaming applications is provided in Scenario 3.

• AFE Services for Global Sites Global sites have local resources and remote resources acting together as one. Clients who access the service need to receive the content from the best available site, which depends on proximity information as well as load sharing decisions made by the AppDirector. The recommended solution for AFE services for global sites is provided in Scenario 4.

4 AppDirector Technical Solution Guide

Step 1: Defining the Required Type of Solution

• AFE Services with AppXcel AppXcel is Radware's application acceleration device. Combining AppXcel with AppDirector provide high availability and load sharing for the application servers together with the AppXcel's devices. Such a solution enables taking L7 decisions for HTTPS traffic as well. The recommended solutions for AFE services with AppXcel are provided in Scenario 5 and Scenario 6.

AppDirector Technical Solution Guide 5

Step 2: Before Installation Before installation, Radware recommends you take into consideration the following:

1. Physical Connectivity Concerns

• A Radware device acts as a switch. Crossed cables should be used between switches and straight cables should be used for connecting other network hosts. Make sure you use the right type of cable as stated. Some platforms support the Auto sensing feature (MDIX) and can operate with any type of cable, however this feature is disabled once you disable Auto negotiation.

• Only GBICs that have been tested and approved by Radware can be used. For an updated list, refer to: http://www.radware.com/content/support/faq/gigabitethernetandgibcsupport.asp.

• Auto negotiation is activated by default. In most cases, this is the preferred option. Verify that it is activated on the other side as well.

Note: Disabling Auto negotiation disables the cable type Auto sensing feature (MDIX) as well (available on AS1v2, AS2, AS3 and AS4).

• Optical cables are not provided by Radware and need to be purchased separately. Some devices use SC connectivity as well as LC. Make sure you have the appropriate cable.

• The copper cables that Radware provides are intended for management only and should not be used for other types of traffic. CAT5 certified copper cables must be used.

• When connecting to network switches and working with Radware's proprietary redundancy protocol, make sure you disable Spanning Tree or at least enable Port Fast on the relevant ports (on the switch). It is also possible to set the Spanning Tree to operate in fast learning mode on the relevant ports. Radware Application Switches do not support the Spanning Tree protocol.

2. IP Allocation Concerns

• Make sure you have the IP addresses allocated and defined in your network for the AppDirector's interfaces, new servers, NAT IP addresses (if activated on the AppDirector), DNS IP addresses (if activated on the AppDirector) and for the redundant AppDirector as well.

• Pay particular attention to the Local Triangulation implementation and VLANs (explained in this document) where the IP addresses of the servers should be public routable IP addresses.


http://www.radware.com/content/support/faq/gigabitethernetandgibcsupport.asp

http://www.radware.com/content/support/faq/gigabitethernetandgibcsupport.asp

Step 2: Before Installation

3. Management Concerns

• Install the Radware management software – APSolute Insite – on the management computer. There are two versions of this software. One is for the SQL database for use with Radware APSolute OS enhancement (and for DefensePro) and the other is for regular management purpose. The software can be downloaded from the Radware website: http://www.radware.com/content/support/software/config-configinsite-matrix/default.asp.

• Radware management uses SNMP communication running on UDP port 161. Make sure this communication port is not blocked by your firewall.

• Configuration upload/download action uses TFTP protocol. Ensure that TFTP is not blocked by your firewall and the management station is not NATed toward the Radware device. As TFTP traffic is initiated from the Radware device to the management station, a relevant firewall rule should be configured. UDP ports 162 and 69 are used for TFTP.

• Radware devices can also use HTTP, HTTPS, Telnet, and SSH for management. In case you choose to activate one of the above (see Step #5: Management Settings) verify that they are not blocked by your firewall. Traffic direction is from the management system to the Radware device.

• Radware devices have a console port for terminal communication, which uses an RS232 cable (provided by Radware). (See Scenario 3: AppDirector in Local Triangulation Mode.)

4. Latest Software Versions Radware classifies the software versions according to the following statuses:

Status Description

Shipping GA The default shipping version on new product orders.

GA (General Availability)

A general availability version that has completed full QA and beta processes and is considered a stable version.

LA (Limited Availability) A limited availability version that includes new features, has completed QA and beta processes, but currently has limited deployment in the field.


http://www.radware.com/content/support/software/config-configinsite-matrix/default.asp

http://www.radware.com/content/support/software/config-configinsite-matrix/default.asp

The software is also classified according to the following types:

Status Description

MY (Maintenance Version)

Radware is committed to providing 12 months notice before the end of maintenance for this software.

FV (Features Version) Radware is committed to providing three months advanced notice before the end of maintenance for this software. Issues in this version may be fixed in a later feature version.

CV (Customer Version) Specially developed software that has custom features or specific fixes for unique customer environments or applications. For ongoing maintenance, it is required to upgrade to the next version where the specific development is integrated.

Note: It is recommended that you verify that the software version of the Radware device you are about to install is the GA (General Availability) or Shipping GA version. An updated list of software versions and their status can be found at: http://www.radware.com/content/support/software/statusmatrix/default.asp?_v=statusmatrix.

5. Technical Support • Radware offers its Certainty Support Program, a suite of technical support

packages in various levels. You can view the complete set of programs at: . http://www.radware.com/content/support/default.asp

• Once you purchased the relevant Certainty Support package you can either contact Radware via email ([email protected]) or via the phone using our worldwide toll free numbers. An updated list is available at: http://www.radware.com/content/support/supportprogram/contact.asp.

• Additional information about the Radware Certainty Support program is available at: http://www.radware.com/content/document.asp?_v=about&document=2774


http://www.radware.com/content/support/software/statusmatrix/default.asp?_v=statusmatrix

http://www.radware.com/content/support/software/statusmatrix/default.asp?_v=statusmatrix

http://www.radware.com/content/support/default.asp

mailto:[email protected]

http://www.radware.com/content/support/supportprogram/contact.asp

http://www.radware.com/content/document.asp?_v=about&document=2774

Step 3: Pre-Installation Tasks

Step 3: Pre-Installation Tasks This section describes the step-by-step configuration that it is common to the various scenarios. You can adjust it to meet your specific needs by using your own network's IP addresses.

To configure the AppDirector:

1. Connect to the AppDirector using a serial cable. 2. In the COM3 Properties window, set your terminal emulation program

parameters according to the explanations provided:

Bits per second: 19200

Data bits: 8

Parity: None

Stop bits: 1

Flow control: None

3. Power on the AppDirector. A start up configuration screen appears.

4. Fill in the requested information (IP, Subnet Mask, Physical interface, Default Gateway) and click Enter for the rest of the settings. Once you have provided the requested information, the device is rebooted.

If the start up configuration screen does not appear, wait for the following prompt: AppDirector >


5. Log in with the default username (radware) and password (radware): AppDirector >login

User: radware

Password: *******

If you already set the IP, Subnet mask and Physical Interface in step 4, skip the next step.

6. Assign a management address to Interface #1: AppDirector# net ip-interface create 10.10.10.10 255.255.255.0 1

The result should be: Created successfully

IP Address 10.10.10.10 If Number (-i ): 1 Network Mask (-m ): 255.255.255.0 Fwd Broadcast (-f ): enable Broadcast Addr (-ba ): ONE FILL VlanTag (-v ): 0

7. Make sure that the management computer is on the same network segment as the AppDirector.

8. On your desktop, open APSolute Insite by clicking the shortcut icon. The Login window appears.

9. In the Login window, type in the username and the password (default is: radware/radware) and click Ok. The main window appears.



10. To connect to your AppDirector, in the main window, click Add > Add Radware Device > AppDirector. An AppDirector object appears in the main window.

11. To connect to the device, expand the icon view and double-click the AppDirector icon. The Connect to Device window appears.

12. In the Connect to Device window, type in the IP address (as configured in dialog wizard via the console) and the community. The default community of Radware products is public.

13. Click Ok and wait until you are connected to AppDirector. The AppDirector icon appears in the main window.


14. Once the device is connected, adjust the device global settings for your network needs. Double-click the AppDirector icon. The Setup window appears.

15. In the Setup window, select Global > Client Table Settings. The default value for the Client Table is 65536 entries.



16. To tune the Client Table, click Edit Settings. The Client Table Settings window appears.

This table stores an entry for each active TCP session. You need to calculate the number of required entries. The recommended setting for up to 5,000 concurrent users is 50,000 entries; this is based on the fact that each entry generates five simultaneous TCP sessions that last two minutes each.

Notes:

Each change in the device's tuning table requires a system reboot, however the best way to know how many sessions you have for your application is to tune it for a higher value (200,000) and check how many entries AppDirector stores during peak time. Once you have this information, you can better tune the device for your numbers and reboot it later during the next available maintenance window.

For a list of the tables that can be tuned and their maximum values, refer to the AppDirector Tuning Table paper.


http://www.radware.co.il/content/download.asp?document=6527

17. In the Client Table Settings window, click Ok.

18. Then click Ok again to reboot the device.

19. After the device reboots, close all open windows and double-click the AppDirector icon. The Setup window appears.

Note:

If you are configuring the AD according to Scenario 8: AD as a L2 Bridge (VLAN) in the Datacenter, skip steps 20 – 27 and follow step 28.

20. In the Setup window, click Add. The Interface window appears.

21. In the Interface window, configure the physical interfaces as required. Each interface must have at least an IP address, a Subnet Mask, and a physical port number. Then click Ok to return to the Setup window. Repeat this step for other IP addresses that should be configured in this scenario or according to your network needs.

22. In the Setup window, click Networking. The Networking dropdown list appears. From the Networking dropdown list, select Routing Table. The Routing Table window appears.



23. In the Routing Table window, click Add. The Edit Physical Route window appears.

24. In the Edit Physical Route window, type the routing configuration. For each entry, you should set at least the destination network, Network Mask, Net Hop (which should belong to one of the previously configured networks), and a physical port on the device where the traffic should be sent.

Note: Routing can be configured only on interfaces that are active (i.e., a network cable is connected and the state is Up).

25. Click Ok to return to the Routing Table window. Repeat this action for each routing entry that you need to add.

26. In addition, a default Gateway must be configured and must point to the access router or the firewall as the next hop router. In the Edit Physical Route window for the gateway, set the following parameters according to the explanations provided:

Destination IP Address 0.0.0.0


Subnet Mask 0.0.0.0

Next Hop The IP address of the access router or firewall

IF Number The relevant IF number.

27. Click Ok twice to close the windows.

Note: Follow steps 28-31 only if you are configuring the AD according to Scenario 8: AD as a L2 Bridge (VLAN) in the Datacenter.

28. In the Setup window, click Networking. The Networking dropdown list appears. From the Networking dropdown list, select VLAN.



The Virtual LAN window appears.

29. Highlight the row labeled 100001. This is a pre defined VLAN. Assign ports to this VLAN in the relevant section of this screen. The ports that should be assigned are the ports that should be member in this VLAN.

30. Click Update to confirm the changes and OK to close this window.

31. Repeat step 28-30 in case you need to configure more VLANs. If you wish to use other VLAN then the pre defined one click Add in the Virtual LAN window and create a new VLAN.



33. In the Interface window, configure the physical interfaces as requested. Each interface must have at least an IP address, a Subnet Mask, and a VLAN number as the 'If Num' (usually its 100001). Click Ok to return to the Set-Up window.

34. In the Setup window, click Networking. The Networking dropdown list appears. From the Networking dropdown list, select Routing Table. The Routing Table window appears.



35. In the Routing Table window, click Add. The Edit Physical Route window appears.

36. In the Edit Physical Route window, type the routing configuration. For each entry, you should set at least the destination network, Network Mask, Net Hop (which should belong to one of the previously configured networks), and a VLAN port on the device where the traffic should be sent.

Note: Routing can be configured only on interfaces that are active (a network cable is connected and the state is Up).

37. Click Ok to return to the Routing Table window. Repeat this action for each routing entry that you need to add.

38. In addition, a default Gateway must be configured and must point to the access router or the firewall as the next hop router. In the Edit Physical Route window for the gateway, set the following parameters according to the explanations provided:

DESTINATION IP ADDRESS

0.0.0.0

SUBNET MASK 0.0.0.0

NEXT HOP THE IP ADDRESS OF THE ACCESS ROUTER OR FIREWALL.

IF NUMBER THE RELEVANT VLAN NUMBER.

39. Click Ok twice to close the windows.


Traffic Settings Pane - General Explanation The farm settings are configured in the Traffic Settings pane of the farm window. The key traffic parameters are described in Table 1.

Table 1: Key Traffic Settings

Parameter Description

Dispatch Method The algorithm used to split traffic between servers, which can be cyclic, according to the amount of traffic or to the number of sessions. Other options include Hashing, the result of SNMP query to the servers (like CPU Usage), or the response time of the server to the AppDirector's health check traffic.

Session Mode The way AppDirector adds entries to its Client Table. • Regular: L3 load balancing (every source IP is

written once and is attached to one server). • Entry Per Session: L3 load balancing as in the

Regular mode, but entries are written in the Client Table according to source IP address and source port (L4). This is recommended in case of servers that exist in more than one farm and to avoid system confusion.

• Server per Session: L4 load balancing where every session with a different source IP and source port is written into the Client Table and attached to a different server. This mode is used mainly for L7 content switching according to information from the application (cookies, URLs, and so on).

• Remove on Session End: Equivalent to Entry per Session but adds the option to remove the entries from the Client Table not only after the Client Aging Time has expired but also when the session ends (a FIN or RST packet that belongs to that session arrives from either the client or the server). For additional information on the Session mode, refer to the AppDirector User Guide.

• Remove Entry in Select Server: Equivalent to Server per Session but adds the option to remove the entries from the Client Table not only after the Client Aging Time expired but also when the session ends (a FIN or RST packet that belongs to that session arrives from either the client or the server). For additional information on the Session mode, refer to the AppDirector User Guide.


http://www.radware.com/content/support/manual/Default.asp



Parameter Description

Client Aging Time This is the period AppDirector keeps an entry of a session in the Client Table when there is no activity. AppDirector resets this timer each time there is TCP activity on the session. The default value is 60 seconds; however, Radware guidelines for the best tuning value are to determine your application timeout and add a minute to that value. This way persistency is maintained for your application's session. The value should be written in seconds, not minutes.

Note: Additional settings can be tuned In the Traffic Settings pane. Nonetheless, it is recommended that you maintain the default settings unless otherwise required, for example, when enabling NAT, Installing a remote server on a global AppDirector, and so on.


Step 4: Recommended Scenarios This section describes the most commonly used scenarios for installing the AppDirector in your network, including the step-by-step procedures for their implementation.

The recommended scenarios include:

• Scenario 1: AppDirector as a Router in the Datacenter, page 23 • Scenario 2: AppDirector in One Leg Implementation (One Arm), page 30 • Scenario 3: AppDirector in Local Triangulation Mode, page 37 • Scenario 4: AppDirector with Local and Remote Servers, page 45 • Scenario 5: AppDirector with AppXcel, page 53 • Scenario 6: AppDirector with AppXcel – Backend SSL Enabled, page 69 • Scenario 7: Global Traffic Management with DNS/HTTP Redirection,

page 85 Performing an installation in keeping with the recommended installation scenarios will ensure a fast and smooth installation process and easier troubleshooting in the future.

Important Note: Refer to Step 1 for guidelines on selecting the scenario that best fits your requirements, according to your application type In cases where more than one scenario is recommended, the scenario rating accompanied by red stars ( ) should be used.


Step 4: Recommended Scenarios

Scenario 1: AppDirector as a Router in the Datacenter

Scenario Description This is one of the most commonly used scenarios for installing AppDirector. All traffic to the servers and back passes through AppDirector, therefore traffic load balancing and high availability traffic shaping (QOS) and security policy enforcement (IPS) can be applied.

In this scenario, the external interface of AppDirector has a public IP or one that is NATed by the Firewall/Router on top of it and the internal interface has an internal IP from the same segment as the servers’ segment. This way AppDirector acts as a router between the servers and the external segment. Traffic that is not destined to the AppDirector VIPs is routed towards its destination according to the Routing Table information.

This scenario can be used for L3/L4 content switching as well as L7 content switching. This scenario should not be used for servers that work with loopback adapters that reply directly to the clients.

Advantages The advantages of this scenario include the following:

• Simple IP management. Internal segment does not use public IPs. No need for coordination with the ISP, you can add as many servers as you want with no IP considerations.

• Security is enhanced as the servers are located in a different IP segment protected by the AppDirector.

• QOS is available for AppDirector based on application data (like HTTP cookies).

Limitations The limitations of this scenario include the following:

• Changes in the physical network. Installing AppDirector in such a scenario requires cabling changes and routing changes.

• Direct access to the servers and from the servers is done via AppDirector. This should be included in the overall traffic calculations that AppDirector should process (for example, database synchronization, software auto updates, and so on).


Suggested Physical Implementation Figure 1 illustrates a suggested physical implementation of the AppDirector as a Router.

APSolute Application Delivery AppDirector

G1 G2 G3 G4 G5

F9 F10 F11 F12F1 F2 F3 F4

F13 F14 F15 F16F5 F6 F7 F8


G1 G2 G3 G4 G5

F9 F10 F11 F12F1 F2 F3 F4

F13 F14 F15 F16F5 F6 F7 F8

Figure 1: AppDirector as a Router in the Datacenter

Step-by-Step Configuration Before you begin this configuration section, refer to Step 3: Pre-Installation Tasks.

After completing the pre-installation procedure, you are ready to configure the server farms.

To configure the server farms:

1. Right-click the AppDirector icon and select APSolute OS >Traffic Redirection. The Traffic Redirection window appears.



2. In the Traffic Redirection window, select Farm > Add. The Farm window appears.

3. In the Farm window, type the farm name in the Farm Name text box.

Note:

If the name contains more than one word, avoid spaces by adding a dash "-" between the words.

4. Next, configure your servers and associate them with the farm. In the Farm window, click Add. The Farm Servers window appears.


5. In the Farm Servers window, type the server name in the Server Name text box.

Note:


6. In the Server Address text box, type the server's IP address.

Note:

The servers should be located in the AppDirector's local segment. If not, you need to configure a relevant entry under the Routing Table. Other parameters should retain their default value. Click the Help button or refer to the AppDirector User Guide for a detailed explanation about the use of these settings.

7. Click Ok to confirm and return to the Traffic Redirection window. Repeat the above steps for the additional servers as required.





8. In the Farm window, click Traffic Settings. The Traffic Settings pane appears.

9. In the Traffic Settings pane, set the key traffic settings according to the explanations provided in Table 1, page 20.

10. Click Connectivity Check. The Connectivity Check pane appears.

The Connectivity Check pane allows you to configure simple connectivity checks for the servers. The purpose of the connectivity checks is to let AppDirector know the state of the servers (active or down). Connectivity checks can include;


Ping, TCP port (three-way handshake attempt), UDP port or HTTP page request.

Note: It is possible to disable the checks. To disable the checks, in the Connectivity Check pane, select No Checks from the Connectivity Method dropdown list. Disabling the checks can be used in order to perform more complex and deep checks in the Health Monitoring module.

11. Click Ok to close the Farm window and return to the Traffic Redirection window. At this point, the farms, servers and their connectivity checks are configured. The next step is to configure the policies that need to intercept the traffic coming to AppDirector and redirect it to the relevant farms.

12. In the Traffic Redirection window, click L4 Policies. The L4 Policies pane appears.

13. In the L4 Policies pane, click Add. The L4 Policies window appears.

14. In the L4 Policies window, in the VIP Address text box, type the VIP address that AppDirector will listen on. All traffic coming to this VIP will be classified according to the L4 Policy that you set now.

15. Click Add to configure the policies. The Add L4 Policy window appears:



For this example (HTTP servers), the L4 Protocol should be TCP, the Layer 4 Port should be 80, and the Farm Name should indicate the farm that was configured earlier. The policy name is a free text field that describes the policy's role. Other settings should not be changed. For more information about the other settings, refer to the AppDirector User Guide.

16. Click Ok to confirm and return to the L4 Policies window.

17. In case you have other farms and services, configure the VIPs and policies for them in this window as well.

18. Upon completion, click Ok twice to close the windows and return to the APSolute Insite main windows.

19. To configure the device management settings, refer to Step #5: Management Settings, page 119.

20. To complete the configuration of this scenario, refer to Step #6: Configuring Redundancy in the AppDirector using VRRP, page 120.

21. To configure advanced Layer 7 parameters, refer to Step #7: Advanced Content Switching – Layer 7, page 129

22. To configure the NAT parameters, refer to Step #8: Client NAT Settings, page 132



Scenario 2: AppDirector in One Leg Implementation (One Arm)

Scenario Description This scenario is recommended when minimum changes in the network are a mandatory condition. AppDirector is plugged into the backbone switch with one physical interface. The main changes are L3 routing changes that take place on the servers themselves.

AppDirector, the servers and the gateway (Router/Firewall) can be located on the same L2 segment. In case this is not possible, AppDirector can have two IP addresses configured on the same physical interface: a router between the external network (the access router or the Firewall segment) and the internal network (the servers segment). In case the servers are located on another segment, their default gateway should be AppDirector so that the response traffic passes through AppDirector and is NATed to the VIP.

In case the servers are on the same network segment as the access router or the Firewall and their default gateway cannot be changed, AppDirector should NAT the sessions going to the servers in order to force the response to pass via AppDirector and not be sent directly to the clients. This feature is known as Client NAT.

Advantages The advantages of this scenario include:

• The changes in the network are minor. • It is possible to perform fast fallback with no physical changes in the network. • Management access to the servers is easy as they are directly accessible. The

AppDirector is not required for this task.

Limitations The limitations of this scenario include:

• Routing changes are required on the servers, however the default gateway is not the network's gateway but AppDirector. It is common to forget this fact when performing maintenance tasks on the servers.

• In case one segment is used (the same segment for the servers and the access router/Firewall), the servers are not hidden with an internal IP range behind the AppDirector as in the routing scenario. This might be considered a security threat.



Suggested Physical Implementation Figure 2 illustrates a suggested physical implementation of the AppDirector in One Leg implementation in this scenario.


G1 G2 G3 G4 G5

F9 F10 F11 F12F1 F2 F3 F4

F13 F14 F15 F16F5 F6 F7 F8


G1 G2 G3 G4 G5

F9 F10 F11 F12F1 F2 F3 F4

F13 F14 F15 F16F5 F6 F7 F8

Figure 2: AppDirector in One Leg Implementation






2. In the Traffic Redirection window, select Farms > Add. The Farm window appears.



3. In the Farm window, enter the farm name.

Note:




Note:



Note:

The servers should be located in the AppDirector's local segment. If not, you will have to configure a relevant entry under the Routing Table. Other settings should not be changed. Click the Help button or refer to the AppDirector User Guide for a detailed explanation about these settings.

7. Click Ok to confirm and return to the Traffic Redirection window. Repeat the above steps for the other servers you want to add.






10. In the Farm window, select Connectivity Check. The Connectivity Check pane appears.

The Connectivity Check pane allows you to configure simple connectivity checks for the servers. The purpose of the connectivity checks is to let AppDirector know the state of the servers (active or down). Connectivity checks can include a



Ping, TCP port (three-way handshake attempt), UDP port or HTTP page request.



12. In the Traffic Redirection window, select L4 Policies. The L4 Policies pane appears.

In the L4 Policies window, you need to set the VIP address that AppDirector will listen on. All traffic coming to this VIP will be classified according to the L4 Policy that you set.

13. Click Add to configure the policies. The Add L4 Policy window appears.




15. In case you have other farms and services, configure the VIPs and policies for them in the L4 Policies window

16. Upon completion, click Ok twice to close the windows and return to the APSolute Insite main window.



19. To configure advanced Layer 7 parameters, refer to Step #7: Advanced Content Switching – Layer 7, page 129





Scenario 3: AppDirector in Local Triangulation Mode

Scenario Description This scenario is recommended for streaming applications and when minimum changes in the network are a mandatory condition. AppDirector will be connected via one physical interface to the backbone switch, and the main changes, which are L3 routing changes, will be implemented on the servers themselves.

Traffic that reaches AppDirector's VIP is forwarded to the selected server where the only change in the packet is the destination MAC. The server responds directly to the client via the gateway without passing through AppDirector. The servers should have a loopback interface installed and be configured with AppDirector's VIP.


• The changes in the network are minor. • The effective throughput that can be gained by this architecture is higher

than the first two scenarios. As the traffic from the servers to the clients (the server's response) is routed directly to the gateway, the throughput is the network's throughput. This is commonly used for streaming services where the client's request is small but the server's response is highly bandwidth consumption.


• No L7 content switching is possible due to the fact that the servers’ response to the clients does not pass through the AppDirector. This prevents AppDirector terminating the TCP session between the client and the server that is required for the L7 inspection.

• No QOS or application security is possible for the outbound traffic due to the fact that the servers’ response to the clients does not pass through AppDirector.

• The servers must be configured on the same broadcast domain (L2 subnet) of AppDirector.

• Servers cannot be members of two farms at the same time.


Suggested Physical Implementation Figure 3 illustrates a suggested physical implementation of the AppDirector in Local Triangulation mode.


G1 G2 G3 G4 G5

F9 F10 F11 F12F1 F2 F3 F4

F13 F14 F15 F16F5 F6 F7 F8


G1 G2 G3 G4 G5

F9 F10 F11 F12F1 F2 F3 F4

F13 F14 F15 F16F5 F6 F7 F8

Figure 3: AppDirector in Local Triangulation Mode







2. In the Traffic Redirection window, click Add. The Farm window appears.



Note:




Note:



Notes:

The servers should be located in the AppDirector's local segment. If not, you will have to configure a relevant entry under the Routing Table.

Server type should be set to: "local Triangulation". Other settings should not be changed. Click the Help button or refer to the AppDirector User Guide for a detailed explanation of these settings.

Each physical server should have a Loopback adaptor installed. For assistance with such an installation, refer to the AppDirector User Guide.

7. Click Ok to confirm and return to the Traffic Redirection window. Repeat the above steps for the other servers you want to add.







Note: Additional settings can be tuned In the Traffic Settings pane. Nonetheless, it is recommended that you maintain the default settings unless otherwise required, for example, when enabling NAT, Installing a remote server on an AppDirector Global, and so on. Before enabling any of the advanced features, make certain they are applicable in such a Local Triangulation scenario.



The Connectivity Check pane allows you to configure simple connectivity checks for the servers. The purpose of the connectivity checks is to let AppDirector know the state of the servers (active or down). Connectivity checks can include; Ping, TCP port (three-way handshake attempt), UDP port or HTTP page request.


11. Click Ok to close the Farm window and return to the Traffic Redirection window. At this point the farms, servers and their connectivity checks are configured. The next step is to configure the policies that need to intercept the traffic coming to AppDirector and redirect it to the relevant farms.



12. In the Traffic Redirection window, click L4 Policies > Add. The L4 Policies window appears.

In the L4 Policies window, you need to enter the VIP address that AppDirector will listen on. All traffic coming to this VIP will be classified according to the L4 Policy that you set.

13. In the L4 Policies window, click Add to configure the policies. The Add L4 Policy window appears.

For this example (HTTP servers), the L4 Protocol should be TCP, the Layer 4 Port should be 80, and the Farm Name should indicate the farm that was configured earlier. The policy name is a free text field that describes the policy's


role. Other settings should not be changed. For more information about the other settings, refer to the AppDirector User Guide.

14. Click Ok to confirm and to return to the L4 Policies window. In case you have other farms and services, configure the VIPs and policies for them in the L4 Policies window. When finished, click Ok twice to close the windows and return to APSolute Insite main window.






Scenario 4: AppDirector with Local and Remote Servers

Scenario Description This scenario can be used when part of the application resources are located remotely at another data center where only L3 TCP connection is available (ISP Internet link or leased line for example). This kind of architecture allows you to better utilize local and remote resources while services to the users are provided transparently.


• AppDirector can share the load among servers taking into consideration the traffic load on each site.

• AppDirector can utilize the local datacenter only and use the remote data enter only as a backup in case all local resources are unavailable.

• After initial redirection, the connection between clients and remote servers is established directly. AppDirector is not in between therefore the sessions are not subjected to multiple network hops.


• Partial QoS or application security is possible due to the fact that sessions that are redirected to remote servers do not pass through AppDirector.

• As redirection is done via HTTP code (HTTP 302) or via DNS service, an application that does not use HTTP or DNS cannot be configured with global servers (unless you use the Global Triangulation architecture mentioned in the AppDirector User Guide).

Important Note: This scenario can be configured only when using the AppDirector Global operation license.



Suggested Physical Implementation Figure 4 illustrates a suggested physical implementation of the AppDirector with local and remote servers.


G1 G2 G3 G4 G5

F9 F10 F11 F12F1 F2 F3 F4

F13 F14 F15 F16F5 F6 F7 F8


G1 G2 G3 G4 G5

F9 F10 F11 F12F1 F2 F3 F4

F13 F14 F15 F16F5 F6 F7 F8

Figure 4: AppDirector with Local and Remote Servers



Step-by-Step Configuration Description Before you begin this configuration section, refer to Step 3: Pre-Installation Tasks, page 9.




2. In the Traffic Redirection window, click Farms > Add. The Farm window appears.


Note:






Note:


6. In the Server Address text box, type the server's IP.

Notes:

In case this is the remote server, change the server Type to: "Remote Server".

The local servers should be located in the AppDirector's local segment. If not, you will have to configure a relevant entry under the Routing Table.

Other settings should not be changed. Click the Help button or refer to the AppDirector User Guide for a detailed explanation of these settings.

7. Click Ok to confirm and return to the Traffic Redirection window. Repeat the above steps for any other servers you want to add.



Note: Additional settings can be tuned In the Traffic Settings pane. Nonetheless, it is recommended that you maintain the default settings unless otherwise required, for example, when enabling NAT, Installing a remote server on an AppDirector Global, and so on. Before enabling any of the advanced features, make certain they are applicable in such a Local Triangulation scenario.






11. Click Ok to close the Farm window and return to the Traffic Redirection window. At this point the farms, servers and their connectivity checks are configured. The next step is to configure the policies that need to intercept the traffic coming to AppDirector and redirect it to the relevant farms.

12. Click L4 Policies > Add. The L4 Policies window appears.



13. In the L4 Policies window, in the VIP Address text box, type the VIP address that AppDirector will listen on. All traffic coming to this VIP will be classified according to the L4 Policy that you set.

14. Click Add to configure the policies. The Add L4 Policy window appears.

For this example (HTTP servers), the L4 Protocol should be TCP, Layer 4 Port should be 80, and the Farm Name should indicate the farm that was configured earlier. The policy name is a free text field that describes the policy's role. Other settings should not be changed. For more information about the other settings, refer to the AppDirector User Guide.

15. Click Ok to confirm and to return to the L4 Policies window.



16. In the L4 Policies window, configure the VIPs and policies for any other farms and services as required.

17. When complete, click Ok twice to return to APSolute Insite main window.






Scenario 5: AppDirector with AppXcel

Scenario Description SSL is a heavy task for the application servers. The amount of clients they can serve with SSL is much lower than the amount of clients they can serve without SSL.

This scenario should be used when you plan to integrate Radware's AppXcel (AX) with AppDirector or into an existing AppDirector setup.

AppXcel is an application acceleration device that enhances the performance of HTTP, HTTPS and other services that run over SSL. Using it as an integrated appliance in the AppDirector setup provides high availability and load sharing of AppXcel's resources.

Using AppXcel for SSL Offloading Traffic that reaches the SSL VIP is not directed to the SSL server but is redirected to the AppXcel farm that contains AppXcel devices. An SSL session is established between the AppXcel and the client via AppDirector. SSL is decrypted by the AppXcel and a clear data session is established between the AppXcel and the application servers' farm through AppDirector. In this manner, the clients use SSL to communicate with the datacenter while, in order to enhance performance, the application servers use clear text and do not use SSL.

Using AppXcel for HTTP Compression Traffic that reaches the servers VIP is not directed to the servers but instead, is redirected to the AppXcel farm. After establishing a TCP session between the client and the AppXcel, the AppXcel initiates a TCP session with the application server through AppDirector. The external session (Client <-> AX) uses content compression algorithms (like GZIP or Deflate) to make data transfer more efficient thus reducing the amount of data that needs to be transferred.


• High availability is gained not only for the application servers but to the AppXcel devices as well.

• L7 content switching decisions can be made for HTTPS traffic after it is decrypted by the AppXcel.

• Application security policies can be enforced on the traffic that was encrypted by the AppXcel, so that SSL attacks can be detected.


Suggested Physical Implementation Figure 5 illustrates a suggested physical implementation of the AppDirector with AppXcel.


G1 G2 G3 G4 G5

F9 F10 F11 F12F1 F2 F3 F4

F13 F14 F15 F16F5 F6 F7 F8


G1 G2 G3 G4 G5

F9 F10 F11 F12F1 F2 F3 F4

F13 F14 F15 F16F5 F6 F7 F8

PWR OK SYS OK SSL RESET

ACT

OK

AppXcelAPSolute Application Delivery

SERIAL PORT

FE

LNK/ACT

LAN 2

BY PASSBYPASS

FE

LNK/ACT

LAN 1


ACT

OK


SERIAL PORT

FE

LNK/ACT

LAN 2

BY PASSBYPASS

FE

LNK/ACT

LAN 1

Figure 5: AppDirector with AppXcel



Step-by-Step Configuration Configuration according to this scenario entails configuration of both the AppDirector and AppXcel, as described in the following sections:

• Configuring AppDirector, below • Configuring AppXcel, page 62

Configuring AppDirector Before you begin this configuration section, refer to Step 3: Pre-Installation Tasks, page 9.




2. In the Traffic Redirection window, click Add. The Farm window appears.

3. In the Farm window, enter the farm name in the Farm Name text box.

Note:






Note:



Notes:



7. Click Ok and return to the Traffic Redirection window. Repeat the above steps for any other servers you want to add.





10. In the Farm window, click Connectivity Check. The Connectivity Check pane appears.

The Connectivity Check pane allows you to configure simple connectivity checks for the servers.

The purpose of the connectivity checks is to let AppDirector know the state of the servers (active or down). Connectivity checks can include a Ping, TCP port (three-way handshake attempt), UDP port or HTTP page request.

Note: It is possible to disable the checks. To disable the checks, in the Connectivity Check pane, select No Checks from the Connectivity Method dropdown menu. Disabling the checks can be used in order to perform more complex and deep checks in the Health Monitoring module.

11. Click Ok to close the Farm window to return to the Traffic Redirection window.

12. Click Ok to confirm and return to the Traffic Redirection window. Repeat Steps 2-6 and set another farm for AppXcel devices.



Note: If the application server farm is called "Application1", it is recommended to call this farm "Application1_SSL" for future troubleshooting. Both farms (HTTP and HTTPS) should be set for Entry per Session for the Session mode and have the Application Server Support set to Enable in the SSL Farm.

The following window shows the "Application1_SSL" farm settings in the Farm window:

13. Click Ok to confirm and return to the Traffic Redirection window. The next step is to configure a L4 Policy to be used to intercept traffic coming to AppDirector's VIP and direct it to the right farm (either an HTTP or HTTPS farm).


14. In the Traffic Redirection window, click on L4 Policies. The L4 Policies pane appears.

15. Click Add. The L4 Policies window appears.

16. In the L4 Policies window, in the VIP address text box, type the Public IP address you want to assign to the L4 Policy. This IP address is the destination IP address of the traffic that reaches AppDirector and should be intercepted (the application's VIP address).



17. Click Add to create the interception policy. The Add L4 Policy window appears.

18. In the Add L4 Policy window, configure the traffic flow of each Layer 4 protocol. HTTP should be linked to the Application1 farm and HTTPS to the Application1_SSL farm. You need to enter the parameters twice (once each L4 protocol).

19. Click Ok to accept your preferences. The L4 Policies pane displays the complete policy content: 100.100.100.40 is the L4 Policy VIP, while the farms that can be selected according to the L4 protocol are the HTTP (Application1 for this example) and the HTTPS (Application1_SSL) farms:


20. To configure the device management settings, refer to Step #5: Management Settings, page 119



Configuring AppXcel The process of setting up AppXcel to work according to this scenario is performed in several stages:

• Configuring AppXcel Networking, below • Configuring the AppXcel Security Key and Certificate, page 64 • Configuring the Tunnel, page 66 • Backing Up the AppXcel Configuration, page 68

Configuring AppXcel Networking In order to use AppXcel in this scenario, you need to first configure its networking settings.

To configure AppXcel:

1. Connect to AppXcel using a serial cable.

2. In the COM Properties window, set your terminal emulation program parameters according to the explanations provided:


Data bits: 8

Parity: None

Stop bits: 1

Flow control: None



3. Boot the AppXcel and wait for the login prompt: Radware AppXcel Version 1.00.01

AppXcel login:

4. Log in with the default username and password (radware/radware).

5. Assign a management address to LAN1: net management-ip create 10.10.11.20 255.255.255.0 -inf 1

6. Make certain the management computer is on the same network segment as the AppXcel.

7. Using APSolute Insite, add an AppXcel device (10.10.11.20). The default username and password are: radware/radware. The AppXcel appears in the main window.


8. To configure the networking, double-click the AppXcel icon and select Routing Table. The Routing window appears.

9. In the Routing window, click Add and create the default gateway. (The default gateway should be AppXcel's interface on that network segment, in this example it is 10.10.11.10). The following example of the Edit Route window shows the correct parameter settings:

10. Click Ok to close the Edit Route window.

11. The click Ok to close the Routing Table window and the Setup window.

Configuring the AppXcel Security Key and Certificate You now need to configure the Security Key and Certificate. The following options are available:



• Import a PKCS12 format package that contains both Key and Certificate. This is the file format that is generated when exporting the Key and Certificate from an IIS Server.

• Import each separately. This option is used when storing both on a backup media. You can Import using copy and paste or using a PEM/DER format.

• The key can be created on the AppXcel and a certificate request can be created on top of it. This request should be exported and sent to a Certificate Authority (CA) company. After signing it the certificate should be uploaded to the AppXcel.

The following example describes the second option – importing the security key and certificate separately. Make sure you have the two files ready (key + certificate). For more on implementing the other options, refer to the AppXcel User Guide.

To import the security key and certificate:

1. Right-click the AppXcel icon and select Keys. The Keys window appears.

2. In the Keys window, click Import Key. The Import Key window appears.

3. In the Import Key window, configure the key parameters as follows:

4. In the New Key ID text box, type a key ID (1 for example).

5. In the Key Password text box, type the key password (to be used when exporting the key for backup purposes). Then type it again in the Verify Key Password text box for confirmation purposes.

6. Select the import method you want to use, File or Text. Then paste your key in the text box to replace the "Erase this line…" text or browse your disk to locate the key file. The string that should be pasted in this screen should begin with: " -----BEGIN RSA PRIVATE KEY-----………." and end with: "-----END RSA PRIVATE KEY-----".



7. Click Ok to close this window. The key you just imported is listed in the Keys window.

8. In the Keys window, select the key line and click Edit. 9. Click the Certificate button and select Import. Follow the procedure for

importing a key. Enter the relevant parameters in the New Certificate window as shown below:

10. Click Ok repeatedly to close the windows. The Key and the Certificate are configured in your AppXcel.

Configuring the Tunnel The next step is to configure the tunnel. A tunnel is the main application of the AppXcel and is represented by an IP address that should be accessible by the AppXcel. All traffic destined to the tunnel's IP address will get decryption services. It is possible to configure multiple tunnels in one AppXcel.



To configure the tunnel:

1. Double-click the AppXcel icon and click Add. The Edit Tunnel window appears.

2. In the Edit Tunnel window, set the following parameters according to the explanations provided:

Tunnel Serial ID: 1

Interface: LAN 1 (The default value should be left).

IP Address: The IP of the tunnel (should be the same IP configured in the AppXcel as the server IP in the "Application1_SSL" farm).

Mask: The Subnet mask of the tunnel's network segment.

Port: The application port of the traffic that should be handled by the tunnel. Normally, it should be 443 for SSL decryption.

Server IP: The IP address of the L4 Policy in the AppDirector.


Server Port: The application port of the backend servers' farm or L4 Policy that should receive the traffic. Normally port 80 is used.

Attached Key ID: The key ID.

Service Type: The type of application that is terminated. This is in order to provide special support for various applications such as HTTP (compression, caching, headers rewrite), FTP (FTPS support), or SMTP (SMTPS support). Other will not modify any of the application data content except terminating the SSL.

3. In the Edit Tunnel window, click Advanced to configure additional tunnel properties and select Tunnel Transparency. This forces AppXcel to establish a connection to the backend servers using the original clients' source IP address.

4. Click Ok to confirm your preferences and once again to close the main AppXcel window.

Backing Up the AppXcel Configuration The final task is to back up the AppXcel's configuration file.

To back up the configuration:

1. To save a copy of the configuration, select Device > Configuration File. The Download pane appears.

2. In the Download pane, select the AppXcel device, provide a path on your local hard disk to save the file, and type the configuration export password (default: radware).

3. Click Apply to start downloading and saving the configuration file. AppXcel is ready for operation.



Scenario 6: AppDirector with AppXcel – Backend SSL Enabled

Scenario Description This scenario should be used when you plan to integrate Radware's AppXcel (AX) with AppDirector or into an existing AppDirector setup.

SSL is a heavy task for application servers. The number of clients they can serve with SSL is much lower than the number of clients they can serve without SSL. AppXcel is an application acceleration device that enhances the performance of HTTP, HTTPS and other services that run over SSL. Using it as an integrated appliance in the AppDirector setup enables high availability and load sharing of AppXcel's resources.

Scenario 6 is different from Scenario 5, as in this case the servers are working in SSL mode and AppXcel encrypts the traffic sent. Scenario 6 is used mostly in banking environments where the laws forces traffic to be fully encrypted until it reaches the servers. This scenario also adds the capability to perform Layer 7 switching and maintain session persistency according to application data (Cookies, URLs, HTTP Headers, and so on.).

Using AppXcel for SSL Offloading: Traffic that reaches the Application's VIP in AppDirector is not directed to the SSL servers, it redirected to the AppXcel farm. This farm contains AppXcel devices. An SSL session is established between AppXcel and the client via AppDirector. SSL is decrypted by AppXcel and a new SSL session - with lighter and less secure ciphers - is established between AppXcel and the backend servers via AppDirector. This way, the clients talk SSL with the data center, while, in order to enhance performance, the application servers use lighter ciphers. The traffic is encrypted while performance is boosted.


• High availability is gained not only for the application servers but for AppXcel devices as well.

• L7 content switching decisions can be made for HTTPS traffic after it is decrypted by AppXcel.

• Application security policies can be enforced on the traffic that was encrypted by AppXcel, so that SSL attacks can be detected.


Suggested Physical Implementation Figure 6 illustrates a suggested physical implementation of the AppDirector with AppXcel – with Backend SSL enabled.


G1 G2 G3 G4 G5

F9 F10 F11 F12F1 F2 F3 F4

F13 F14 F15 F16F5 F6 F7 F8


G1 G2 G3 G4 G5

F9 F10 F11 F12F1 F2 F3 F4

F13 F14 F15 F16F5 F6 F7 F8


ACT

OK


SERIAL PORT

FE

LNK/ACT

LAN 2

BY PASSBYPASS

FE

LNK/ACT

LAN 1


ACT

OK

AppXcelAPSolute Application DeliverySERIAL PORT

FE

LNK/ACT

LAN 2

BY PASSBYPASS

FE

LNK/ACT

LAN 1

Figure 6: AppDirector with AppXcel – with Backend SSL Enabled

Step-by-Step Configuration This example demonstrates how SSL can be maintained all the way from client to server, while AppDirector can inspect the Layer 7 headers of the HTTP protocol. This is achieved through the AppXcel's ability to terminate the SSL, send the decrypted headers to AppDirector, and encrypt the traffic again with lower and more efficient ciphers.

Configuration according to this scenario entails configuration of both the AppDirector and AppXcel, as described in the following sections:

• Configuring AppDirector • Configuring AppXcel, page 78



Configuring AppDirector Before you begin this configuration section, refer to Step 3: Pre-Installation Tasks, page 9.


1. AppDirector is ready to configure the servers' farms. Right-click the AppDirector icon and select APSolute OS > Traffic Redirection. The Traffic Redirection window appears.

2. In the Traffic Redirection window, click Farms > Add. The Farm window appears.


3. In the Farm window, enter the farm name in the Farm Name text box.

Note:




Note:



Notes:



7. In the Farm Servers window, click Ok to confirm and return to the Farm window. Repeat the above steps for any other servers you want to add.






10. In the Farm window, click Connectivity Check. The Connectivity Check pane appears.

The Connectivity Check pane allows you to configure simple connectivity checks for the servers. The purpose of the connectivity checks is to let AppDirector know the state of the servers (active or down). Connectivity checks can include a Ping, TCP port (three-way handshake attempt), UDP port or HTTP page request.



11. Click Ok to accept your preferences and return to the Traffic Redirection window.

12. Repeat Steps 2-7 and set the following farms: Japanese-Farm, SSL-Farm and add the relevant servers to those farms. After repeating these steps for each of the farms, you should have the following configured:

i. English-Farm (English-1 server configured for this farm) ii. Japanese-Farm (Japanese-1 server configured for this farm) iii. SSL-Farm (AX-1 server configured for this farm)

13. Click Ok to confirm and return to the Traffic Redirection window. The next step is to configure the L7 parameters to let the AppXcel distinguish between English language users and Japanese language users.

14. In the Traffic Redirection window, click L4 Policies >L7 Policies. The L7 Policies window appears.

15. In the L7 Policies window, click L7 Method to configure a method for each language.

16. Click Add to create a method. The Edit Layer 7 Method window appears.

17. In the Edit Layer 7 Method window, set the following parameters for the first

method (detecting English language users) according to the explanations provided:

Method Name: English

Method Type: Header Field

Header Field: Accept-Language

Token: en

18. Click Ok to accept your preferences and repeat the above step for Japanese language users. For Japanese, the value of Token should be 'ja'.

19. Click Ok to confirm the Japanese method and again in the Layer 7 Method window. The next step is to configure a Layer 7 policy.

20. In the Layer 7 Policies window, click Add Policy.



21. Type a name, an Index, and select English as the first method.

22. Click Add and repeat this step for another policy with the same name but with a different index number (English can be 1 and Japanese can be 2). The following is an example of such a window (for a policy that identifies English users):

23. Click Ok to accept your preferences and return to the Traffic Redirection window. The next step is to configure an L4 Policy to be used to intercept traffic coming to AppDirector's VIP and direct it to the right farm (either HTTP or HTTPS farm).

Now you need to configure the policy for the SSL traffic from the clients and the interception policies for both HTTPS traffic from the users to the AppXcel and HTTPS traffic from the AppXcel to the backend servers.


24. In the Traffic Redirection window, select L4 Policies. The L4 Policies pane appears.

25. In the L4 Policies pane, configure the traffic flow. HTTPS from clients should be linked to the SSL-Farm and HTTPS traffic from AppXcel should be inspected by L7 data and linked to the English-Farm or Japanese-Farm.

26. Click Add. The Add L4 Policy window appears.

27. In the Add L4 Policy window, create an L4 Entry (SSL Traffic should be linked to the SSL-Farm).

28. Click Ok to accept your preferences. The policy for the SSL traffic from the clients is ready.



29. Click Add again to create the L7 Policy to handle the traffic coming from AppXcel. The Add L4 Policy window appears.

30. Configure AppDirector to select a language farm according to the Users' language. In the Add L4 Policy window, in the Layer7 Related Parameters section, configure the following parameters according to the explanations provided:

Backend Encryption Port: 443

Explicit Farm Name: None

L7Persistent Switching Mode:

First

Bytes of Request to Read: 3504

PORT Classification Input: Header

31. Click Ok to save your preferences.

32. In the L4 Policies window, configure the interception policies for both HTTPS traffic from the users to the AppXcel and HTTPS traffic from the AppXcel to the backend servers. The special Layer 7 inspection is achieved using a Layer 7 type interception mechanism that listens on a predefined port for header information coming from the AppXcel, and makes routing decisions on SSL traffic that match those headers. This special protocol between AppXcel and AppDirector is a Radware proprietary protocol and cannot be used with any other vendor.


The following example of the L4 Policies window shows the properly configured policies.



Configuring AppXcel The process of setting up AppXcel to work according to this scenario is performed in several stages:

• Configuring AppXcel Networking, 78 • Configuring the AppXcel Security Key and Certificate, page 81 • Configuring the Tunnel, page 82 • Backing Up the AppXcel Configuration, page 84

Configuring AppXcel Networking In order to use AppXcel in this scenario, you need to first configure its networking settings.

To configure AppXcel networking:

1. Connect to AppXcel using a serial cable.

2. In the COM Properties window, set your terminal emulation program parameters according to the explanations provided:


Data bits: 8

Parity: None



Stop bits: 1

Flow control: None

3. Boot AppXcel and wait for the login prompt: Radware AppXcel Version 1.00.01

AppXcel login:

4. Log in with the default username and password (radware/radware).

5. Assign a management address to LAN1: net management-ip create 10.10.11.20 255.255.255.0 -inf 1

6. Make sure the management computer is on the same network segment as the AppXcel. Using APSolute Insite, add an AppXcel device (10.10.11.20). The default username and password are: radware/radware. The AppXcel icon appears in the main window.


The first step is to configure the networking.

7. Double-click the AppXcel icon. The Setup window appears.

8. In the Setup window, click Networking > Routing Table. The Routing Table window appears.

9. In the Routing Table window, click Add and create the default gateway. (The default gateway should be AppXcel's interface on that network segment, in this example it is 10.10.11.10). The following is an example configuration of the Edit Route settings:

10. Click Ok three times and return to the main window.



Configuring the AppXcel Security Key and Certificate You now need to configure the Security Key and Certificate. The following options are available:

• Import a PKCS12 format package that contains both Key and Certificate. This is the file format that is generated when exporting the Key and Certificate from an IIS Server.

• Import each separately. This option is used when storing both on a backup media. You can Import using copy and paste or using a PEM/DER format.

• The key can be created on the AppXcel and a certificate request can be created on top of it. This request should be exported and sent to a Certificate Authority (CA) company. After signing it the certificate should be uploaded to the AppXcel.

The following example describes the second option – importing the security key and certificate separately. Make sure you have the two files ready (key + certificate). For more on implementing the other options, refer to the AppXcel User Guide.

To import the security key and certificate:

1. Right-click the AppXcel icon and select Keys. The Keys window appears.

2. In the Keys window, click Import Key. The Import Key window appears.

3. In the Import Key window, configure the key parameters as follows:

4. In the New Key ID text box, type a key ID (1 for example).

5. In the Key Password text box, type the key password (to be used when exporting the key for backup purposes). Then type it again in the Verify Key Password text box for confirmation purposes.



6. Select the import method you want to use, File or Text. Then paste your key in the text box to replace the "Erase this line…" text or browse your disk to locate the key file. The string that should be pasted in this screen should begin with: " -----BEGIN RSA PRIVATE KEY-----………." and end with: "-----END RSA PRIVATE KEY-----".

7. Click Ok to close this window. The key you just imported is listed in the Keys window.

8. In the Keys window, select the key line and click Edit. 9. Click the Certificate button and select Import. Follow the procedure for

importing a key. Enter the relevant parameters in the New Certificate window as shown below:

10. Click Ok repeatedly to close the windows. The Key and the Certificate are configured in your AppXcel.

Configuring the Tunnel The next step is to configure the tunnel. A tunnel is the main application of the AppXcel and is represented by an IP address that should be accessible by the AppXcel. All traffic destined to the tunnel's IP address will get decryption services. It is possible to configure multiple tunnels in one AppXcel.



To configure the tunnel:

1. Double-click the AppXcel icon and click Add. The Edit Tunnel window appears.

2. In the Edit Tunnel window, set the following parameters according to the explanations provided:

Tunnel Serial ID: 1

Interface: LAN 1 (The default value should be left).

IP Address: The IP of the tunnel (should be the same IP configured in the AppXcel as the server IP in the " SSL" farm).

Mask: The Subnet mask of the tunnel's network segment.

Port: The application port of the traffic that should be handled by the tunnel. Normally, it should be 443 for SSL decryption.

Server IP: The IP address of the L4 Policy in the AppDirector.


Server Port: The application port of the backend servers' farm or L4 Policy that should receive the traffic. When using backend SSL, port 443 is normally used.

Attached Key ID: The key ID.

Service Type: The type of application that is terminated. This is in order to provide special support for various applications such as HTTP (compression, caching, headers rewrite), FTP (FTPS support), or SMTP (SMTPS support). Other will not modify any of the application data content except terminating the SSL.

3. In the Edit Tunnel window, click Advanced. The Advanced pane appears.

4. In the Advanced pane, set the following parameters according to the explanations provided:

• Select the Tunnel Transparency checkbox. This forces AppXcel to establish a connection to the backend servers using the original clients' source IP.

• Select the Enable Backend SSL checkbox. This forces AppXcel to establish an SSL session instead of a regular clear text session with the backend server.

• In the Backend Layer 7 LB Port text box, type the application port that is to be used for AppXcel and AppDirector to communicate regarding the L7 information that needs to be exchanged. In this example, port 88 is used.

• The Backend Cipher Suite (which can be Low, Medium or High) is for the SSL session between the AppXcel and the Backend server. Radware recommends using 'Low' in order to boost performance. As the session is internal and should not leave the local datacenter, there is no need for it to be highly secured.

5. Click Ok to accept your preferences and close the main AppXcel window.

Backing Up the AppXcel Configuration The final task is to back up the AppXcel's configuration file.

To back up the configuration:

1. To save a copy of the configuration, select Device > Configuration File. The Download pane appears.

2. In the Download pane, select the AppXcel device, provide a path on your local hard disk to save the file, and type the configuration export password (default: radware).

3. Click Apply to start downloading and saving the configuration file. AppXcel is ready for operation.



Scenario 7: Global Traffic Management with DNS/HTTP Redirection

Scenario Description

When using the global traffic management solution, several redirection methods are available to define how service requests are redirected to required destinations.

When a client sends a new request for service, AppDirector selects the best available server for the task. If the required server is placed at the local site, AppDirector forwards the request for service to that server. If the required server is located at the remote site, AppDirector redirects the request for service using one of the following methods:

• DNS Redirection • HTTP Redirection • RSTP Redirection • Triangulation Redirection An AppDirector that is included in a global traffic management solution continuously monitors the network and responds to permanent or transient performance conditions, directing customers to the best available site. The two main stages involved in this process are: making the management decision about the best site and redirecting the user to this site, if needed. Then, a server is selected within the local site.

The selection of the best server farm is done according to the global IP traffic management decisions that are based on load balancing and/or proximity considerations:

• Load Balancing: To distribute the traffic load among physical sites, the load balancers in the network must continuously update each other with health and performance indices. The main load balancing site must know the condition of every other site in order to make the appropriate decisions based on the real-time dynamic load.

• Proximity: Proximity considerations are based on network proximity. Network proximity indicates the network distance or time distance between the user and a data resource. For example, a user is geographically closer to the New York site than to the Chicago site, yet can access the Chicago site faster when the network path to the New York site is overloaded – in terms of network proximity, the user is closer to Chicago than to New York.

On the basis of these load and/or network proximity considerations, AppDirector makes the load-balancing decision and determines to which site the request for service is redirected.


AppDirector Global This scenario requires that both AppDirectors (Local and Remote) have a Global license.

AppDirector Global performs local load balancing as well as distributed load balancing according to load considerations, but also directs clients to sites that are “closest” to that client according to the network proximity considerations.

For more information about communication between Distributed Sites, refer to the AppDirector User Guide, Chapter 7.

Redirection Methods in this Scenario Once the best site for a particular task has been selected, the user is redirected to that site. In this scenario, AppDirector will use one of the following redirection methods to perform the redirection:

• DNS: DNS redirection uses the DNS mechanism. AppDirector has the ability to respond to DNS queries for the IP address of a specified host name that represents the service. When such a query is made, AppDirector responds with an IP address that provides the best service for the client. This IP address belongs to a local farm on AppDirector, to a remote farm on the distributed AppDirector, or to a remote standalone server.

• HTTP: For HTTP traffic, AppDirector uses the standard HTTP redirection mechanism (code 302/moved temporarily) to redirect the client to an alternate site. This alternate site can either be a standalone server or another AppDirector with its own virtual address.

For further information about DNS and HTTP redirection methods, refer to the AppDirector User Guide, Chapter 7.





Suggested Physical Implementation

Figure 7 illustrates a suggested physical implementation of the AppDirector in Global Traffic Management with DNS/HTTP Redirection.

G2G1

Web Server Director

F1 F2 F3 F4 F5 F6 F7 F82 4 6 8

1 3 5 7PW R

RESET

SYS OK

MODE

G2G1

Web Server Director

F1 F2 F3 F4 F5 F6 F7 F82 4 6 8

1 3 5 7PW R

RESET

SYS OK

MODE

G2G1

Web Server Director

F1 F2 F3 F4 F5 F6 F7 F82 4 6 8

1 3 5 7PW R

RESET

SYS OK

MODE

G2G1

Web Server Director

F1 F2 F3 F4 F5 F6 F7 F82 4 6 8

1 3 5 7PW R

RESET

SYS OK

MODE

Figure 7: Using AppDirector with DNS/HTTP Redirection

Step-by-Step Configuration Before you begin this configuration section, refer to Step 3: Pre-Installation Tasks, page 9.

The configuration for this scenario is performed in the following stages:

• Configuring the Networking Settings and Connecting to the Main AppDirector, page 88.

• Configuring the Networking Settings and Connecting to the Remote AppDirector, page 91

• Creating a VIP and Layer 4 Policy in the Main AppDirector, page 93. • Configuring Redirection Parameters in the Main AppDirector, page 97 • Creating a VIP and Layer 4 Policy in the Remote AppDirector, page 98 • Configuring Redirection Parameters in the Remote AppDirector, page 101 • Configuring the Reporting Intervals, page 102 • Configuring Redirection, page 103


Configuring the Networking Settings and Connecting to the Main AppDirector

You need to configure the network settings and connection to the main AppDirector.

To configure networking and connect to the main AppDirector:

1. Connect the device and define interfaces 1, 4 and 16. Refer to Step 3 for a detailed explanation on how to set up the management interface.

2. Double-click the AppDirector icon. The Connect to Device window appears.

3. In the Connect to Device window, type in the device’s IP address (10.204.150.190) and click Ok.

4. Double-click the AppDirector icon again. The Setup window appears.


6. In the Interface window, set the following interfaces according to the explanations provided:

IF Num: F-1

IP Address: 172.16.1.10

Network Mask: 255.255.255.0



IF Num: F-4

IP Address: 10.0.10.1


IF Num: F-16

IP Address: 10.204.150.190


The Routing Table will display the following settings:

Destination IP Address: 0.0.0.0


Next Hop: 172.16.1.1

IF Number: F-1


7. Add local servers.

Note: In this example we use only one local server but you can add as many as required.

From the main toolbar, click Add > Servers > Server. A Server icon appears in the main window.

8. Double-click the Server icon. The Server window appears.



9. In the Server window, set the following parameters according to the explanations provided:

Server Name: Server 1

Admin Status: Selected


Note: You have to type the IP Address in the IP address text box and click Add.

10. Click Apply and Ok.

11. Repeat the above steps to add as many local servers as needed to the map, including servers from both the local and remote site.

12. Click Ok to apply your settings.

Configuring the Networking Settings and Connecting to the Remote AppDirector

You need to configure the network settings and connection to the remote AppDirector.

To configure networking and connect to the remote AppDirector:

1. Connect the device and define interfaces 1, 4 and 16. Refer to Step 3 for a detailed explanation on how to set up the management interface.

2. Double-click the AppDirector icon. The Connect to Device window appears.

3. In the Connect to Device window, enter the device’s IP address 10.204.150.191 and click Ok.

4. Double-click the AppDirector icon again. The Setup window appears.


6. In the Interface window, set the following interfaces according to the explanations provided:

IF Num: F-1

IP Address: 172.16.2.10


IF Num: F-4



IF Num: F-16

IP Address: 10.204.150.191



The Routing Table displays the following settings:

Destination IP Address: 0.0.0.0


Next Hop: 172.16.2.1

IF Number: F-1

7. Add local servers.

Note: In this example we use only one local server but you can add as many as required.

From the main toolbar, click Add > Servers > Server. A Server icon appears in the main window.

8. Double-click the Server icon and set the following parameters according to the explanations provided:

Server Name: Server 2

Admin Status: Selected

IP address: 10.0.20.10

Note: You have to type the IP Address in the IP address text box and click Add.

9. Click Apply and Ok.

10. Repeat the above steps to add as many local servers as needed to the map, including servers from both the local and remote site.



11. Click Ok to apply your settings.

12. To save the APSolute Insite map, in the main window, select File > Save Site or press <CTRL>+S on your keyboard. Assign a name to the site map and click Save.

Creating a VIP and Layer 4 Policy in the Main AppDirector The next step is to create a VIP and Layer 4 policy in the main AppDirector.

To create a VIP and a Layer 4 Policy:

1. Right-click the Main AppDirector icon and select APSolute OS > Traffic Redirection. The Traffic Redirection window appears.


2. In the Traffic Redirection window, select Farms and click Add. The Farm window appears.

3. In the Farm window, set the following parameters according to the explanations provided:

Farm Name: AD1

Mode: Global

4. Click Apply > Add. The Farm Servers window appears.

5. In the Farm Servers window, select the server located on this site from the Server Name dropdown list and add a server description if required.



6. Click Ok. The Farm Servers window closes.



9. In the Traffic Settings pane, set the traffic settings according to the explanations provided:

Dispatch Method: The algorithm used to split traffic between servers, which can be cyclic, according to the amount of traffic or to the number of sessions. Other options include Hashing, the result of SNMP query to the servers (like CPU Usage), or the response time of the server to the AppDirector's health check traffic.

For this scenario, we recommend that you select Cyclic.

Session Mode: The way AppDirector adds entries to its Client Table. For this scenario, select ServerPerSession.

Distribution Threshold:

5 Note: the default value of Distribution Threshold is 2500. This scenario is using the value 5 for demonstration purposes.


Redirection Mode For this scenario, select HTTP as the Redirection mode.

Note: If DNS is selected as the Redirection mode, you need to define a DNS Redirection Fallback.

HTTP Redirection Mode:

Select the required HTTP Redirection Mode.

Note: When the HTTP Redirection Mode is set to Name Mode, in the Redirect To text box you need to type the name to which the request for service is redirected. If such a name is not specified the Server name is used.

Client Aging Time: This is the period AppDirector keeps an entry of a session in the Client Table when there is no activity. AppDirector resets this timer each time there is TCP activity on the session. The default value is 60 seconds; however, Radware guidelines for the best tuning value are to determine your application timeout and add a minute to that value. This way persistency is maintained for your application's session. The value should be written in seconds, not minutes.

Note: Additional settings can be tuned In the Traffic Settings pane. Nonetheless, it is recommended that you maintain the default settings unless otherwise required, for example, when enabling NAT, Installing a remote server on an AppDirector Global, and so on. Before enabling any of those advanced features, make certain they are applicable for this scenario.

10. Click Ok to record your preferences and close the Farm window.

11. In the Traffic Redirection window, click L4Policies. The L4 Policies window appears.

12. In the L4 Policies window, click Add.

13. In the VIP Address text box, type the IP address of the VIP. For this scenario, type 172.16.1.2.


15. In the Add L4 Policy window, set the following parameters according to the explanations provided:

L4Protocol: TCP

L4Port: 80

L4Policy name: any text string

Farm name: AD1

16. Click Ok to close the Add L4 Policy window.

17. Click Ok to close the L4 Policies window.



Configuring Redirection Parameters in the Main AppDirector The next task is to configure the redirection parameters in the main AppDirector.

To configure redirection parameters:

1. Right-click the main AppDirector icon and select APSolute OS > Traffic Redirection. The Traffic Redirection window appears.

2. In the Traffic Redirection window, in the Farms pane, select the row for the AD1 farm and click Edit. The Farm window appears.

3. In the Farms window, click Add. The Farm Servers window appears.

4. In the Farm Servers window, set the following parameters according to the explanations provided:

Server Name: Remote AD

When you select the server from the dropdown list, The server address appears automatically.

Type: Distributed AD

Weight: The weight should be the sum of the total weight of all local servers on the other site. For example, if there are 3 servers on the remote site, each of them is configured with a weight of 1, the weight should be 3.

Server Description: An optional text description.


6. Click Ok. The Farm window closes.

7. In the Traffic Redirection window, click Redirection. The Redirection pane appears.

8. In the Redirection pane, select your device and click Edit. The Traffic Redirection window for the selected device appears.

9. In the Traffic Redirection window, make sure that the Distributed Sites pane is selected.

10. In the Distributed Sites pane, from the Redirection Mode dropdown list, select Redirection.


11. Click Add. The Edit Report Table window appears.

12. In the Edit Report Table window, set the following parameters according to the explanations provided:

Distributed Farm: Type in the name of the remote Farm: AD2.

Distributed Server: Type in the local VIP address: 172.16.1.2.

L4 Policy Select the L4 Policy you configured (HTTP).

Report Destination Address:

Type in the IP address of the remote AD: 172.16.2.10.

Redundant Remote Address

If the main AppDirector device has a redundant device next to it, set its address here to ensure a smooth backup process.

13. Click Ok to close all opened windows.

Creating a VIP and Layer 4 Policy in the Remote AppDirector The next step is to create a VIP and Layer 4 policy in the remote AppDirector.

To create a VIP and a Layer 4 policy in the remote AppDirector:

1. Right-click the Remote AppDirector and select APSolute OS > Traffic Redirection. The Traffic Redirection window appears.

2. In the Traffic Redirection window, select Farms >Add. The Farm window appears.

3. In the Farm window, set the following parameters according to the explanations provided:

Farm Name: AD2

Mode: Global



4. Click Apply > Add. The Farm Servers window appears.

5. In the Farm Servers window, select the server located on this site from the Server Name dropdown list and add a server description if required.



8. In the Traffic Settings pane, set the traffic settings according to the explanations provided:

Dispatch Method: The algorithm used to split traffic between servers, which can be cyclic, according to the amount of traffic or to the number of sessions. Other options include Hashing, the result of SNMP query to the servers (like CPU Usage), or the response time of the server to the AppDirector's health check traffic.

For this scenario, we recommend that you select Cyclic.

Session Mode: The way AppDirector adds entries to its Client Table. For this scenario, select ServerPerSession.

Distribution Threshold:

5 Note: the default value of Distribution Threshold is 2500. This scenario is using the value 5 for demonstration purposes.

Redirection Mode For this scenario, select HTTP as the Redirection mode.

Note: If DNS is selected as the Redirection mode, you need to define a DNS Redirection Fallback.

HTTP Redirection Mode:

Select the required HTTP Redirection Mode.

Note: When the HTTP Redirection Mode is set to Name Mode, in the Redirect To text box you need to type the name to which the request for service is redirected. If such a name is not specified the Server name is used.

Client Aging Time: This is the period AppDirector keeps an entry of a session in the Client Table when there is no activity. AppDirector resets this timer each time there is TCP activity on the session. The default value is 60 seconds; however, Radware guidelines for the best tuning value are to determine your application timeout and add a minute to that value. This way persistency is maintained for your application's session. The value should be written in seconds, not minutes.

Note: Additional settings can be tuned In the Traffic Settings pane. Nonetheless, it is recommended that you maintain the default settings unless otherwise required, for example, when enabling NAT, Installing a remote server on an


AppDirector Global, and so on. Before enabling any of those advanced features, make certain they are applicable in such a Local Triangulation scenario.

9. Click Ok record your preferences and close the Farm window.



12. In the VIP Address text box, type the IP address of the VIP. For this scenario, type 172.16.2.2.


14. In the Add L4 Policy window, set the following parameters according to the explanations provided:

L4Protocol: TCP

L4Port: 80

L4Policy name: Any text string

Farm name: AD2





Configuring Redirection Parameters in the Remote AppDirector The next task is to configure the redirection parameters in the remote AppDirector.

To configure redirection parameters:

1. Right-click the main AppDirector, select APSolute OS > Traffic Redirection. The Traffic Redirection window appears.

2. In the Traffic Redirection window, in the Farms pane, select the row for AD2 farm and click Edit. The Farm window appears.

3. In the Farm window, click Add. The Farm Servers window appears.

4. In the Farm Servers window, set the following parameters according to the explanations provided:

Server Name: Remote AD

When you select the server from the dropdown list, The server address appears automatically.

Type: Distributed AD

Weight: The weight should be the sum of the total weight of all local servers on the other site. For example, if there are 3 servers on the remote site, each of them is configured with a weight of 1, the weight should be 3.

Server Description: An optional text description.


6. Click Ok. The Farm window closes.




10. In the Distributed Sites pane, from the Redirection Mode dropdown list, select Redirection.


11. Click Add. The Edit Report Table window appears.

12. In the Edit Report Table window, set the following parameters according to the explanations provided:

Distributed Farm: Type in the name of the remote Farm: AD1.

Distributed Server: Type in the local VIP address: 172.16.2.2.

L4 Policy Select the L4 Policy you configured (HTTP).

Report Destination Address:

Type in the IP address of the remote AD: 172.16.1.10.

Redundant Remote Address

If the remote AppDirector device has a redundant device next to it, set its address here to ensure a smooth backup process.


Configuring the Reporting Intervals The reporting settings should be configured for both the main device and the remote device. You need to perform the following procedure for each AppDirector.

To configure the reporting intervals:

1. Double-click the AppDirector icon. The Setup window appears.

2. In the Setup window, click Global. The Global pane appears.

3. In the Global pane, select Advanced Settings and then click Edit Settings. The Advanced Settings window appears.



4. In the Advanced Settings window, set the following parameters according to the explanations provided:

Load Report Interval: Set an interval number (in seconds) as required.

Report Timeout: Set an interval number (in seconds) as required.

5. Click Ok to apply the setup and to close all opened windows.

Configuring Redirection The process of configuring redirection is performed in several stages:

• Defining Redirection to HTTPS, page 104 • Configuring DNS Redirection, page 105


Defining Redirection to HTTPS AppDirector can redirect HTTP traffic to HTTPS. Using HTTP Redirection, AppDirector can be configured to redirect clients to secure access to the site, using HTTPS.

When the client accesses the farm, and AppDirector decides to redirect the client using HTTP Redirection, you can set AppDirector to indicate to the client that the site must be accessed using HTTPS rather than HTTP.

To define redirection to HTTPS, you need to perform the following procedure for on both the main AppDirector and the remote AppDirector.

To define redirection to HTTPS:

1. Right-click the AppDirector icon and select APSolute OS > Traffic Redirection. The Traffic Redirection window appears.

2. In the Traffic Redirection window, select Farm. The Farm pane appears.

3. In the Farm pane, double-click the selected farm or click Edit. The Farm window appears.



4. In the Farm window, select Traffic Settings. The Traffic Settings pane appears.

5. In the Traffic Settings pane, select the Redirect to HTTPS checkbox and click Ok.


Configuring DNS Redirection

AppDirector can redirect clients to other sites using the DNS mechanism. When using DNS Redirection, AppDirector becomes the authoritative DNS server for its farms. When a client sends a DNS request for a specific service, the AppDirector selects the local farm IP or a remote farm address for the answer.

The configuration of DNS Redirection differs from the previous example only with regard to setting the Redirection Mode to DNS Redirection in the main AppDirector configuration.

When using DNS Redirection for a farm, for example, www.radware.com, the authoritative DNS server for radware.com is configured with an NS (Name Server) record pointing to the AppDirector Virtual IP Interface (VIPI) Address, or to the AppDirector physical interface if no backup device is present.

When a request for www.radware.com arrives at this DNS server, it sends the request to the main AppDirector, which then resolves it either to its own farm or to a remote server or a remote farm on a distributed AppDirector.

The name of the farm on the AppDirector must match the required URL, for example, www.radware.com.

To support site redundancy, a second NS record is configured, using the remote AppDirector Virtual IP Interface (VIPI) address. When the main AppDirector (or its backup device) is available, requests are received and are resolved by it. Otherwise, requests are sent to the remote AppDirector. This is part of the Internet DNS mechanism. The DNS server can be located anywhere.

The following DNS settings should be applied to both the main and remote AppDirectors.


To define DNS redirection:

1. Right-click the AppDirector icon and select APSolute OS > Traffic Redirection. The Traffic Redirection window appears.

2. In the Traffic Redirection window, click DNS. The DNS pane appears.

3. In the DNS pane, set the following DNS parameters:

• Select the Enable DNS checkbox.

• Select the Respond With Two A records checkbox.

• In the Host Name text box, enter the Host Name (domain for which DNS resolve is required).

• From the L4Policy Name dropdown list, select the relevant L4 policy.

4. In the DNS pane, click Add and select Farm. The Farm pane appears.

5. In the Farm pane, select the AD1 Farm and click Edit. The Farm window appears.




7. In the Traffic Settings pane, change the Redirection mode to DNS and set the DNS Redirection Fallback.

8. Click Ok to close the Edit Farm window.





12. In the Distributed Sites pane, set the following DNS parameters:

• From the DNS Redirection dropdown list, select the redirection mode (DNS, DNS + HTTP + Triangulation, and so on).

• From the DNS Redirection Fallback dropdown list, select the relevant fallback mode.

In order to allow DNS servers to redirect traffic to the AppDirectors, you must create an L4 Policy with the VIP that is to be used as an NS record.



15. In the VIPAddress text box, for each site type in a different VIP address.




17. In the Add L4 Policy window, for each site set the following parameters according to the explanations provided:

L4Protocol: Any

L4Port: Any

L4Policy name: Any text string

Application: Virtual Interface




Scenario 8: AD as a L2 Bridge (VLAN) in the Datacenter

Scenario Description This scenario is another way to install the AD. Radware recommends using it only if no other option (Scenario numbers 1, 2, 3) is suitable for your needs. It involves VLAN settings where more than one interface of the AD should be a member in the same L2 segment. The AD acts a bridge in terms of IP segments and does not perform L3 routing between the interfaces members in the VLAN.

The term VLAN in Radware products means that the servers located under the AD and the FW / Router located on top of the AD are on the same L2 segment.


• The default GW of the servers can be the AD but also the router/FW on top. This is an advantage as no routing changes are required in the servers.

• QOS is available by AD according to application data (like HTTP cookies).


• Changes in the physical network. Installing AD in such a scenario requires changes in both cabling and routing.

• Direct access to and from the servers is done via AD. This should be included in the overall traffic calculations processed by AD (for example, database synchronization, software auto updates, and so on).

• Security is affected as the servers are located in the same IP segment of the AD and the router on top of it (most of the time these are public IPs).



Suggested Physical Implementation Figure 18 illustrates a suggested physical implementation of AD as a Bridge.


G1 G2 G3 G4 G5

F9 F10 F11 F12F1 F2 F3 F4

F13 F14 F15 F16F5 F6 F7 F8


G1 G2 G3 G4 G5

F9 F10 F11 F12F1 F2 F3 F4

F13 F14 F15 F16F5 F6 F7 F8

Figure 8: AD as a Bridge in the Datacenter






2. In the Traffic Redirection window, select Farm > Add. The Farm window appears.



3. In the Farm window, type the farm name in the Farm Name text box.

Note:




Note:




Note:

The servers should be located in the AppDirector's local segment. If not, you need to configure a relevant entry under the Routing Table. Other parameters should retain their default value. Click the Help button or refer to the AppDirector User Guide for a detailed explanation about the use of these settings.

7. Click Ok to confirm and return to the Traffic Redirection window. Repeat the above steps for the additional servers as required.







10. Click Connectivity Check. The Connectivity Check pane appears.




12. In the Traffic Redirection window, click L4 Policies. The L4 Policies pane appears.


13. In the L4 Policies pane, click Add. The L4 Policies window appears.

14. In the L4 Policies window, in the VIP Address text box, type the VIP address that AppDirector will listen on. All traffic coming to this VIP will be classified according to the L4 Policy that you set now.

15. Click Add to configure the policies. The Add L4 Policy window appears:






17. In case you have other farms and services, configure the VIPs and policies for them in this window as well.

18. Upon completion, click Ok twice to close the windows and return to the APSolute Insite main windows.

19. To configure the device management settings, refer to Step #5: Management Settings page 119.


21. To configure advanced Layer 7 parameters, refer to Step #7: Advanced Content Switching – Layer 7, page 119.



Step #5: Management Settings The next step is to configure the AppDirector Management properties. These settings are relevant for all scenarios.

To configure the management properties:

1. Double-click the AppDirector icon. The Setup window appears.

2. In the Setup window, click Access. The Access pane appears.

3. In the Access pane, select the Active checkbox for the desired management tool. You can enable Telnet, Web (HTTP or HTTPS) and SSH. For security reasons, Radware recommends using HTTPS (Secure Web) instead of HTTP and SSH instead of Telnet.

Note: When Active is selected, the default username and password are radware.

4. Click Ok to close the Access pane.


Step #5: Management Settings

5. It is recommended to modify the default account. In the main window, select the AppDirector and select Device > Device Permissions. The Device Permissions window appears, with the User Table pane displayed by default.

6. In the User Table pane, click Add to create more accounts or double-click the radware account to modify its password. Click Apply.

7. To enable the physical ports, in the Device Permissions window, click Management Settings. The Management Settings pane appears.

8. In the Management Settings pane, enable the physical ports to be allowed for management for each management method (SNMP, Telnet, Web, SSH, SSL) and click Apply.


Step #6: Configuring Redundancy in the AppDirector using VRRP

This step covers the redundancy configuration. It guides you through the steps needed to configure redundancy on your pair of AppDirectors.

Note: Redundancy should be set only when all configured interfaces are active (a network cable is connected and the state is 'up').

To configure redundancy using VRPP:

1. To connect to the backup AppDirector device, on the main toolbar,

click Add > Add Radware Device > AppDirector. Another AppDirector object appears in the main window.

2. To connect to the device, expand the icon view and double-click the AppDirector icon. The Connect to Device window appears.



3. Select both AppDirectors (holding down the <CTRL> button) and then click

Link on the toolbar. The Multiple Device Links window appears.

4. In the Multiple Device Links window, select the appropriate option (in this example AppDirector_Active is "backed-up-by" AppDirector_Backup) and click Ok. The Redundancy window appears.


5. In the Redundancies window, from the Relation Type dropdown list, select VRRP.

Note: Radware recommends using VRRP (Virtual Router Redundancy Protocol) as the redundancy method. However it is possible to use Radware's propriety ARP redundancy mechanism. For further information, refer to the AppDirector User Guide.

6. In the Redundancies window, click Add VRID on the left side to create the VRRP settings for the first interface. The Edit VRRP Table window appears.

7. In the Edit VRRP Table window, set the following parameters according to the explanations provided:

Note: If you configured any VLAN interface in the AD select the relevant VLAN name in the Interface field instead of the physical interface name. Follow this rule any time you are requested to select a physical interface.

Interface: The interface name.

VRID: The VRID number (Virtual Router Identification). Start from 1 or choose any value between 1 to 255. Change the priority to 255 (the highest possible to configure and a must in case of Active device).

Primary IP: The IP address of the Active device.





8. Click Ok to confirm the settings and return to the Redundancies window. The new entry appears in the Redundancies window, as shown in the example below.

9. In the Redundancies window, select the new entry on the left side and click the right arrow button to copy this entry to the backup device. The Copy Line from Master to Backup window appears.

10. In the Copy Line From Master to back up window, select the equivalent IP for the active's interface on the backup device (in this example 10.10.10.10 in the Active is equivalent to 10.10.10.11 on the Backup).


11. Repeat steps 5-10 for each additional interface on the AppDirector. After the redundancy configuration, assuming only one interface is configured in AppDirector, the Redundancies window appears as shown below.

The next step is to add the associated IP addresses to each VRID.

Associated IP addresses are the IP addresses that should be controlled by the VRRP mechanism and are taken over by the Backup device when the Active is not in service or down for maintenance.



12. In the Redundancies window, click on the left Associated IP button. The Associated IP Address window appears.

13. In the Associated IP Address window, configure the IP address, the interface and the relevant VRID. The relevant VRID is the VRID that belongs to the network segment as the added IP address.

14. Click Add to confirm.

Notes:

All L4 Policies, NAT IPs, and DNS VIPs should be included in the associated IP table. Physical IP addresses should not be included in the Associated IP table.

The AppDirector's Physical IP address is usually used as a default gateway for other network elements. If the backup device takes over, it must include this IP address as one of its own IP addresses (to enable other network elements to route their traffic via a live IP address). However, the active device cannot be accessed during the takeover period (that was caused due to maintenance tasks) because its IP address is taken over by the backup device. The solution is to use VIPs instead of physical IPs addresses. In order to do this, you must associate at least one VIP (like existing or new created L4 Policy) to each VRID (the VIP should match the VRID's network segment). As a result, the Active AppDirector will still be accessible during takeover as the backup will not take ownership of the active AppDirector's IP address. The configured VIPs are used as the network's default gateway in the same manner as the physical IP addresses were used until then.


15. The last step is to activate these VRRP settings. Double-click the relevant interface entry. The Edit VRRP Table window appears.

16. In the Edit VRRP Table window, select the Enable Virtual Router checkbox. This must be repeated for each interface entry.

The AppDirector redundant setup is ready. The next step is to synchronize the actual setup.



Synchronizing Configurations between Active and Backup Devices The Copy Configuration wizard converts the Active device's configuration into a Backup device's configuration format. You must run this wizard each time you change any of the AppDirector's settings in order to have an updated configuration on the Backup device.

To synchronize configurations between active and backup devices:

1. In the AD Redundancies window, click Copy Configuration. The Copy Configuration window appears.

2. In the Copy Configuration window appears, click Apply to perform the actual convert and send action.

Note: The copy action is performed using TFTP between the AppDirector and the APSolute Insite computer. As TFTP is sensitive to NAT over the network, make sure that the management computer is located on the same network as the AppDirector or is routed with no NAT in between.

At this stage, the primary AppDirector is ready for operation. It is very important to back up the current configuration and store it in a safe location. It is also important to repeat the backup action periodically to ensure you always store an updated backup configuration file.

3. To back up the configuration file, in the main window, select the device and click Device> Configuration File. The Configuration File window appears.


4. In the Configuration File window, click browse to locate and select a safe location to store the configuration file on your hard disk. The default location is the User Files directory in the APSolute Insite installation folder.

5. Once the download is complete, as indicated by the 100% progress bar, click Apply.

6. Click Ok to close the Configuration File window.


Step #7: Advanced Content Switching – Layer 7

Step #7: Advanced Content Switching – Layer 7 Sometimes it is necessary to make load-balancing decisions according to information stored in the application Layer (L7), and not according to the source IP address or port. This may be relevant in the interest of persistency, for example, for a proxy server or a Firewall that performs NAT to the IP of the clients that need to have access to the servers' farm. For such purposes, you can configure Session ID Persistency in the AppDirector device.

To configure Session ID persistency:


2. Select the farm for which you want to enable L7 and click Session IDs. The Session IDs pane appears:

Note: This example shows how to set “session_id” as the Session Identifier. According to the string that follows this identifier; AppDirector will maintain persistency. The Session ID can be found in the client's HTTP GET request or in the server's HTTP initial response. Radware recommends consulting your application expert as this field has no standards and can be implemented in a variety of ways.


3. In the Session IDs pane, click Add. The Edit Session ID Persistency Table Text Match window appears.

4. In the Edit Session ID Persistency Table Text Match window, set the following parameter according to the explanation provided:

Persistency Identifier: Type in the "session_id" ; the relevant identifier, according to your application.

Notes:

Additional settings in this window should not be changed unless your application has other HTTP headers that might have the same identifier inside or there are some other persistency needs that are not covered with this example.

To better understand the role of these parameters, refer to the AppDirector User Guide for a detailed explanation.

5. Click Ok to confirm and close this window.




Step #7: Advanced Content Switching – Layer 7


7. In the Traffic Settings pane, from the Sessions Mode dropdown list, select Server per Session to allow AppDirector to redirect TCP sessions from the same source IP (Proxy or Firewall) to different servers.

8. Click Ok and close the Farm window. AppDirector will search for the HTTP headers and will take the balancing/persistency decision according to this data.

Note: Many other L7 decision taking and persistency are possible using AppDirector. For more information kindly refer to the AppDirector User Guide.



Step #8: Client NAT Settings Sometimes it is necessary to NAT sessions sent from the AppDirector to the application servers. If the application server's response sessions are routed directly to the Internet, they will be dropped by the destination host (because the source IP address belongs to the application server and not the AppDirector's VIP from the original client's session). For this reason, the application server needs to be forced to respond via the AppDirector, therefore the AppDirector changes the source IP address back to the original requested IP address.

The solutions for this complexity can be either forcing the application server to be routed to the Internet via the AppDirector or to enable Client NAT on the AppDirector.

To enable Client NAT:

1. In the AppDirector main window, right-click the AppDirector icon and select APSolute OS >Traffic Redirection. The Traffic Redirection window appears.


Step #8: Client NAT Settings

2. In the Traffic Redirection window, select the NAT pane. The NAT pane appears.

3. In the NAT pane, click the NAT Settings button. The NAT Settings window appears.

4. In the NAT Settings window, select the Client NAT checkbox to enable the Client NAT capabilities. Click Ok to close the NAT Settings window.


5. In the NAT pane, set the following parameters according to the explanations provided:

Client NAT Addresses: Verify that this option is selected.

From IP Address: Type the first IP address in the range of IP addresses to be used as the source IP address of the traffic sent to the application servers.

To IP Address: Type the last IP address in the range of IP addresses to be used as the source IP address of the traffic sent to the application servers.

6. Click Add to save the range you entered. The following window shows the sample configuration. In this example, 10.10.10.50 was used as the NAT IP address.

7. In the NAT pane, set the following parameters according to the explanations provided:

Client NAT Intercept Addresses:

Verify that this option is selected.

From IP Address: Type the first IP address in the range of IP addresses to be NATed when sent to the application servers.

To IP Address: Type the last IP address in the range of IP addresses to be NATed when sent to the application servers.

8. Click Add to save the range you entered.

9. Click Farm. The Farms pane appears.


Step #8: Client NAT Settings

10. In the Farms pane, select the farm for which you want to configure Client NAT and click Edit. The Farm window appears.


12. In theTraffic Settings pane, set the NAT IP range you configured in the NAT Address Range text box. This IP range is used as the source IP address of traffic sent to the server in this farm.

13. Click Apply and then click Farm Servers. The Farm Servers pane appears.


14. In the Farm Servers pane, select the server and click Edit. The Farm Servers window appears.

15. Select the Client NAT checkbox to enable Client NAT for this specific server. It is also possible to use different NAT IP as set for the farm for traffic sent to this specific server. If this option is not configured, the farm's setting is used.

Note: It is possible to configure Client NAT on selected farms only or on selected servers only. This is the reason you have to change settings globally, per farm and per server.

16. Click Ok to close the Farm Servers window.

17. Click Ok to close the Farm window.

18. Click Ok to close the Traffic Redirection window. Client NAT is now configured and from now on all users' traffic that is sent to the servers for which you defined Client NAT is NATed according to the settings.


appdirector solution rev 1.03 - radware

Documents