Application Profile

Overview

Application profiles determine the behavior of virtual services, based on application type.

The application profile types and their options are described in the following sections:

HTTP Profile
DNS Profile
Layer 4 Profile
SSL Profile
SYSLOG Profile
SIP Profile

Application Profile Tab

Navigate to Templates > Profiles > Applications to open the Profiles tab in the Application window, which includes the following functions:

Search — Searches against the name of the profile.
Create — Opens the Create Application Profile popup.
Edit — Opens the Edit Application Profile popup.
Delete — Removes an application profile (click its check box) if it is not currently assigned to a virtual service.

Note: If the profile is still associated with any virtual services, the profile cannot be removed. In this case, an error message lists the virtual service that still is referencing the application profile. You cannot delete any of the system-standard profiles (as illustrated below).

The following screenshot provides the following information for each application profile:

Name — Specify the name of the profile.
Type — Select the type of application profile. The following are the options:
- L4 SSL/TLS — Catch-all for any virtual service that is SSL-encrypted and not using an application-specific profile.
- L4 — Catch-all for any virtual service that is not using an application-specific profile.
- DNS — Default for processing DNS traffic.
- SYSLOG — Default for processing Syslog traffic.
- HTTP — Default for processing Layer 7 HTTP traffic.
- SIP — Default for processing SIP traffic.
Note: NSX Advanced Load Balancer ships with the templates shown in the above window with the exception of a System-SIP template. For SIP to appear in the fourth row above, you need to create the template beforehand.

Creating and Editing an Application Profile

The Create Application Profile and Edit Application Profile screens share the same interface regardless of the application profile chosen.

The initial settings for a new profile are similar regardless of the type of profile chosen:

Name — Specify a unique name for the profile.
Description — Specify an optional description for the profile.
Type — Click the appropriate button to select the application for this profile. Select L4 for none.

HTTP Profile Tab

The HTTP application profile (which is the default) allows NSX Advanced Load Balancer to be a proxy for any HTTP traffic. HTTP-specific functionality such as redirects, content switching, or rewriting server responses to client requests may be applied to a virtual service. The settings apply to all HTTP services that are associated with the HTTP profile. You can also attach HTTP-specific policies or DataScripts directly to a virtual service.

The HTTP profile contains these tabs:

General
Security
Compression
Caching
DDoS

General Tab

The General tab of HTTP Application Profile window contains HTTP basic settings:

Connection Multiplex — This option controls the behavior of HTTP 1.0 and 1.1 request switching and server TCP connection reuse. This allows NSX Advanced Load Balancer to reduce the number of open connections maintained by servers and distribute requests across idle servers, thus reducing server overloading and improving performance for end-users. The exact reduction of connections to servers will depend on the client connectivity, the HTTP version, and how frequently request/responses are utilizing the connection. It is important to understand that connection refers to a TCP connection, whereas request refers to an HTTP request and subsequent response. HTTP 1.0 and 1.1 allow only a single request/response to go over an open TCP connection at a time. Many browsers attempt to mitigate this bottleneck by opening around six concurrent TCP connections to the destination web site. Refer Multiplex plus Persistence in the below section.
X-Forwarded-For — This option allows NSX Advanced Load Balancer will insert an X-Forwarded-For (XFF) header into the HTTP request headers when the request is passed to the server. The XFF header value contains the original client source IP address. Web servers can use this header for logging client interaction instead of using the layer 3 IP address, which will incorrectly reflect the Service Engine’s source NAT address. When you enable this option, the XFF Alternate Name field appears, which allows the XFF header insertion to use a custom HTTP header name. If the XFF header or the custom name supplied already exists in the client request, all instances of that header will be removed. To add the header without removing pre-existing instances of it, use an HTTP request policy.
Preserve Client IP Address — This option causes the NSX Advanced Load Balancer SE to use the client-IP rather than its own as the source-IP for load-balanced connections from the SE to back-end application servers. Ensure that you enable IP Routing in the SE group before enabling this option. Preserve client IP Address is mutually exclusive with source translating the virtual services. You cannot use connection multiplexing from HTTP(s) application profile with Preserve client IP.
WebSockets Proxy — This option allows the virtual service to accept a client’s upgrade header request. If the server is listening for WebSockets, the connection between the client and server will be upgraded. WebSocket is a full-duplex TCP protocol. The connection will initially start over HTTP, but once successfully upgraded, all HTTP parsing by NSX Advanced Load Balancer will cease and the connection will be treated as a normal TCP connection.
Proxy Expect Header — This option, if unchecked, allows full duplex communication between client and server via the virtual service.
Save — Select another tab from the top menu to continue editing or click on Save to return to the Application Profiles tab. Refer to Preserve Client IP article for more details.

