Policies allow advanced customization of network layer security, HTTP security, HTTP requests, and HTTP responses. A policy can be used to control security, client request attributes, or server response attributes. Policies are comprised of matches and actions, similar to an if-then logic. If the logic evaluates to true, it matches the policy, and therefore the NSX Advanced Load Balancer performs the corresponding action.

Policies are comprised of one or more rules, which are match-action pairs. A rule can contain many matches, or have many actions. Multiple policies can be configured for a virtual service. Policies can alter the default behavior of the virtual service, or if the matching criteria are not met, can stay benign for a particular connection, request, or response.

Policies are not shared. They are defined on a per-virtual-service basis and intended to be simple point-and-click functionality.

For more advanced capabilities, see VMware NSX Advanced Load Balancer DataScript Guide.

Policies are configured within the Policies tab of the virtual service editor.

Prioritizing Policies

Policies can be used to recreate similar functionality found elsewhere within the NSX Advanced Load Balancer. For instance, a policy can be configured to generate an HTTP redirect from HTTP to HTTPS. The same functionality can be configured within the Secure-HTTP application profile. Since a policy is more specific than a general purpose profile, the policy takes precedence.

If the profile is set to redirect HTTP to HTTPS through port 443, and the policy is set to redirect HTTP to HTTPS on port 8443, the client will be sent to port 8443. (See Execution Priority in theVMware NSX Advanced Load Balancer DataScript Guide for more information.)

A virtual service can have multiple policies defined, one for each of the four types. Once defined, policies for the four types are implemented in the following order of priority:

  1. Network security policy.

  2. HTTP Security Policy.

  3. HTTP request policy.

  4. HTTP response policy.

  5. DataScripts policy.

  6. Access policy.

For instance, a network policy that is set to discard traffic takes precedence over an HTTP request policy set to modify a header. Since the connection is discarded, the HTTP request policy will not execute. Each policy type can contain multiple rules, which in turn can be prioritized to process in a specified order. This is done by moving the policies up or down in the ordered list within the NSX Advanced Load Balancer UI.

Match - Action

All policies are made up of match and action rules, which are similar in concept to if - then logic. Administrators set match criteria for all connections, requests, or response to the virtual service. The NSX Advanced Load Balancer executes the configured actions for all traffic that meets the match criteria.

A single match with multiple entries is treated as “or” operation. For instance, if a single match type has the criteria “marketing”, “sales”, and “engineering” set, then the match is true if the path contains “marketing”, or “sales”, or “engineering”.

If a rule has multiple matches configured, all match types must be true for the action to be executed. In the above screenshot, both the path and HTTP method matches must be true. Within each of these two match types, only one of the entries must be true for that match type to be true. For HTTP method, a client request must be of type GET or HEAD. Multiple rules can be configured for each policy and they can be configured to occur in a specific order. If no match is applied, the condition is automatically met and the actions will be executed for each connection as per the policy type.

Matches against HTTP content are case-insensitive. This is true for header names and values, cookies, host names, paths, and queries. For HTTP policies, the NSX Advanced Load Balancer compares Uniform Resource Identifier (URI) matches against the decoded HTTP URI. Many browsers and web servers encode human-readable format content differently. For instance, a browser’s URI encoding might translate the dollar character “$” to “%24”. The Service Engine (SE) translates the “%24” back to “$” before evaluating it against the match criteria.

Create a Policy

The virtual service editor defines policies consisting of one or more rules that control the flow of requests through the virtual service.

