Radware AppDirector – Configuration: Basic Application
This will be the first in a series of posts to cover basic configuration steps for the Radware AppDirector. This post will explain how to create a basic application/website and load balance them across multiple servers. I will also include instructions how to offload SSL on load balancer to reduce overhead on the machines servicing your farm.
1. Create New Farm
The first step to setup a new service is to create a new farm. This will serve as a connection point between the servers hosting the application and the virtual IP address clients will ultimately land on. When creating the new farm, it’s settings will determine how client traffic is load balanced among your servers within that farm (called Dispatch Method), as well as how the AppDirector handles the client table entries for each connection (called Session Mode).
To create a new farm, follow the following steps:
AppDirector –> Farms –> Farm Table
1. Name – Name of your Farm – Use a descriptive name describing the service it’s used for.
2. Session Mode – Tells the AppDirector how to manage the client table
3. Dispatch Method – Tells the AppDirector how to distribute the client traffic to your application servers in the farm.
4. Aging Time – Time (in seconds) the AppDirector will keep a particular entry in the client table. If the aging time is surpassed, the AppDirector will remove the particular entry and make a new load balancing decision upon a new request. You will want to increase this value if 1) your applications require authentication and 2) they do not use Windows authentication or share session data. For example, if your application requires authentication to access, it’s highly likely you want them to land on the same back-end server for each request, at least for a limited amount of time, to prevent them from having to continuously log in. The default value is 60 seconds.
5. Connectivity Check Method: This is a farm level health check which can remove/add servers from the farm – automatically – if the service is unavailable. This check will apply to all servers in the farm. If you choose TCP Port, you will need to provide the port in the “Connectivity Check Port” menu as highlighted below. If you will utilize the Health Monitoring Module, found here, set the value as None.
2. Create Application Servers
The second step to deploying your application will be to configure the application servers that will service your farm. These could be web servers, FTP server, SMTP servers, etc. Each server will be entered separately using the name, IP Address, and Port that the server is listening on. To create an application server, follow the steps below:
AppDirector –> Servers –> Application Servers –> Table
1. Server Name: Enter a name – I suggest the actual server name – to identify the server. If you have a single server serving multiple farms, using the actual server name will be a huge help down the road for easy identification, maintenance tasks, and overall administration. However, you may name the server anything you wish. Keep in mind that this field IS changeable after creation.
2. Farm Name: Select the Farm that was created in Step 1. Note that a server can be joined to multiple farms if needed. Note that this field is NOT changeable after creation.
3. Server Address: Enter the IP address that the server is using for application. Servers can have multiple IP addresses hosting different websites, so make sure to enter the correct one for your application. Note that this field is NOT changeable after creation.
4. Server Port: Enter the port the application is listening on, such as 80, 443, 21, 25, etc. If you are offloading on the AppDirector, you’ll want to choose 80 for a typical web application. Note that this field is NOT changeable after creation.
5. Client NAT & Client NAT Address Range: If you server’s default route does NOT pass through the AppDirector, you will likely need to client NAT to establish connectivity. If so, enable client NAT and select the appropriate address/address range. These should be preconfigured in AppDirector –> NAT –> Client NAT –> NAT Addresses.
3. Create or Import SSL Certificate
Encrypting the data transmitted over the internet, using certificates, is crucial to the security of your application (and business) and should be a part of every public application. Sure, you can host the certificate on your web server, which is perfectly acceptable, however, it requires additional CPU cycles to encrypt/decrypt traffic and is an administrative nightmare when utilizing multiple servers in a farm. Allowing the AppDirector to offload SSL removes this overhead from your servers and gives the administrator a single pane of glass to manage all web certificates. Follow the below examples to create a new certificate, generate a CSR, or import an existing certificate:
Security –> Certificates –> Table
1. Name – This field should be a friendly name for your certificate – call it what you want but keep it descriptive to it’s purpose.
2. Key Size: Choose your desired key size: 512, 1024, or 2048.
3. Common Name: This field should match the exact URL of your application (ie. www.mywebsite.com)
4. Entry Type: To generate a CSR to upload to a public/private CA, choose Signing Request.
5. Key Passphase: Choose a complex password to secure the private key. Hint: You will need this password to export the private key if needed in the future or to export a CSR.
6. Other Fields: Fill out the pertinent information requested in the other fields related to your business.
*After you have all fields completed, click “Set”. This will generate your CSR that you will export using the following steps:
Security –> Certificates –> Export (You may also click yellow “Export PKI components” if you are on the Certificate Table page)
1. Name: Choose the name of the Signing Request (the name you used in step 1 above)
2. Type: Change to Signing Request
3. Passphrase: Password entered in step 5 above which secures the private key
*Click Show to see the CSR in the text box or Export to download a file containing the CSR. This will be the file/text that you will use for requesting a certificate from a public CA (Verisign, GoDaddy, etc) or your private CA.
Once you get the certificate back from the CA, you will need to Import it in the AppDirector. To do this, follow the below steps:
Security –> Certificates –> Import
1. Name: Use the exact name (case sensitive) that you used in Step 1 above. This must match or it will result in an error.
2. Type: Choose Certificate
3: Passphrase: Leave Blank – Passphrases protect the private key and not the certificate itself.
4. Text: Copy the certificate information here or click Browse to upload a file.
*Click Import. At this point, you should be able to see the new certificate in the certificate table.
4. Create New SSL Policy
Now that you have a certificate to use for your application, it’s time to create an SSL policy which will be assigned to your Layer 4 Policy. The SSL policy will define what certificate to use, what intermediate certificate to use, which Cipher Suite to use, and more.
AppDirector –> Layer 4 Traffic Redirection –> SSL Policies
1. Policy Name: Name for SSL policy – name it something descriptive (such as OWA if its for Outlook Web Access)
2. Certificate: Choose the certificate created or Imported above.
3. Cipher Suite: Choose the cipher suite you want the AppDirector to use (check with your security team if unsure)
4: Intermediate Certificate: Choose the intermediate certificate supplied by your CA. It must be imported first at Security –> Certificates –> Import. Choose Intermediate CA Certificate for the type.
5: Listening Server Port: Traditional SSL offloading will require port 80 here, but if your server listens on another port, such as 8080 or 8081, enter it here. It must match the port on the Application Servers in this farm.
5. Create New Layer 4 Policy
Almost done. The last thing to create is the Layer 4 Policy which will tie all the above to work together. The Layer 4 Policy is also known as the virtual IP, or VIP. The L4P will be the address that clients ultimately connect to access your application and, depending on your network configuration, it can be a public or private IP address. To create your Layer 4 Policy, follow the steps below:
AppDirector –> Layer 4 Redirection –> Layer 4 Policies
1. L4 Policy Name: Descriptive name for the policy
2. Virtual IP: IP address for the policy
3. L4 Port: Port the L4P should listen on – Enter 443
4. Application: Choose the application that L4P is used for – Select HTTPS
5. Farm Name: Choose the farm created above. This tells the AppDirector what servers to load balance the traffic to when a client lands on the L4P.
6. SSL Policy: Choose the SSL Policy created above.
*Click Set to create the new policy. Make sure that you create/modify an A record in DNS to point the URL to the new L4P IP address. You should now be able to browse to the URL and access your application.
6. Setup HTTP –> HTTPS Redirection using Layer 7 Policy
If you went through the trouble of setting up SSL on your application, chances are you want to make sure clients are using it without error. With our configuration above, users that do not specifically enter https:// for the URL, and try to access the site over HTTP, will be presented with an error because our L4P is listening ONLY on 443, not 80. To provide a smooth transition between the two, forcing users to HTTPS and provide a better end user experience, we can automatically redirect request for HTTP to use HTTPS. This is done by utilizing a Layer 7 Policy and attaching it to a new Layer 4 Policy listening on the same IP as above. We’ll first create the Layer 7 method, or what the AppDirector is looking for, and then the Layer 7 Policy, or what you want the AppDirector to do, and finally the second Layer 4 Policy. Follow the steps below to configure HTTP to HTTPS redirection:
AppDirector –> Layer 7 Farm Selection –> Methods
The Layer 7 Method is, essentially, what you want the AppDirector to watch for. It can look for a URL, such as www.mysite.com, specific values in a header, and more. Personally, if a client lands on this Layer 4 policy’s address, they are trying to get to a specific application. Therefore, I simply watch for all traffic hitting this VIP, which can be defined as a regular expression with a value of “.” or EXP=.|.
1. Method Name: Descriptive name for new method.
2. Method Type: For this example, we’ll choose Regular Expression
3: Arguments: Click the box to bring up the Arguments window. Type “.” (without the quotes) and click set. You’ll see EXP=.| entered in the Arguments field now.
*Click Set to create the new Layer 7 Method. This new method will look for all traffic.
AppDirector –> Layer 7 Farm Selection –> Policies
The Layer 7 Policy defines what you want the AppDirector to do with the traffic defined by the Layer 7 Method. You can point traffic to a different farm or redirect the client to a new URL if desired. We will redirect the user using the “HTTPS Redirect to” field as show below:
1. Policy Name: Descriptive Name for Policy
2. First Method: Choose the Layer 7 Method created in the above step.
3. Arguments: Click the box to bring up the Arguments window. In the “HTTPS Redirect to” field, type the URL for your application (ie. www.mysite.com — don’t include https://). Choose the appropriate HTTP redirection code. Moved Permanently = 301, Moved Temporarily = 302.
*Click Set to create the new Layer 7 Policy.
AppDirector –> Layer 4 Traffic Redirection –> Polices
The secondary Layer 4 Policy will listen on port 80 and redirect clients to use 443 utilizing the Layer 7 Policy we created above.
1. L4 Policy Name: Descriptive name for the policy
2. Virtual IP: IP address for the policy – Use same address as above
3. L4 Port: Port the L4P should listen on – enter 80
4. Application: Choose the application that L4P is used for – Select HTTP
5. L7 Policy Name: Choose the Layer 7 Policy created above.