Multiplex plus Persistence

Multiplexing behavior changes with server persistence enabled:

Multiplex enabled, Persistence disabled — Client connections and their requests are decoupled from the server side of the Service Engine. Requests are load-balanced across the servers in the pool using either new or pre-existing connections to those servers. The connections to the servers may be shared by requests from any clients.
Multiplex enabled, Persistence enabled — Client connections and their requests are sent to a single server. These requests may share connections with other clients who are persisted to the same server. HTTP requests are not load balanced.
Multiplex disabled, Persistence enabled — NSX Advanced Load Balancer opens a new TCP connection to the server for each connection received from the client. Connections are not shared with other clients. All requests received through all connections from the same client are sent to one server. HTTP client browsers may open many concurrent connections, and the number of client connections will be the same as the number of server connections.
Multiplex disabled, Persistence disabled — Connections between the client and server are one-to-one. Requests remain on the same connection they began on. Multiple connections from the same client may be distributed among the available servers.

Security Tab

The Security tab of the HTTP application profile controls the security settings for HTTP applications that are associated with the profile.

Security Information

The HTTP security settings affect how a virtual service should handle HTTPS. If a virtual service is configured only for HTTP, any HTTPS settings in this section will not apply. Only if the virtual service is configured for HTTPS, or HTTP and HTTPS, the settings will take effect.

More granular settings also may be configured using policies or DataScripts.

Reset connection on HTTP request for SSL port — This option resets the TCP connection when a plain HTTP request is sent to an SSL port. If you uncheck this field, and if an HTTP request is sent on an SSL port, then NSX Advanced Load Balancer sends a 400 Bad Request to the user.
SSL Everywhere — This option enables all of the following options, which together provide the recommended security for HTTPS traffic.
HTTP-to-HTTPS Redirect — This option will automatically redirect clients from the insecure to the secure port for a single virtual service configured with both an HTTP service port (SSL disabled) and an HTTPS service port (SSL enabled). For instance, clients who type www.avinetworks.com into their browser will automatically be redirected to https://www.avinetworks.com. If the virtual service does not have both an HTTP and HTTPS service port configured, this feature will not activate. For two virtual services (one with HTTP and another on the same IP address listening to HTTPS), an HTTP request policy must be created to manually redirect the protocol and port.
Secure Cookies — When NSX Advanced Load Balancer is serving as an SSL proxy for the backend servers in the virtual service’s pool, NSX Advanced Load Balancer communicates with the client over SSL. However, if NSX Advanced Load Balancer communicates with the backend servers over HTTP (not over SSL), the servers will incorrectly return responses as HTTP. As a result, cookies that should be marked as secure will not be so marked. Enabling secure cookies will mark any server cookies with the secure flag, which tells clients to send only this cookie to the virtual service over HTTPS. This feature will only activate when applied to a virtual service with SSL/TLS termination enabled.
HTTP Strict Transport Security (HSTS) — This option uses a header to inform client browsers that this site should be accessed only over SSL/TLS. The HSTS header is sent in all HTTP responses, including error responses. This feature mitigates man-in-the-middle attacks that can force a client’s secure SSL/TLS session to connect through insecure HTTP. HSTS has a Duration setting that tells clients the SSL/TLS preference should remain in effect for the specified number of days. You can enable the insertion of the includeSubdomains directive in the HSTS header. Doing so signals the user agent that the HSTS policy applies to this HSTS host as well as any subdomains of the host’s domain name. This setting will activate only on a virtual service that is configured to terminate SSL/TLS.