The following are the steps to create a policy:

  1. Policy Type: First select the policy type to add by selecting one of the following categories:

    1. HTTP Security: HTTP security policies perform defined actions such as allow/deny, redirect to HTTPS, or respond with a static page.

    2. Network Security: It is configured to explicitly allow or block traffic of user-defined types in the network.

    3. HTTP Request: HTTP request policies allow manipulation of HTTP requests, content switching and also allow customized actions based on client HTTP requests.

    4. HTTP Response: HTTP response policies evaluate responses from the server, and can be used to modify the server’s response headers. HTTP response policies are most often used with HTTP request policies to provide an Apache Mod_ProxyPass capability for rewriting a website’s name between the client and the server.

    5. DataScripts: DataScripts execute when various events are triggered by data plane traffic.

    6. Access: Access policy can be provided for SAML or Ping access.



  2. Create Rule: Create a new rule by clicking the 'plus' icon and specify the following information for the new rule:

    1. Enable or Disable: By default, the new rule is enabled. The green slider icon can be toggled to change to gray, to deactivate the rule and make it have no effect on the traffic.

    2. Rule Name: Specify a unique name for the rule in the Rule Name field, or leave the default system generated name in place.

    3. Logging: Select Logging if you want logging enabled for this rule. When enabled, a log is generated for any connection or request that matches the rule’s match criteria. If a virtual service is already set to log all connections or requests, this option will not create a duplicate log. Client logs are flagged with an entry for the policy type and rule name that matched. When viewing the policy’s logs within the logs tab of the virtual service, the logs will be part of the significant logs option unless the specific connection or request is a non-error traffic, in which case it can be displayed under the default non-significant logs filter.

    4. Match: Add one or more matches using the Add New Match drop-down menu. The match options vary depending on the context defined by the policy type to be created. If a rule is not given a match, all connections or requests are considered true or matched.

    5. Action: Add one or more actions from the dropdown menu to be taken when the matches are true. The available options vary depending on the type of rule to be created.

    6. Save Rule: Click the Save Rule button to save the new rule.



  3. Ordering: Rules are enforced in the order in which they appear in the list. For instance, if you add a rule to close a connection based on a client IP address, followed by a rule that redirects an HTTP request from that IP address to a secure HTTP (HTTPS) connection, the NSX Advanced Load Balancer closes the connection without forwarding the request. Alter the order in which rules are applied by clicking the up and down arrow icons until the rules are in the desired order.

Network Security

The following table lists both the available network security match criteria and the configurable actions that can occur when a match is made.

Note:

This feature is supported for IPv6 in NSX Advanced Load Balancer.

Match

Client IP: Client IP address or a group of client addresses.

  • Use a "-" to specify a range: 10.0.0.0-10.1.255.255

  • Use a "/" to specify a netmask: 10.0.0.0/24

Service Port: The ports on which the virtual service is listening.

IP Reputation: The IP reputation service to identify or categorize IP addresses based on the threats associated with them.

Actions

Logging: Selecting the option causes the NSX Advanced Load Balancer to log when an action has been invoked.

Allow or Deny: Explicitly allow or deny any matched traffic. Denied traffic is issued a reset (RST), unless the system is under a volumetric or denial of service attack, in which case the connection can be silently discarded.

Rate Limit: Restrict clients from opening greater than the specified number of connections per second in the Maximum Rate field. Clients that exceed this number will have their excessive connection attempts silently discarded. If burst size is enabled, clients can burst above the maximum rate, if they have not recently been opening connections. This feature can be applied to TCP or UDP. All clients that match the match criteria will be treated as one bucket. For instance, if no match is defined, any, and all IP addresses will increment the maximum rate counter. Throttling occurs for all new connecting clients.

HTTP Security Policy

The following table lists both the available HTTP security match criteria and the configurable actions that can occur when a match is made.

Match

Client IP: Client IP address or a group of client addresses.

  • Use a "-" to specify a range: 10.0.0.0-10.1.255.255

  • Use a "/" to specify a netmask:10.0.0.0/24

  • Use a pre-defined IP group, which can be based on geo-location.

Service Port: The ports on which the virtual service is listening.

In SNI virtual hosting and enhanced virtual hosting, the service match criterion is matched against its parent virtual service for policies under a child virtual service.

Protocol Type: HTTP or HTTPS.

Example: https://www.avinetworks.com/marketing/index.html?a=1&b=2

HTTP Method: The method used by the client request. The match is true if any one of the methods that an administrator specifies is true.

The options available are GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE, and CONNECT, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, and UNLOCK.

