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 also resumes a broken session. The NSX Edge internal interface IP for this scenario is 10.0.0.18, internal interface IP 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.. Associate tcp_monitor to this pool.

4

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 }

5

Create a virtual server (named rdp-vs). Associate the application profile to this virtual server and add the application rule created in step 4.

By default, NSX load balancer supports basical 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