Note: If a virtual service is set temporarily to support SSL/TLS and HSTS has been set, it cannot gracefully be downgraded back to HTTP. Client browsers will refuse to accept the site over HTTP. When HSTS is in effect, clients will not accept a self-signed certificate.
HTTP-only Cookies — This option marks server cookies as HTTP-only, which means the cookies cannot be viewed or used by third parties, including Javascript or other web sites. This feature will activate for any HTTP or terminated HTTPS virtual service.
Rewrite Server Redirects to HTTPS — When a virtual service terminates client SSL/TLS and then passes requests to the server as HTTP, many servers assume that the connection to the client is HTTP. Absolute redirects generated by the server may therefore include the protocol, such as http://www.avinetworks.com. If the server returns a redirect with HTTP in the location header, this feature will rewrite it to HTTPS. Also, if the server returns a redirect for its own IP address, this will be rewritten to the hostname requested by the client. If the server returns redirects for host names other than what the client requested, they will not be altered.

Note: Consider creating an HTTP response policy if greater granularity is required when rewriting redirects. This feature will activate only if the virtual service has both HTTP and HTTPS service ports configured.
X-Forwarded-Proto — This option, if enabled, makes NSX Advanced Load Balancer insert the X-Forwarded-Proto header into HTTP requests sent to the server, which informs that server whether the client connected to NSX Advanced Load Balancer over HTTP or HTTPS. This feature activates for any HTTP or HTTPS virtual service.

Client SSL Certificate Validation

NSX Advanced Load Balancer can validate the certificates presented by clients, by checking them against a client revocation list (CRL). Further options allow passing certificate information to the server through HTTP headers.

Client Certificate Type — Enables client validation based on their SSL certificates.
- None — Disables validation of client certificates.
- Request — This setting expects clients to present a client certificate. If a client does not present a certificate, or if the certificate fails the CRL check, the client connection and requests are still forwarded to the destination server. This allows NSX Advanced Load Balancer to forward the client’s certificate to the server in an HTTP header, so that the server may make the final determination to allow or deny the client.
- Require — NSX Advanced Load Balancer requires a certificate to be presented by the client, and the certificate must pass the CRL check. The client certificate, or relevant fields, may still be passed to the server through an HTTP header.
PKI Profile — The public key infrastructure (PKI) profile contains configured Certificate Authority (CA) and the CRL. A PKI profile is not necessary if validation is set to Request, but is required if validation is set to Required.
Add HTTP Request Headers — HTTP header can be added to client’s request prior to sending the request to the server. For instance, terminate SSL and send the server information about the client’s SSL certificate.
- HTTP Header Name — Optionally, NSX Advanced Load Balancer may insert the client’s certificate, or parts of it, into a new HTTP header to be sent to the server. To insert a header, this field is used to determine the name of the header.
- HTTP Header Value — Used with HTTP Header Name field, the Value field is used to determine the portion of the client certificate to insert into the HTTP header sent to the server. Using the plus icon, additional headers may be inserted. This action may be in addition to any performed by HTTP policies or DataScripts, which could also be used to insert headers in requests sent to the destination servers.

Compression Tab

The Compression tab permits one to view or edit the application profile’s compression settings.

The compression option enables HTTP Gzip compression for responses from NSX Advanced Load Balancer to the client. Compression is an HTTP 1.1 standard for reducing the size of text-based data using the Gzip algorithm. The typical compression ratio for HTML, Javascript, CSS, and similar text content types is about 75%, meaning that a 20-KB file may be compressed to 5 KB before being sent across the internet, thus reducing the transmission time by a similar percentage.

The compression percentage achieved can be viewed using the Client Logs tab of the virtual service. This may require enabling full client logs on the virtual service’s Analytics tab to log some or all client requests. The logs will include a field showing the compression percentage with each HTTP response.

Note: It is highly recommended to enable compression in conjunction with caching, which together can dramatically reduce the CPU costs of compressing content. When both compression and caching are enabled, an object such as the index.html file will need to be compressed only one time. After an object is compressed, the compressed object is served out of the cache for subsequent requests. NSX Advanced Load Balancer does not needlessly re-compress the object for every client request. For clients that do not support compression, NSX Advanced Load Balancer also will cache an uncompressed version of the object.

You can specify compression settings as follows:

Check Enable Compression box to enable compression. You can change compression settings after enabling this feature.
Select either Auto or Custom, which enables different levels of compression for different clients. For instance, filters can be created to provide aggressive compression levels for slow mobile clients while disabling compression for fast clients from the local intranet. Auto is recommended, to dynamically tune the settings based on clients and available Service Engine CPU resources.
- Auto mode enables NSX Advanced Load Balancer to determine the optimal settings.
  
  Note: By default, the Compression Mode is Auto. The content compression depends on the client’s RTT, mentioned as follows:
  - No compression if RTT is less than 10ms.
  - Normal compression if RTT is 10 to 200ms.
  - Aggressive compression if RTT is above 200ms.