HTTP Version: True if the client version is 0.9, 1.0, or 1.1

Path: The path or a group of paths. Paths do not need to begin with a forward slash (/). For comparison purposes, the NSX Advanced Load Balancer automatically omits any initial slash specified in the match field.

Example: https://www.avinetworks.com/marketing/index.html?a=1&b=2

Query: A query or a group of queries. Do not add the leading ‘?’ or ‘&’ characters to a match.

Example: https://www.avinetworks.com/marketing/index.html?a=1&b=2

Headers: True if a header exists, or if it exists and contains a specified value

Cookie: True if a cookie exists, or if it exists and contains a specified value

Host Header: The host header of the request.

Example: https://www.avinetworks.com/marketing/index.html?a=1&b=2.

Actions

Logging: Selecting the option causes the NSX Advanced Load Balancer to log when an action has been invoked.

Allow: Allows the matched requests to continue on to further policies or to the destination pool servers.

Close Connection: Matched requests causes the NSX Advanced Load Balancer to close the TCP connection that received the request through an FIN. Many browsers open multiple connections that are not closed unless requests sent over those connections also trigger a close connection action.

Redirect To HTTPS: Respond to the request with a temporary redirect to the desired port for SSL.

Send Response: The NSX Advanced Load Balancer can serve an HTTP response using HTTP status code 200 (success), 403 (unauthorized), or 404 (file not found). A default page is rendered by the browser for each of these status codes. Instead, you can also upload a custom HTML file. This file can have links to images or other files, but only the initial HTML file is stored and served through the Send Response.

Note:

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.

Rate limit: Specify the maximum number of new connections, HTTP requests, bandwidth in Mbps, and/or concurrent open connections from/for/by clients.
Note:

HTTP security policy option in available on the NSX Advanced Load Balancer UI. To create or edit the existing HTTP security policy, navigate to Applications > Virtual Services, select the desired virtual services, and select the HTTP Security option.

TLS Fingerprint Support for HTTP Security Policies

NSX Advanced Load Balancer supports configuration of HTTP security policies to block bad requests from a client/source having a specific TLS fingerprint (different from that of common browsers).

The configuration workflow consists of the following steps:

  • Finding TLS fingerprints associated with bad requests

  • Configuring HTTP security policy with tls_fingerprint_match

  • Associating Virtual Services with the specific HTTP security policy

Usually a client’s TLS fingerprint is not part of the application log. To log the TLS fingerprint in full detail, click the following box in the UI:

HTTP Request

HTTP request policies allow manipulation of HTTP requests. These requests can be modified before they are forwarded to the server, used as a basis for content switching, or discarded. The HTTP request policies can only be applied to a layer 7 virtual service configured with an HTTP profile. The following table lists the match criteria available under HTTP request, and the actions that can be configured to occur when a match is made.

Note:

This feature is supported for IPv6 in NSX Advanced Load Balancer.

HTTP Request Policy

Match

Client IP: Client IP address or a group of client addresses.

Use a "-" to specify a range: 10.0.0.0-10.1.255.255 Use a "/" to specify a netmask: 10.0.0.0/24 Use a pre-defined IP Group, which can be based on geo-location.

Note:

Client IP address in IPv6 address format can also be used.

Service Port: The ports the virtual service is listening on.

Protocol Type: HTTP or HTTPS.

Example: https://www.avinetworks.com/marketing/index.html?a=1&b=2.

HTTP Method: The method used by the client request. The match is true if any one of the methods that an administrator specifies is true.

The options available are GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE, and CONNECT. You can also choose from the additional options: PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, and UNLOCK.

HTTP Version: True if the client version is 0.9, 1.0, or 1.1

Path: The path or a group of paths. In accordance with RFC 3986, a path is empty or starts with a forward slash. For the beginswith and equals match operators in an HTTP request match policy, the match string needs to begin with a forward slash to result in a match.

Example: In https://www.avinetworks.com/marketing/index.html?a=1&b=2 the path is /marketing/index.html.

