Radware AppDirector – Configuration: Basic Application

Home

VMware

Microsoft

Radware

About

Featured Radware AppDirector - Dispatch Methods Apr 21, 2014 | All , Radware |

Featured Radware AppDirector - Reset to Factory Defaults Apr 21, 2014 | All , Radware |

Recent Radware AppDirector - DNS Persistency by Bryan Krausen | Apr 21, 2014 | 2 Radware AppDirector - Authentication using RADIUS by Bryan Krausen | Apr 21, 2014 | 0 Importing/Exporting AppDirector Configurations by Bryan Krausen | Apr 21, 2014 | 0

Radware AppDirector - DNS Persistency by Bryan Krausen | Apr 21, 2014 | 2

Radware AppDirector - Authentication using RADIUS by Bryan Krausen | Apr 21, 2014 | 0

Importing/Exporting AppDirector Configurations by Bryan Krausen | Apr 21, 2014 | 0

Select Page

Posted by Bryan Krausen | Apr 21, 2014 | All , Radware | 12 |

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.

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.

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 .

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.

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.

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.

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.

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.

Rate:

Bryan Krausen is currently working as a Sr. Solutions Architect with experience in a vast number of platforms, specializing in AWS and HashiCorp tools.

February 25, 2015

August 17, 2016

November 26, 2014

February 22, 2016

ajay on July 9, 2013 at 5:18 pm Very helpful ..study material ..for beginner…!! Thank you. Reply

Very helpful ..study material ..for beginner…!! Thank you.

Keshava Mp on 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! Reply btkrausen on July 25, 2013 at 8:07 pm Thanks. Please let me know if you have suggestions for posts that you’d like to see. I have about 3 in queue right now 🙂 Reply

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!

btkrausen on July 25, 2013 at 8:07 pm Thanks. Please let me know if you have suggestions for posts that you’d like to see. I have about 3 in queue right now 🙂 Reply

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

Anonymous on August 27, 2013 at 6:38 pm Too Good Reply

Too Good

RSR on February 22, 2014 at 7:24 pm Very Nice….Waiting for 2 post 1)VRRP clustering 2)radeware LLB configuration steps.. awaiting for ur reply.. Thanks… siva Reply btkrausen on February 24, 2014 at 8:49 pm Siva, unforunately I’ve moved on to another position where I don’t manage Radware appliances any longer, therefore it’s hard for me to get screenshots and such. I can tell you, however, that VRRP setup is under the Redundancy menu. Generally both AppDirectors have a IP with a VRRP address that “floats” between the devices. Create the Virtual Router IP under this menu. Also, be sure to add the VRRP IP to the Layer 4 Policies as a “virtual IP address”. Reply

Very Nice….Waiting for 2 post 1)VRRP clustering 2)radeware LLB configuration steps..

awaiting for ur reply.. Thanks… siva

btkrausen on February 24, 2014 at 8:49 pm Siva, unforunately I’ve moved on to another position where I don’t manage Radware appliances any longer, therefore it’s hard for me to get screenshots and such. I can tell you, however, that VRRP setup is under the Redundancy menu. Generally both AppDirectors have a IP with a VRRP address that “floats” between the devices. Create the Virtual Router IP under this menu. Also, be sure to add the VRRP IP to the Layer 4 Policies as a “virtual IP address”. Reply

Siva, unforunately I’ve moved on to another position where I don’t manage Radware appliances any longer, therefore it’s hard for me to get screenshots and such.

I can tell you, however, that VRRP setup is under the Redundancy menu. Generally both AppDirectors have a IP with a VRRP address that “floats” between the devices. Create the Virtual Router IP under this menu. Also, be sure to add the VRRP IP to the Layer 4 Policies as a “virtual IP address”.

Michal on May 17, 2014 at 7:04 am Hi Do You know if there is any literature (study materials, books etc.) available for this platform? Reply Bryan Krausen on May 17, 2014 at 5:05 pm Not really much out there which was one of the main reasons I started posting information regarding Radware configuration. The only information I had was the official documentation and a book from a Radware class I attended. Reply

Hi Do You know if there is any literature (study materials, books etc.) available for this platform?

Bryan Krausen on May 17, 2014 at 5:05 pm Not really much out there which was one of the main reasons I started posting information regarding Radware configuration. The only information I had was the official documentation and a book from a Radware class I attended. Reply

Not really much out there which was one of the main reasons I started posting information regarding Radware configuration. The only information I had was the official documentation and a book from a Radware class I attended.

Michal on May 17, 2014 at 7:05 am Hi Do You know is there any study materials available for this platform? Reply

Do You know is there any study materials available for this platform?

Manoj on July 11, 2014 at 3:11 am Thank you!!! I have configured Web server to listen on port-81 and VIP port on 80. but unfortunately I’m unable to ping or telnet to VIP address. Kindly suggest. Do i need to do any port re-direction? Thanks in advance. Reply Bryan Krausen on July 11, 2014 at 9:33 am You should be able to Telnet without issue to the VIP on port 80. As long as the farm was setup with the web server listening on port 81 it should do the port redirection for you. If you are using SSL certificates, don’t forget to use 81 on the policy rather than 80. As for pinging a VIP, you’ll need to add a second Layer 4 Policy but select ICMP rather than TCP as the protocol. Reply

Thank you!!!

I have configured Web server to listen on port-81 and VIP port on 80. but unfortunately I’m unable to ping or telnet to VIP address. Kindly suggest.

Do i need to do any port re-direction?

Thanks in advance.

Bryan Krausen on July 11, 2014 at 9:33 am You should be able to Telnet without issue to the VIP on port 80. As long as the farm was setup with the web server listening on port 81 it should do the port redirection for you. If you are using SSL certificates, don’t forget to use 81 on the policy rather than 80. As for pinging a VIP, you’ll need to add a second Layer 4 Policy but select ICMP rather than TCP as the protocol. Reply

You should be able to Telnet without issue to the VIP on port 80. As long as the farm was setup with the web server listening on port 81 it should do the port redirection for you. If you are using SSL certificates, don’t forget to use 81 on the policy rather than 80.

As for pinging a VIP, you’ll need to add a second Layer 4 Policy but select ICMP rather than TCP as the protocol.

BestOlive on October 15, 2018 at 10:42 pm I see you don’t monetize your site, don’t waste your traffic, you can earn extra cash every month. You can use the best adsense alternative for any type of website (they approve all websites), for more info simply search in gooogle: boorfe’s tips monetize your website Reply

I see you don’t monetize your site, don’t waste your traffic, you can earn extra cash every month. You can use the best adsense alternative for any type of website (they approve all websites), for more info simply search in gooogle: boorfe’s tips monetize your website

Your email address will not be published.

COMMENT

Name

Website

Integrating HashiCorp Consul with Amazon Route 53 Resolver

Designing High Availability for HashiCorp Vault in AWS

AWS Certified Advanced Networking Prep – Route 53

AWS Certified Advanced Networking Prep – VPC

AWS Certified Advanced Networking Prep – VPN