Procedure
1 Log in to the vSphere Web Client.
2 Click Networking & Security and then click NSX Edges. 3 Double-click an NSX Edge.
4 Click Manage and then click the Load Balancer tab.
5 In the left navigation panel, click Application Rules and click the Add icon. 6 Type the name and script for the rule.
For information on the application rule syntax, see
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html. 7 Click OK.
Application Rule Examples
HTTP/HTTPS redirection based on condition
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
Routing by domain name
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
Microsoft RDP load balancing and protection
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.
Advanced Logging
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
# 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