Query: A query or a group of queries. Do not add the leading ‘?’ or ‘&’ characters to a match.

Example: https://www.avinetworks.com/marketing/index.html?a=1&b=2.

Headers: True if a header exists, or if it exists and contains a specified value.

Cookie: True if a cookie exists, or if it exists and contains a specified value.

Host Header: The request’s host header.

Example: https://www.avinetworks.com/marketing/index.html?a=1&b=2.

Action

Redirect URL: Redirects a client to a different protocol, port, host, or path. By default the host, path, and query are not altered unless an administrator populates those fields. The path field does not require a leading “/” slash character. To create a simple HTTP to HTTPS redirect, simply set the protocol to HTTPS.

Note:

The redirect action may not be stacked with other actions.

Modify Header: Allows adding, replacing, or removing of an HTTP header or cookie. The

Note:

The fieldIs Sensitive? is added within the Modify header action to mask any custom value that is sensitive.

Rewrite URL: Similar to ProxyPass functionality, this action allows for the client’s requested URL to be rewritten into a URL that the server understands. For example, the client should use www.avinetworks.com/sales, while the server may be configured for sales.avinetworks.com. The path field does not require a leading "/" slash character.

Content Switch: Forward matched requests to a pool, or a specific server with that pool. Alternatively, the NSX Advanced Load Balancer can serve an HTTP response using HTTP status code 200 (success), 403 (unauthorized), 404 (file not found), or 429 (too many requests). A default page is sent for each of these status codes, or a custom html file may uploaded.

Note:

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.

Why is a virtual service always up when a redirect policy is attached to it?

A virtual service on Avi Vantage remains always up when a redirect policy is attached to it. This is an expected behaviour and this behaviour is by design. A virtual service is kept alive if one of the following conditions is met:

  • At least one of the pools associated to the virtual service is up.

  • A policy (for example, a redirect policy) associated with the virtual service that does not need a pool.

  • A DataScript attached to the policy.

  • The virtual service is associated to a policy that sends a local response.

Is Sensitive

Is Sensitive option is used to mask the custom values in ‘Modify Header’. The Is Sensitive field is added within Modify Header action to add any custom value which is sensitive.

The sensitive field (Is Sensitive) is a flag in HTTP header value which determines if the custom value has to be marked sensitive or not. If you check Is Sensitive field, then the custom value in Modify header option in action for HTTP Policy Set will be masked. An example is shown in the screenshot below:



Note:

The Is Sensitive is an immutable field, it can only be set or unset during creation of the HTTP policy.

As the header values are masked, updating an existing header can be difficult for the admins. To simplify this, NSX Advanced Load Balancer assigns an index, that is, an integer value to identify all the headers uniquely as shown in the screenshot above. This helps to remove the ambiguity. The index is auto assigned by NSX Advanced Load Balancer. If there is any requirement to change the index, it can be done using CLI or API and you need to ensure that the index should be a unique value.

The CLI for setting sensitive field for custom values in HTTP Policies is as follows:

+------------------------+----------------------------------------------------+
| Field                  | Value                                              |
+------------------------+----------------------------------------------------+
| uuid                   | httppolicyset-14be5dde-8ff2-4891-a930-a81b6f547d9b |
| name                   | test-HTTPPolicySet-0                               |
| http_request_policy    |                                                    |
|   rules[1]             |                                                    |
|     name               | Rule 1                                             |
|     index              | 1                                                  |
|     enable             | True                                               |
|     match              |                                                    |
|       vs_port          |                                                    |
|         match_criteria | IS_IN                                              |
|         ports[1]       | 80                                                 |
|     hdr_action[1]      |                                                    |
|       action           | HTTP_ADD_HDR                                       |
|       hdr              |                                                    |
|         name           | pqr                                                |
|         value          |                                                    |
|           val          | <sensitive>                                        |
|           is_sensitive | True                                               |
|       hdr_index        | 1                                                  |
| is_internal_policy     | False                                              |
| tenant_ref             | admin                                              |
+------------------------+----------------------------------------------------+