- Custom mode allows you to create custom filters that provides more granular control over the level of compression.
Compressible Content Types — Select HTTP Content Types that are eligible to be compressed from the drop-down list. The following are the options available in the drop-down list:
- System-Compressible-Content-Types
- System-Cacheable-Resource-Types
- System-Devices-Mobile
- System-Rewritable-Content-Types
  
  You can create a new string by clicking on Create String Group option from the drop-down list. The following screen appears:
You can specify the following details:
- Name — Specify the name of the string.
- Key Value Pair — Check this box to pair the string group.
- String Information
  - String — Specify the string details either by clicking Add String or you can upload the string by clicking on Upload File button.
After specifying the necessary details, click on Save.
Remove Accept Encoding Header — Check this box to remove the Accept Encoding header, which is sent by HTTP 1.1 clients to indicate that they are able to accept compressed content. Removing the header from the request prior to sending the request to the server allows NSX Advanced Load Balancer to ensure the server will not compress the responses. Only NSX Advanced Load Balancer will perform the compression.

Compression Filter

To create a custom compression filter, click on Compression Filter button.

You can specify the following details:

Filter 1 — Specify a unique name for the filter (optional).
Matching Rules — Determine if the client (via client IP or user agent string) is eligible to be compressed via the associated action. If both client IP and user agent rules are populated, then both must be true for the compression action to fire.
- Client IP Address allows you to use an IP Group to specify eligible client IP addresses. For instance, an IP Group calls Intranet that contains a list of all internal IP address ranges. Clearing the Is In button reverses this logic and any client that is not coming from an internal IP network will match the filter.
  
  Note: Client IP is subject to the option Use_True_Client_IP. Client IP might be equal to source IP from layer-3 header or equal to the fetched IP from user-defined HTTP header. For more information refer to True Client IP in L7 Security Features.
- User Agent contains matches the client’s user agent string against an eligible list contained within a string group. The user agent is a header presented by clients indicating the type of browser or device they may be using. The System-Devices-Mobile group contains a list of HTTP user agent strings for common mobile browsers.
Action — The Action section determines what will happen to clients or requests that meet the match criteria, specifically the level of HTTP compression that will be used.

The following are the options available in the drop-down list in the Compression field:
- Aggressive compression uses Gzip level 6, which will compress text content by about 80% while requiring more CPU resources from both NSX Advanced Load Balancer and the client.
- Normal compression uses Gzip level 1, which will compress text content by about 75%, which provides a good mix between compression ratio and the CPU resources consumed by both NSX Advanced Load Balancer and the client.
- None disables compression. For clients coming from very fast, high bandwidth and low latency connections, such as within the same data center, compression may actually slow down the transmission time and consume unnecessary CPU resources.
Compression Filters — The following values are displayed:
- Name
- Client IP
- User Agent
- Compression

Caching Tab

NSX Advanced Load Balancer can cache HTTP content, thereby enabling faster page load times for clients and reduced workloads for both servers and NSX Advanced Load Balancer. When a server sends a response, such as logo.jpg, NSX Advanced Load Balancer can add the object to its cache and serve it to subsequent clients that request the same object. This can reduce the number of connections and requests sent to the server.

Enabling caching and compression allows NSX Advanced Load Balancer to compress text-based objects and store both the compressed and original uncompressed versions in the cache. Subsequent requests from clients that support compression will be served from the cache and NSX Advanced Load Balancer will need not compress every object every time, which greatly reduces the compression workload.

Note: Regardless of the configured caching policy, an object can be cached only if it is eligible for caching. Some objects may not be eligible for caching.

By default, caching is disabled. Check Enable Caching box to enable caching.

The following parameters are all optional:

