An application profile allows you to specify HTTP/HTTPS redirection, which always redirects traffic regardless of the request URLs. You also have the flexibility to specify the conditions in which HTTP/HTTPS traffic should be redirected.

move the login URL only to HTTPS. 
acl clear dst_port 80
acl secure dst_port 8080
acl login_page url_beg /login 
acl logout url_beg /logout 
acl uid_given url_reg /login?userid=[^&]+ 
acl cookie_set hdr_sub(cookie) SEEN=1
redirect prefix https://mysite.com set-cookie SEEN=1 if !cookie_set
redirect prefix https://mysite.com if login_page !secure
redirect prefix http://mysite.com drop-query if login_page !uid_given
redirect location http://mysite.com/ if !login_page secure
 redirect location / clear-cookie USERID= if logout

You can create an application rule to direct requests to a specific load balancer pool according to domain name. The following rule direct requests to foo.com to pool_1, and requests to bar.com to pool_2.

acl is_foo hdr_dom(host) -i foo
  acl is_bar hdr_dom(host) -i bar
  use_backend pool_1 if is_foo
  use_backend pool_2  if is_bar

In the following sample scenario, the load balancer balances a new user to the less loaded server and resumes a broken session. The NSX Edge internal interface IP address for this scenario is 10.0.0.18, internal interface IP address is 192.168.1.1, and the virtual servers are 192.168.1.100, 192.168.1.101, and 192.168.1.102.

1

Create a application profile for TCP traffic with MSRDP persistence.

2

Create a TCP health monitor (tcp_monitor).

3

Create a pool (named rdp-pool) with 192.168.1.100:3389, 192.168.1.101:3389 and 192.168.1.102:3389 as members.

4

Associate tcp_monitor to rdp-pool.

5

Create the following application rule.

tcp-request content track-sc1 rdp_cookie(mstshash) table rdp-pool
tcp-request content track-sc2 src table ipv4_ip_table
 
#   each single IP can have up to 2 connections on the VDI infrastructure
tcp-request content reject if { sc2_conn_cur ge 2 }

#   each single IP can try up to 5 connections in a single minute
tcp-request content reject if { sc2_conn_rate ge 10 }

# Each user is supposed to get a single active connection at a time, block the second one
tcp-request content reject if { sc1_conn_cur ge 2 }

# if a user tried to get connected at least 10 times over the last minute, 
# it could be a brute force
tcp-request content reject if { sc1_conn_rate ge 10 }

6

Create a virtual server (named rdp-vs).

7

Associate the application profile to this virtual server and add the application rule created in step 4.

The newly applied application rule on the virtual server protects the RDP servers.

By default, NSX load balancer supports basic logging. You can create an application rule as follows to view more detailed logging messages for troubleshooting.

 # log the name of the virtual server
 capture request  header Host len 32

 # log the amount of data uploaded during a POST
 capture request  header Content-Length len 10
# log the beginning of the referrer
capture request  header Referer len 20

# server name (useful for outgoing proxies only)
capture response header Server len 20

# logging the content-length is useful with "option logasap"
capture response header Content-Length len 10

# log the expected cache behaviour on the response
capture response header Cache-Control len 8

# the Via header will report the next proxy's name
 capture response header Via len 20

# log the URL location during a redirection
capture response header Location len 20

After you associate the application rule to the virtual server, logs include detailed messages such as the following example.

