2.1.2. Lab 2: Leverage LTM Policies To Direct SSL Terminated Applications To Secondary Virtual Servers

What is SNI? Introduced in TLS 1.0 as a TLS extension, Server Name Indication (SNI) allows the client to send the hostname they are trying to connect to in the SSL handshake. This allows the Application Delivery Controllers (ADC) such as the BIG-IP and the Application servers to identify the appropriate application the client is trying to connect to. From this information, the ADC can respond with the proper SSL certificate to the client allowing the ADC to provide SSL enabled services for multiple applications from a single IP address.

LTM policies are another way to programatically modify traffic as it is flowing through the data plane of the BIG-IP. This functionality can also be accomplished with F5 iRules. The advantage this has over iRules is that LTM policies can be modified and appended to the existing configuration without replacing the entire application configuration. This lends itself to being updated through the CLI or via the REST API easily.

If you make a single change to an iRule, the entire iRule needs to be re-uploaded and applied.

The LTM policy is what directs application traffic to flow from the external virtual server to the internal virtual servers based on the Layer 7 request. In this case, since we are using SNI to terminate multiple applications (mysite,yoursite,theirsite, api, downloads) we need to be able to direct that traffic to the appropriate application pools. Some can even come back to the same application pool.

Whether it is based on the hostname or the URI path, the request can be forwarded to a different virtual server or an application pool of servers.

2.1.2.1. Create the LTM Policies

Note

As shown in this diagram, there is an external VIP and internal VIPs. The external VIP has the local traffic policies on it.

ltp-diagram

Navigation: Local Traffic > Policies : Policy List > Policy List Page, then click Create

Policy Name HTTPS_Virtual_Targeting_PolicyL7
Strategy Execute *best* matching rule using the *best-match* strategy

Navigation: Click Create Policy

image11

Navigation: Local Traffic > Policies : Policy List > Draft Policies > /Common/HTTPS_Virtual_Targeting_PolicyL7

image12

Navigation: Click create to create some rules.

You will need to create the following rules within your policy:

Rule Name Rule Logic      
www.mysite.com HTTP Host Host is www.mysite.com
  Forward Traffic Virtual Server   int_vip_www.mysite.com_1.1.1.1
www.yoursite.com HTTP Host Host is www.yoursite.com
  Forward Traffic Virtual Server   int_vip_www.yoursite.com_3.3.3.3
www.theirsite.com HTTP Host Host is www.theirsite.com
  Forward Traffic Virtual Server   int_vip_www.theirsite.com_2.2.2.2
www.mysite.com-api HTTP Host host is www.mysite.com
  HTTP URI path begins with /api
  Forward Traffic Virtual Server   int_vip_www.mysite.com-api_1.1.1.2
  Replace http uri path with /
www.mysite.com-downloads HTTP Host host is www.mysite.com
  HTTP URI path begins with /downloads
  Forward Traffic Virtual Server   int_vip_www.mysite.com-downloads_1.1.1.3

Navigation: Remember to click Add after adding the matching string

image13

Navigation: Click Save

Additional Example for /api. The replacement line is required to strip the path from the request for the site to work.

image14

Complete the additional policies according to the list above.

Once complete, you must save a Draft, then publish the policy.

Navigation: Local Traffic > Policies: Policy List > /Common/HTTPS_Virtual_Targeting_PolicyL7

Navigation: Save Draft Navigation: Click Publish

image15

2.1.2.2. Apply The Policy To The External Virtual Server

Navigation: Local Traffic > Virtual Servers : Virtual Server List

image16

Navigation: Click the EXT_VIP_10.10.90.30

image17

Navigation: Click the Resources Tab

image18

Navigation: Under Policies Click Manage

image19

Navigation: Select the HTTPS_Virtual_Targeting_PolicyL7

image20

Navigation: Click the Double Arrow to move the policy into the left-hand column and click Finished.

image21

The result should look like the screenshot below.

image22

Attention

When you first set up the Virtual Servers, accessing the sites didn’t work very well because the policies were not setup. Now try accessing all the VS you created from Chrome. You can use the bookmarks for easy access. If you manually type in the sites in the address bar, use https://** since you enabled encyrption when you created the virtual server.

2.1.2.3. Validate Lab 2 Configuration

Validation: This lab is using self-signed certificates. You can either open a web browser on the test client or run CURL from the CLI to validate your configuration.

You will need to accept the certificate to proceed to the application sites

With curl you need to use the -k option to ignore certificate validation

Note

You may have to edit the hosts file on your Win7 Client to add:

10.10.99.30 www.mysite.com

10.10.99.30 www.yoursite.com

10.10.99.30 www.theirsite.com

image23

From a terminal window (use Cygwin on Win7 Client Desktop, or go to the c:\curl directory from windows command shell ). Curl will let us do some of the additional testing in later sections.

curl -k https://10.10.99.30 -H Host:www.mysite.com

<H1> MYSITE.COM </H1>

curl -k https://10.10.99.30 -H Host:www.theirsite.com

<H1> THEIRSITE.COM </H1>

curl -k https://10.10.99.30 -H Host:www.yoursite.com

<H1> YOURSITE.COM </H1>

curl -k https://10.10.99.30/api -H Host:www.mysite.com

{
   "web-app": {
     "servlet": [
        {
           "servlet-name": "cofaxCDS",
           "servlet-class": "org.cofax.cds.CDSServlet"
        }
 ...

Note

A bunch of nonsense JSON should be returned.

curl -k https://10.10.99.30/downloads/ -H 'Host:www.mysite.com'

<html>
<head>
  <title>Index of /downloads</title>
</head>
<body>

Note

This completes Module 1 - Lab 2

Previous Next