HTTP Policy QueryMatch

In HTTP policies, one of the parameters that can match against is the query string in the URI. QueryMatch is similar to other match targets in the following ways:

  • It is used to match the query string against a list of custom strings or string groups.

  • It is used to copy the query string into the action rules (Redirect or Rewrite URL actions) using the Keep Query knob.

Addition of Match Criteria

The following are the match operations supported for Query match:

Match Operation

Description

QUERY_MATCH_CONTAINS

Query string contains the configured value(s)

QUERY_MATCH_DOES_NOT_CONTAIN

Query string does not contain the configured value(s)

QUERY_MATCH_EXISTS

Check if the query string is present in the URI

QUERY_MATCH_DOES_NOT_EXIST

Check if the query string is absent (or empty)

QUERY_MATCH_BEGINS_WITH

Query string begins with the configured value(s)

QUERY_MATCH_DOES_NOT_BEGIN_WITH

Query string does not begin with the configured value(s)

QUERY_MATCH_ENDS_WITH

Query string ends with the configured value(s)

QUERY_MATCH_DOES_NOT_END_WITH

Query string does not end with the configured value(s)

QUERY_MATCH_EQUALS

Query string equals the configured value(s)

QUERY_MATCH_DOES_NOT_EQUAL

Query string does not equal the configured value(s)

QUERY_MATCH_REGEX_MATCH

Query string matches the configured regular expression

QUERY_MATCH_REGEX_DOES_NOT_MATCH

Query string does not match the configured regular expression


Note:

  • Regex matching uses string groups exclusively.

  • Regex matching can have up to ten capture groups.

Matching Encoded Strings

NSX Advanced Load Balancer supports Match Decoded String option for the Query_Match is supported (as earlier supported for path match). This option allows user to specify whether to match against an encoded (UTF-8) or decoded query string. By default, the option is selected.

Example 1:

If Match_decoded is unmarked and URI /hello/test?efg=%21efg is sent, the rule will match. Whereas if URI /hello/test?efg=!efg is sent, the rule will not match.



Example 2:

If Match_decoded is marked for the strings hello/test?efg=!efg or hello/test?efg=%21efg, both will match because the string will be converted to hello/test?efg=!efg in both cases.



HTTP Request Queuing

HTTP request queuing allows the NSX Advanced Load Balancer to queue requests that are received after a backend server has reached its maximum allowed number of concurrent connections. Queuing HTTP requests provides time for new connections to become available on the server, without performing the configured pool down action.

HTTP request queuing is disabled by default. The feature can be enabled on a per pool basis. The default queue length is 128 requests, when the feature is enabled. The queue length is configurable, from 1 up to any required amount. The only limitation is that memory must be available on the SE.

How the Queue is Managed

Queued requests are managed on a last-in, first-out (LIFO) basis. For example, if the queue length is 128, the NSX Advanced Load Balancer can queue up to 128 requests for a saturated server. Only GET requests can be queued. PUT requests are not queued. While the server is unable to accept new requests, the NSX Advanced Load Balancer queues the new requests, up to the maximum number of requests the queue can hold, that is, the queue length. If the queue is full and the server is still unable to accept new requests, the queue is bypassed and the NSX Advanced Load Balancer begins applying the configured pool down action to new requests.

When the server is able to accept new requests again, priority is given to new requests. New requests have priority over the queued requests and are sent to the server first. Only when no new requests are available to send to the server, the SE sends requests from its queue, beginning with the most recent one, namely, the last one queued. Sending the most recently queued requests instead of the oldest requests from the queue helps minimize impact on end-users as some newer requests might be resends of older requests, or the client might have ended the unresponsive session. Sending a request to the queue because the server is full does not generate a failure event. If the queue is also full, then an event is generated.

Effect on Persistence

HTTP request queuing can be used along with persistence. If both features are enabled, and persistence requires a connection to remain on a particular server and that server is full, requests for that connection are queued until the required server has available connections for them. The requests are not sent to another server. Within the queue, the requests are still managed as described above, on a LIFO basis.