2013-04-25T09:18:17+00:00 edge-187 loadbalancer[18498]: [org1]: 10.117.7.117 - - [25/Apr/2013:09:18:16 +0000] "GET /favicon.ico HTTP/1.1" 404 1440 "" "" 51656 856 "vip-http-complete" 
"pool-http-complete" "m2" 145 0 1 26 172 --NI 1 1 0 0 0 0 0 "" "" "10.117.35.187" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 
(KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31" "Apache/2.2.15 (Linux" ""

2013-04-25T09:18:17+00:00 edge-187 loadbalancer[18498]: [org1]: 10.117.7.117 - - [25/Apr/2013:09:18:16 +0000] "GET /favicon.ico HTTP/1.1" 404 1440 "" "" 51657 856 "vip-http-complete" 
"pool-http-complete" "m2" 412 0 0 2 414 --NI 0 0 0 0 0 0 0 "" "" "10.117.35.187" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 
(KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31" "Apache/2.2.15 (Linux" ""

To troubleshoot the HTTPS traffic, you may need to add more rules. Most web application use 301/302 responses with a location header to redirect the client to a page (most of the time after a login or a POST call) and also require an application cookie. So your application server may have difficulty in getting to know client connection information and may not be able to provide the correct responses: it may even stop the application from working.

To allow the web application to support SSL offloading, add the following rule.

# See clearly in the log if the application is setting up response for HTTP or HTTPS
capture response header Location   len 32
capture response header Set-Cookie len 32

# Provde client side connection info to application server over HTTP header
http-request set-header X-Forwarded-Proto https if  { ssl_fc }
http-request set-header X-Forwarded-Proto http  if !{ ssl_

The load balancer inserts the following header when the connection is made over SSL.

X-Forwarded-Proto: https

The load balancer inserts the following header when the connection is made over HTTP.

X-Forwarded-Proto: http

You can block requests that contain specific keywords in the URL. The following sample rule checks if the request starts with /private or /finance and blocks the requests that have those terms.

acl block_url_list path_beg -i /private /finance
block if block_url_list

You can redirect a client request that does not have a cookie to get an authentication. The following sample rule checks if the HTTP request is authentic and has cookies in the header. If the request does not have cookies then the rule redirects the request to / authent.php for authentication.

acl authent_url url /authent.php
acl cookie_present hdr_sub(cookie) cookie1=
redirect prefix /authent.php if !authent_url !cookie_present

You can redirect the client request / to a default page. The following sample rule checks if the HTTP request is / and redirects the request to a default login page.

acl default_url url /
redirect prefix /login.php if default_url

When the primary pool is down, you can use a maintenance server pool and redirect the URL to the maintenance Web site.

redirect location http://maitenance.xyz.com/maintenance.htm

When you do not want to close the server session after each request, you can keep the server session alive and secure with the NTLM protocol.

no option http-server-close

You can delete the existing response server header and replace it with another server. The following sample rule deletes the server header and replaces it with the NGINX Web server that can act as a reverse proxy server for HTTP, HTTPS, SMTP, POP3, and IMAP protocols, HTTP cache, and a load balancer.

rspidel Server
rspadd Server:\ nginx

You can rewrite the Location header from HTTP to HTTPS. The following sample rule identifies the Location header and replaces the HTTP with HTTP.

rspirep ^Location:\ http://(.*)  Location:\ https://\1

You can redirect requests with a specific host to defined pools. The following sample rule checks for the request for specific hosts app1.xyz.com, app2.xyz.com, and host_any_app3 and redirects these requests respectively to defined pools, pool_app1, or pool_app2, and pool_app3. All other requests are redirected to existing pools defined in the Virtual Server.

acl host_app1 hdr(Host) -i app1.xyz.com
acl host_app2 hdr(Host) -i app2.xyz.com
acl host_any_app3 hdr_beg(host) -i app3

use_backend pool_app1 if host_app1
use_backend pool_app2 if host_app2
use_backend pool_app3 if host_any_app3

You can redirect requests with URL keywords to specific pools. The following sample rule checks if the request starts with /private or /finance and redirects these requests to defined pools, pool_private or pool_finance. All other requests are redirected to existing pools defined in the Virtual Server.

acl site_private path_beg -i /private
acl site_finance path_beg -i /finance
use_backend pool_private if site_private
use_backend pool_finance if site_finance

If your servers in the primary pool are down, you can redirect users to use the servers in the secondary pool. The following sample rule checks in the pool_production is down and transfers users to pool_sorry_server.

acl pool_production_down nbsrv(pool_production) eq 0
use_backend pool_sorry_server if pool_production_down

You can block client IP addresses from accessing your server. The following sample rule blocks the defined IP address and rests the connection if the IP address is not in the whitelist.

acl whitelist src 10.10.10.0 20.20.20.0
tcp-request connection reject if !whitelist

By default, sslv3 and tlsv1 are disabled service monitor extensions. You can enable them using the following application rule.

sslv3 enable
tlsv1 enable

Session timeout is the maximum connection inactivity time on the client side. The inactivity timeout applies when the client is expected to acknowledge or send data. In the HTTP mode, this timeout is particularly important to consider during the first phase, when the client sends the request, and during the response while the client is reading the data sent by the server. The default timeout value is five minutes.

The following sample rule sets the timeout period to 100 seconds.

timeout client 100s

Time can be set as an integer with milliseconds, seconds, minutes, hour, or days.