X-Cache — NSX Advanced Load Balancer will add an HTTP header labeled X-Cache for any response sent to the client that was served from the cache. This header is informational only, and will indicate the object was served from an intermediary cache.
Age Header — NSX Advanced Load Balancer will add a header to the content served from cache that indicates to the client the number of seconds that the object has been in an intermediate cache. For instance, if the originating server declared that the object should expire after 10 minutes and it has been in the NSX Advanced Load Balancer cache for 5 minutes, then the client will know that it should only cache the object locally for 5 more minutes.
Date Header — If a date header was not added by the server, then NSX Advanced Load Balancer will add a date header to the object served from its HTTP cache. This header indicates to the client when the object was originally sent by the server to the HTTP cache in NSX Advanced Load Balancer.
Aggressive — This indicates the caching objects can be enabled or disabled without Cache-Control headers.
Cacheable Object Size — The minimum and maximum size of an object (image, script, and so on) that can be stored in the NSX Advanced Load Balancer HTTP cache, in bytes. Most objects smaller than 100 bytes are web beacons and should not be cached despite being image objects.
Cache Expire Time — If the server sends headers indicating how long the content can be cached (such as cache control), then NSX Advanced Load Balancer will use those values. If the server does not send expiration timeouts, then NSX Advanced Load Balancer will store the object for no longer than the duration of time specified by the Cache Expire Time.
Heuristic Expire — If a response object from the server does not include the Cache-Control header but includes an If-Modified-Since header, then NSX Advanced Load Balancer will use this time to calculate the cache-control expiration, which will supersede the Cache Expire Time setting for this object.
Cache URI with Query Arguments — This option allows caching of objects whose URI includes a query argument. Disabling this option prevents caching these objects. When enabled, the request must match the URI query to be considered a hit. Below are two examples of URIs that include queries. The first example may be a legitimate use case for caching a generic search, while the second may be a unique request posing a security liability to the cache.
- www.search.com/search.asp?search=caching
- www.foo.com/index.html?loginID=User
Cacheable MIME Types — Statically defines a list of cacheable objects. This may be a string group, such as System-Cacheable-Resource-Types, or a custom comma-separated list of MIME types that NSX Advanced Load Balancer should cache. If no MIME types are listed in this field, then NSX Advanced Load Balancer will by default assume that any object is eligible for caching. You can add more string groups by clicking on Add String Group.
- Non-Cacheable MIME Types — Statically defines a list of objects that are not cacheable. This creates a blacklist that is the opposite of the cacheable list. You can add more string groups by clicking on Add String Group.
Non-Cacheable URI — This option allows configuring non-cacheable URI with match criteria.
- Criteria — Select the criteria option from the drop-down list.
The list displays the following values:
- Regex pattern matches
- Does not end with
- Ends with
- Contains
- Equals
- Does not begin with
- Does not equal
- Regex pattern does not match
- Does not contain
- Begin with
- String group — Select the string group type from the drop-down list.
The list displays the following values:
- System-Cacheable-Resource-Types
- System-Compressible-Content-Types
- System-Devices-Mobile
- System-Rewritable-Content-Types
However, you can edit the selected option.
- Match Case — Check this box if Non-Cacheable URI is case sensitive.

DDoS Tab

The Distributed Denial of Service (DDoS) section allows configuring of mitigation controls for HTTP and the underlying TCP protocols. By default, NSX Advanced Load Balancer is configured to protect itself from a number of types of attacks. For instance, if a virtual service is targeted by a SYN flood attack, NSX Advanced Load Balancer will activate SYN cookies to validate clients before opening connections. Many of the options listed below are not quite as straightforward, as bursts of data may be normal for the application. NSX Advanced Load Balancer provides a number of knobs to modify the default behavior to ensure optimal protection.

In addition to the DDoS settings described below, NSX Advanced Load Balancer also can implement connection limits to a virtual service and a pool, configured through the Advanced Properties page. Virtual services also may be configured with connection rate limits and burst limits in the Network Security Policies section. Because these settings apply on to an individual virtual service and pool, they are not configured within the profile.

HTTP Limit Settings

The first step in mitigating HTTP-based denial of service attacks is to set parameters for the transfer of headers and requests from clients. Many of these settings protect against variations of HTTP SlowLoris and SlowPOST attacks, in which a client opens a valid connection and then very slowly streams the request headers or POSTs a file. This type of attack is intended to overwhelm the server (in this case the Service Engine) by tying up buffers and connections. Clients that exceed the limits defined below will have that TCP connection reset and a log generated. This does not prevent the client from initiating a new connection and does not interrupt other connections the same client may have open.