Effect on HTTP Caching

If HTTP caching is enabled and the NSX Advanced Load Balancer receives a request for an object that is in the cache, the NSX Advanced Load Balancer fulfills the request by sending the object from the cache, instead of requesting the object from the server. In this case, even if none of the servers has a free connection to receive the request, the request does not need to be queued.

Queue Size Recommendations

SEs must have enough memory to support the configured HTTP queue size.

For an average request size of 2 KB per request, setting the queue length to 128 requires 256 KB of memory. For higher queue sizes, the appropriate amount of memory must be allocated to the SE.

Effects of Changing the Queue Length

If the queue length is changed, the change goes into effect immediately.

  • Increasing the queue length allows more requests to be queued while the server is saturated.

  • If the queue length is decreased and the new size is smaller than the number of requests that are currently in the queue, the NSX Advanced Load Balancer immediately drops the extra requests from the queue, beginning with the oldest one (first queued). For example, if the queue length is 128 and the queue is full, reducing the queue length to 64 results in the immediate drop of the 64 oldest requests from the queue.

Configuring HTTP Request Queuing

To enable request queuing for a pool:

  1. Navigate to Applications > Pools.

  2. Click Create for creating a new pool or click the edit icon next to the pool name.

  3. Go to the Advanced tab. If creating a new pool, enter a name, and click Next twice.

  4. In the Pool Full Settings section, select Enabled next to Request Queuing.

  5. To change the queue size, edit the number in the Queue Length field. There is no specific maximum length value. In this case, the amount of memory available on the SE for queuing presents the practical limit.

  6. If you are configuring a new pool, finish configuring any other pool settings, and click Save.

HTTP Response Policy

HTTP response policies evaluate responses from the server, and can be used to modify the response headers of the server. These policies are generally used to rewrite redirects or in conjunction with HTTP request policies, to provide a client to server name-rewriting capability similar to Apache’s ProxyPass.

If the intent is to create a hostname mapping from internal to external, consider using the more straightforward Host Name Translation feature within the advanced section of a virtual service. During the HTTP response match, the match criteria that are based on client data are evaluated against the original client request. For example, if the client requested /fruit.htm, and a request policy modified the path to /cheese.htm, the response match rule for path would compare against the unmodified, original path sent from the client, namely /fruit.htm. The following table lists the match criteria available under HTTP response, and the actions that can be configured to occur when a match is made.

Match

Client IP: Client IP address or a group of client addresses.

  • Use a "-" to specify a range: 10.0.0.0-10.1.255.255

  • Use a "/" to specify a netmask: 10.0.0.0/24

  • Use a pre-defined IP group, which can be based on geo-location

Service Port: The ports the virtual service is listening on.

Protocol Type: HTTP or HTTPS.

Example: https://www.avinetworks.com/marketing/index.html?a=1&b=2.

HTTP Method: The method used by the client request. The match is true if any one of the methods that an administrator specifies is true.

HTTP Version: True if the client version is .9, 1.0, or 1.1.

Path: The path or a group of paths. Paths start with a ‘/’. Example: https://www.avinetworks.com/marketing/index.html?a=1&b=2.

Query: A query or a group of queries. Do not add the leading ‘?’ or ‘&’ characters to a match.

Example: https://www.avinetworks.com/marketing/index.html?a=1&b=2

Headers: True if a header exists, or if it exists and contains a specified value.

Cookie: True if a cookie exists, or if it exists and equals a specified value.

Host Header: The request’s host header.

Example: https://www.avinetworks.com/marketing/index.html?a=1&b=2

Location Header: The location header may not exist for every website.

HTTP Status: The status of the response, such as 200 (success), 404 (file not found), or similar. The statuses can be separated by commas, or be a range. For example: 301, 302, 307, 308, 300-599.

Response Header: Match based on a specific header sent by the server.

Actions

Logging: Selecting the logging check box causes Vantage to log when an action has been invoked.

