Skip to navigation

Skip to main content

Skip to primary sidebar

Skip to secondary sidebar

Skip to footer

VirtuallyMyOwn
Thoughts, Ideas, & Solutions

Home

About

Twitter
Restoring DFSR After Restoring a VM from Backup or Snapshot
Configuring Health Checks using Radware AppDirector

Radware AppDirector Configuration:

Basic Application
Jan 23

Posted by btkrausen

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, its 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 its 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, its 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, youll 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 servers 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 its 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.
http://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, its 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. Well 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 http://www.mysite.com, specific values in a header, and more. Personally, if a
client lands on this Layer 4 policys 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, well choose Regular Expression

3: Arguments: Click the box to bring up the Arguments window. Type . (without the quotes)
and click set. Youll 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. http://www.mysite.com dont 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.

 About these ads
Ads not by this site

Share this:

Twitter

Facebook

Like this:
Posted on January 23, 2013, in Radware and tagged AppDirector, HTTP to HTTPS redirection,
radware, server load balancing, web farm. Bookmark the permalink. 4 Comments.

Restoring DFSR After Restoring a VM from Backup or Snapshot

Configuring Health Checks using Radware AppDirector

Leave a Comment

Comments (4)

1. ajay | July 9, 2013 at 5:18 pm

Very helpful ..study material ..for beginner!!

Thank you.

2. Keshava Mp | July 24, 2013 at 5:15 pm

Thank you very much. It really fills a conceptual gap in the scarce world of Radware
documentation.

I have one suggestion: Fill in your own example names so that the flow of thought is
even more clearer. (There is no phrase like give a descriptive name or Give whatever
name you gave above)

Waiting to see more such posts!

Cheers!

o btkrausen | July 25, 2013 at 8:07 pm

Thanks. Please let me know if you have suggestions for posts that youd like to
see. I have about 3 in queue right now

3. Anonymous | August 27, 2013 at 6:38 pm

Too Good

Leave a Reply
 Follow me on Twitter

o AWESOME! Won a Jawbone Jambox from filling out @VMworld surveys and it
came in today. Thanks so much :) #INeverWinAnything 3 days ago

Search for:

Recent Posts

o Radware AppDirector DNS Persistency

o Radware AppDirector Authentication using RADIUS

o Importing/Exporting AppDirector Configurations

o Configuring Health Checks using Radware AppDirector

o Radware AppDirector Configuration: Basic Application

Categories

o Microsoft (2)

o Radware (6)

o VMware (1)

Meta

o Register

o Log in

o Entries RSS
 o Comments RSS

o WordPress.com

Ads not by this site

Blog at WordPress.com. The Mystique Theme.

Follow

Follow VirtuallyMyOwn

Get every new post delivered to your Inbox.

Powered by WordPress.com