HTTP Timeout Settings
- Client Header Timeout — Set the maximum length of time the client is allowed for successfully transmitting the complete headers of a request. The default is 10 seconds.
- HTTP Keep-alive Timeout — Set the maximum length of time an HTTP 1.0 or 1.1 connection may be idle. This affects only client-to-Vantage interaction. The NSX Advanced Load Balancer-to-server keep-alive is governed through the Connection Multiplex feature.
- Client Body Timeout — Set the maximum length of time for the client to send a message body. This usually affects only clients that are POSTing (uploading) objects. The default value of 0 disables this timeout.
- Post Accept Timeout — Once a TCP three-way handshake has successfully completed, the client has this much time to send the first byte of the request header. Once the first byte has been received, this timer is satisfied and the client header timeout (described above) kicks in.
- HTTP Size Settings
  - Client Max Body Size — Set the maximum size for the client request body. This limits the size of the client data that can be uploaded/ posted as part of single HTTP request.
  - Client Max Complete Header Size — Set the maximum size in Kbytes of all the client HTTP request headers.
  - Client Max Header Field Size — Set the maximum size in Kbytes of a single HTTP request header in the client request.
Send Keep-Alive header — Check this box to send the HTTP keep-alive header to the client.
Use App Keep-Alive Timeout — When the above parameter is checked such that keep-alive headers are sent to the client, you need to specify timeout value. If you uncheck this box, NSX Advanced Load Balancer will use the value specified in the HTTP Keep-Alive Timeout field. If you check this box, the timeout sent by the application will be honored.
Allow Header Names with Dot/Period — Check this box to allow the use of dot (.) in HTTP header names. For instance, Header.app.special: PickAppVersionX.
Enable Request Body Buffering — Check this box to request body buffering for POST requests.

Rate Limit HTTP and TCP Settings

This section controls the rate at which clients may interact with the site.

Rate Limit Connections from a Client

Threshold — The client has violated the rate limit when the defined threshold of connections, packets, or HTTP requests have occurred within the specified time period.
Time Period — The client has violated the rate limit when the defined threshold of connections, packets, or HTTP requests have occurred within the specified time period.
Action — Select the action to perform when a client has exceeded the rate limit. The options will depend on whether the limit is a TCP limit or an HTTP limit.
- Report Only — A log is generated on the virtual server log page. By default, no action is taken. However, this option may be used with an alert to generate an alert action to send a notice to a remote destination or to take action through a ControlScript.
- Drop SYN Packets — For TCP-based limits, silently discard TCP SYNs from the client. NSX Advanced Load Balancer also will generate a log. However, during high volumes of DoS traffic, repetitive logs may be skipped.
- Send TCP RST — Reset client TCP connection attempts. While more graceful than the Drop SYN Packets option, sending a TCP reset does generate extra packets for the reset, versus the Drop SYN Packets option which does not send a client response. NSX Advanced Load Balancer will also generate a log. However, during high volumes of DoS traffic, repetitive logs may be skipped.
Add Rate Limit — The following rate limits may be configured:
- Rate Limit Requests from a Client to all URLs — Rate limit all HTTP requests from any single client IP address to all URLs of the virtual service.
- Rate Limit Requests from all Clients to a URL — Rate limit all HTTP requests from all client IP addresses to any single URL.
- Rate Limit Requests from a Client to a URL — Rate limit all HTTP requests from any single client IP address to any single URL.
- Rate Limit Failed Requests from a Client to all URLs — Rate limit all requests from a client for a specified period of time once the count of failed requests from that client crosses a threshold for that period. Clients are tracked based on their IP address. Requests are deemed failed based on client or server side error status codes, consistent with how NSX Advanced Load Balancer logs and how metrics subsystems mark failed requests.
  - Rate Limit Failed Requests from all Clients to a URL — Rate limit all requests to a URI for a specified period of time once the count of failed requests to that URI crosses a threshold for that period. Requests are deemed failed based on client- or server-side error status codes, consistent with how NSX Advanced Load Balancer logs and metrics subsystems mark failed requests.
    - Rate Limit all HTTP requests that map to any custom string to all URLs of the Virtual Service — Rate limit all HTTP requests that map to any custom string.