Modify Header: Allows for the addition, replacement, or removal of an HTTP header or cookie.

Rewrite Location Header: Changes the location header. Useful for proxying between internal and external names, such as www.avinetworks.com/sales to sales.avinetworks.com/.

DataScripts

DataScripts are executed when various events are triggered by data plane traffic. A single rule can execute different code during different events.

See DataScript Events in VMware NSX Advanced Load Balancer DataScript Guide for more details.

Access

Access policy can be provided for SAML, PingAccess, JWT or LDAP access.

SAML

If you select SAML option, specify the following details:

  • SSO Policy: Specify the SSO policy attached to the virtual service.

  • Entity ID: Specify the SAML entity ID for this node.

  • SSO URL: Specify the SAML single sign-on URL to be programmed on the IDP.

  • Session Cookie Name: Specify the HTTP cookie name for the authenticated session.

  • Session Cookie Timeout: Specify the cookie timeout in minutes.

  • SSL Key: Select the SSL key from the drop-down menu.

PingAccess

If you select PingAccess option, specify the following details:

  • SSO Policy: Specify the SSO policy attached to the virtual service.

Create SSO policy by clicking Create SSO Policy button. Specify the following details:

  • Name — Specify the name of the SSO policy.

  • Type — Select the SSO policy type from the drop-down list. The following are the options available in the drop-down list.

    • JWT

    • LDAP

    • OAUTH/OIDC

    • PingAccess

    • SAML

  • Default Auth Profile: Specify the auth profile to use for validating users.

  • Authentication Rules: Click ADD button to add the authentication details.

JWT

If you select JWT option, specify the following details:

  • SSO Policy: Select the SSO Policy attached to the virtual service.

  • Audience: Specify the unique audience to identify a resource server.

  • Token Location: Select the token location as Authorization Headeror URL Query.

LDAP

If you select LDAP option, specify the following details:

  • SSO Policy: Specify the SSO policy attached to the virtual service.

  • Basic Realm: When a request to authenticate is presented to a client, the basic realm indicates to the client which realm they are accessing.

  • Connections Per Server: Specify the number of concurrent connections to LDAP server by a single basic auth LDAP process.

  • Cache Size: Specify the size of LDAP basic auth credentials cache used on the dataplane.

  • Bind Timeout: Specify LDAP basic auth default bind timeout enforced on connections to LDAP server.

  • Request Timeout: Specify LDAP basic auth default login or group search request timeout enforced on connections to LDAP server.

  • Connect Timeout: Specify LDAP basic auth default connection timeout enforced on connections to LDAP server.

  • Reconnect Timeout: Specify LDAP basic auth default reconnect timeout enforced on connections to LDAP server.

  • Servers Failover Only: Check this box to indicate that LDAP basic auth uses multiple LDAP servers in the event of a fail-over only.

After specifying all the necessary details, click Save button.

Policy Tokens

In more complex scenarios, an administrator can capture data from one location and apply it to another location. The NSX Advanced Load Balancer supports the use of variables and tokens, which can be used for this purpose.

Variables can be used to insert dynamic data into the modify header actions of HTTP request and HTTP response policies. Two variables namely, $client_ip and $vs_port are supported. For instance, a new header can be added to a HTTP request called origin_ip, with a value set to $client_ip, to insert the source address of the client as the value of the header.

Tokens can be used to find and reorder specific parts of the HTTP hostname or path. For instance, it is possible to rewrite the original request http://support.avinetworks.com/docs/index.htm to http://www.avinetworks.com/support/docs/index.htm. Tokens can be used for HTTP host and HTTP path. The tokens are derived from the original URL. Token delimiter in host header is “.” and in the URL path it is “/”.

Example 1

Original request URL:

support

avinetworks

com

docs

index.htm

Token:

host[0]

host[1]

host[2]

path[0]

path[1]
In the example above, the client request is broken down into HTTP host and HTTP path. Each section of the host and path are further broken down according to the “.” and “/” delimiters for host and path. A host or path token can be used in an action to rewrite a header, a host, or a path. In the example, a redirect of http://www.avinetworks.com/support/docs/index.htm would send requests to docs.avinetworks.com/support/docs/index.htm