- Rate Limit Failed Requests from a Client to a URL — Rate limit all requests from a client to a URI for a specified period of time once the count of failed requests from that client to the URI crosses a threshold for that period. Requests are deemed failed based on client- or server-side error status codes, consistent with how NSX Advanced Load Balancer logs and metrics subsystems mark failed requests.
- Rate Limit Scans from a Client to all URLs — This option automatically track clients and classify them into three groups, namely, Good, Bad, and Unknown. Clients are tracked based on their IP address. Clients are added to the Good group when the NSX Advanced Load Balancer scan detection system builds history of requests from the clients that complete successfully. Clients are added to the Unknown group when there is insufficient history about them. Clients with a history of failed requests are added to the Bad group and their requests are rate limited with stricter thresholds than the Unknown clients group. The NSX Advanced Load Balancer scan detection system automatically tunes itself so that the Good, Bad, and Unknown client-IP group members change dynamically with changes in traffic patterns through NSX Advanced Load Balancer. In other words, if a change to the website causes mass failures (such as 404 errors) for most customers, NSX Advanced Load Balancer adapts and does not mark all clients as attempting to scan the site.
- Rate Limit Scans from all clients to all URLs — Similar to the previous limit, but restricts the scanning from all clients as a single entity rather than individually. Once a limit is collectively reached by all clients, any client that sends the next failed request will be reset.
- Rate Limit HTTP Header or Cookie — Rate limit all HTTP requests from all client IP addresses that contain any single HTTP Header value.
  Note: Starting with NSX Advanced Load Balancer version 21.1.3, you can upload any type of file as a local response. It is recommended to configure a local file using the UI. To update the local file using API, encode the base64 file out of band and use the encoded format in the API.

DNS Profile Tab

A DNS application profile specifies settings dictating NSX Advanced Load Balancer’s request-response handling. By default, this profile will set the virtual service’s port number to 53, and the network protocol to UDP with per-packet parsing.

You can specify the following details:

Name — Specify the name of the application profile.
Description — Specify the description for the DNS profile.
DNS Settings
- Number of IPs returned by DNS server — Specify the number of IP addresses returned by the DNS service. Default is 1. Specify 0 to return all IP addresses. Otherwise, the valid range is 1 to 20.
- Negative TTL — Specify the TTL value (in seconds) for SOA (Start of Authority) (corresponding to a authoritative domain owned by this DNS Virtual Service) record’s minimum TTL served by the DNS Virtual Service.
- TTL — Specify the TTL value (in seconds) for records served by DNS service. The time in seconds (default = 30) a served DNS response is to be considered valid by requestors of the DNS service. Valid range is 1 to 86400 seconds.
- (Options for) Invalid DNS Query processing — Specifies whether the DNS service should drop or respond to a client when processing its request results in an error. By default, such a request is dropped without any response, or passed through to a passthrough pool, if configured. When set to respond, an appropriate response is sent to the client, for instance, NXDOMAIN response for non-existent records, empty NOERROR response for unsupported queries, and so on.
- Subnet prefix length — This length is used in concert with the DNS client subnet (ECS) option. When the incoming request does not have any ECS and the prefix length is specified, NSX Advanced Load Balancer inserts an ECS option in the request to upstream servers. Valid lengths range from 1 to 32.
- Process EDNS Extensions — This option makes the DNS service aware of the Extension mechanism for DNS (EDNS). EDNS extensions are parsed and shown in logs. For GSLB services, the EDNS subnet option can be used to influence load balancing.
- Negative TTL — Specifies the TTL value (in seconds) for SOA (Start of Authority) (corresponding to a authorative domain owned by this DNS Virtual Service).
- Respond to AAAA queries with empty response — Enable this option to have the DNS service respond to AAAA queries with an empty response when there are only IPv4 records.
- Rate Limit Connections from a Client – Limits connections made from any single client IP address to the DNS virtual service for which this profile applies. The default (=0) is interpreted as no rate limiting.
DNS Request Rate Limiter Settings
- Threshold — Specifies the maximum number of connections or requests or packets that will be processed in the time value specified in the Time Period field (legitimate values range from 10 to 2500). A higher number will result in rate limiting. Specifying a number higher than 0 makes the Time Period field mandatory.
- Time Period — The span of time, in seconds, during which NSX Advanced Load Balancer monitors for exceeded threshold. The allowed range is from 1 to 300. NSX Advanced Load Balancer calculates and takes specified action, if the inbound request rate is exceeded. This rate is the ratio of maximum number to the time span.
- Action — Choose one of three actions from the pulldown to be performed when rate limiting is required: Report Only, Drop SYN Packets, or Send TCP RST.
Advanced Settings
- Preserve Client IP Address — Click this option ON to have the client IP address pass through to the back end. This option is not compatible with connection multiplexing.
- Valid subdomains — A comma-delimited allowed list of subdomain names. Identifies the subdomains serviced by the DNS virtual service with which this profile is associated; all others will not be processed. This option’s best use is in the context of GSLB, in which the GSLB DNS’ sole purpose is to return IP addresses corresponding to the global applications being served. Valid subdomains are configured with ends-with semantics.
- Authoritative Domain Names — A comma-delimited set of domain names for which the GSLB DNS’ SEs can provide authoritative translation of FQDNs to IP addresses. Queries for FQDNs that are subdomains of these domains and do not have any DNS record in NSX Advanced Load Balancer are either dropped or an NXDOMAIN response is sent (depending on the option set for invalid DNS queries, described above). Authoritative domain names are configured with ends-with semantics.

Note: All labels in subdomain and authoritative domain names must be complete. For instance, suppose alpha.beta.com, delta.beta.com, delta.eta.com, and gamma.eta.com are valid FQDNs. If we intend the GSLB DNS to return authoritative responses to queries for each of the four FQDNSs, two authoritative domains could be identified, beta.com and eta.com. It is not sufficient to stipulate eta.com alone because “eta” is not a complete label, and therefore does not match either alpha.beta.com or delta.beta.com.

L4 Profile Tab

The L4 Profile is used for any virtual service that does not require application-layer proxying.

Note: Using an L4 profile is equivalent to setting the virtual service’s application profile to ‘none’.

Rate limits may be placed on the number of TCP connections or UDP packets that may be made to the virtual service from a single client IP address.

You can specify the following details:

Name — Specify the name of the application profile.
Description — Specify the description for the L4 profile.
TCP Settings
- Enable PROXY Protocol — Check this box to enable the usage of proxy protocol to convey client connection information to the back-end servers.
  Note: This is valid only for L4 application profiles and TCP proxy.
TCP Connection Rate Limiter Settings

Rate Limit Connections from a Client — Rate limit all connections made from any single client IP address to the virtual service.
- Threshold — The client has violated the rate limit when the defined threshold of connections (TCP) or packets (UDP) is reached within the specified time period.
- Time Period — The client has violated the rate limit when the defined threshold of connections (TCP) or packets (UDP) is reached within the specified time period.
- Action — Select the action to perform when a client has exceeded the rate limit.
  - Report Only — A log is generated in the virtual service logs page. By default, no action is taken. However, this option may be used with an alert to generate an alert action to send a notice to a remote destination or to take action using a ControlScript.
  - Drop SYN Packets — For TCP-based limits, silently discard TCP SYNs from the client. NSX Advanced Load Balancer also will generate a log. However, during high volumes of DoS traffic, repetitive logs may be skipped.
  - Send TCP RST — Reset client TCP connection attempts. While more graceful than the Drop SYN Packet option, sending a TCP reset does generate extra packets for the reset, versus the Drop SYN Packet option which does not send a client response. NSX Advanced Load Balancer also will generate a log. However, during high volumes of DoS traffic, repetitive logs may be skipped.
Advanced Settings
- Preserve Client IP Address — Check this box if client IP needs to be preserved for backend connection. Not compatible with connection multiplexing.

Syslog Profile Tab

The Syslog application profile allows NSX Advanced Load Balancer to decode the Syslog protocol. This profile will set the virtual service to understanding Syslog, and the network profile to UDP with per-stream parsing.

You can specify the following details:

Name — Specify the name of the application profile.
Description — Specify the description for SYSLOG profile.

Advanced Settings

Preserve Client IP Address — Check this box if client IP needs to be preserved for backend connection. Not compatible with connection multiplexing.

SIP Profile Tab

SIP profile allows NSX Advanced Load Balancer to process traffic for SIP applications. This profile defines the transaction timeout allowed for SIP traffic through NSX Advanced Load Balancer. Configure the timeout within the range of 16 to 512 seconds.

You can specify the following details:

Name — Specify the name of the application profile.
Description — Specify the description for the SIP profile.

SIP Settings

Transaction Timeout — Specify the SIP transaction timeout in seconds.

After specifying the necessary details, click on Save button.