In addition to using the host[0], host[1], host[2] convention, a colon can be used to denote whether the system must continue till the end of the host or path. For instance, host[1:] implies to use avinetworks, followed by any further host fields. The result will be avinetworks.com. This is especially useful in a path, which may contain many levels. Tokens can also specify a range, such as path[2:5]. Host and path tokens can also be abbreviated as 'h' and 'p', such as h[1:] and p[2].

In the rewrite URL, redirect, and rewrite location header actions, the host component of the URL can be specified in terms of tokens, the tokens can be constants strings or tokens from existing host and path component of the URL.

Example 2

New URL: region.avinetworks.com/france/paris/index.htm

Request URL

paris

france

avinetworks

com

region

index.htm

Token:

host[0]

host[1]

host[2]

host[3]

path[0]

path[1]

New Host:

path[0].host[2:]

New Path:

/host[1]/host[0]/path[1]

Example 3

Request URL

www1

avinetworks

com

sales

foo

index.htm

auth=true

Token:

host[0]

host[1]

host[2]

path[0]

path[1]

path[2]

(query)

New Host:

www.host[1:]

New Path:

/host[0]/path[0:]

Query:

Keep Query enabled

New URL:

www.avi.com/www1/sales/foo/index.htm?auth=true

  • If the host header contains an IPv4 address and not an FQDN, and the rewrite URL or redirect action refers to a host token, for instance, host[0], host[1,2], and so on, the rule action is skipped and the next rule is evaluated.

  • If the host header or path contains fewer tokens than that referenced in the action, then the rule action is skipped. For instance, if the host name in the host header has only three tokens (host name www.avinetworks.com, where, token host[0] = www, host1 = avinetworks, host2 = com). If the action refers to host[4] the rule action is skipped.

  • If the location header in the HTTP response contains an IPv4 address and the response policy action is rewrite location header which refers to host tokens, the rule action is skipped.

  • Rule engine does not recognize octal or hexadecimal IPv4 address in the host address. That is, the rule action is not skipped if the host header has octal/ hexadecimal IPv4 address and the action references a host token such as host1, and so on.

  • If an HTTP request arrives with multiple host headers, the first host header will be used.

  • Per RFC, HTTP 1.1 requests must have a non-empty host header. On encountering an empty header, a 400 ‘Bad Request’ HTTP response is returned by the NSX Advanced Load Balancer.

  • The HTTP processing is performed against decoded URIs.

Regex Matching in Policies

The NSX Advanced Load Balancer supports the use of regex captures as tokens that can be used in Policy actions. These regex captures are obtained from the regex pattern string that are matched with the URI in the match rule configured in the policy.

The following are the steps to configure regex matching and tokens:

  • Create a string group object with the list of regex patterns you want to use for URI matching. Note the use of regex captures (the string pattern within the parentheses) which are needed to generate the regex tokens.

  • Navigate to Templates > Groups > String Groups. Click CREATE. Specify the string name and type.

  • Under Policies, create a matching rule with the Criteria field selected as Regex pattern matches and attach the necessary string group(s).

  • You can now use regex captures as tokens in the corresponding action rule. On the GUI, you can use SG_RE[] to access these tokens. These tokens are obtained from the first string in the string group list that matched with the request Path.

  • Regex captures from the query string can be accessed in the action rule using SG_RE_Q to index the required capture group.

Example

Regex String: ^/hello/(.*)/world/(.*)$

Request Path: /hello/foo/world/bar

Regex

Request Path

Tokens

New Path

New Path

^/hello/

/hello/

SG_RE[0]/SG_RE[1] /

/foo/bar /

(.*)

/foo/

SG_RE[0]

/world/

/world/

(.*)$

bar

SG_RE[1]

Caveats and Limitations

  • Regex matching uses string groups exclusively.

  • Regex matching can have up to ten capture groups.