Content Switching

Clicking the Enable button, enables rule-based Content Switching on this Virtual Service. The Enable button only appears if the Virtual Service has a Real Server or SubVS. Once enabled, rules must be assigned to the various Real Servers. Rules can be attached to Real Server by clicking the None button located next the Real Server. Once rules are attached to a Real Server the None button will display the count of rules attached.

Rules Precedence

Clicking the Rules Precedence button displays the order in which Content Switching rules are applied. This option only appears when Content Switching and rules are assigned to the Real Server(s).

This screen shows the Content Switching rules that are assigned to the Real Servers of the Virtual Services and the order in which they apply. A rule may be promoted in the order of precedence by clicking its corresponding Move button.

In LoadMaster firmware 7.2.52 and above, it is easier to reorder the priority of rules in a Virtual Service - there is a move option that allows you to specify the position to move the rule to.

HTTP Selection Rules

Show the selection rules that are associated with the Virtual Service.

HTTP Header Modifications

Clicking Show Header Rules displays the order in which Header Modification rules are implemented. The number of rules (of both request and response type) is displayed on the actual button.

From within the screen you can Add and Delete Header Modification rules. The order in which the rules are applied can be changed by clicking the Move buttons.

In LoadMaster firmware 7.2.52 and above, it is easier to reorder the priority of rules in a Virtual Service - there is a move option that allows you to specify the position to move the rule to. Numbers are also now displayed on the page showing the content rules assigned to a Virtual Service to indicate the priority.

As of LoadMaster firmware version 7.2.51, you can assign URL modification rules to a response by selecting the relevant Modify Response rule in the Response Rules section.

Response Body Modification

Clicking the Show Body Modification Rules button displays the response body modification rules assigned to the Virtual Service. The number of assigned rules is displayed in the button label.

From this screen, you can Add and Delete response body modification rules to/from the Virtual Service. You can change the order that the rules are applied in by clicking the Move button.

In LoadMaster firmware 7.2.52 and above, it is easier to reorder the priority of rules in a Virtual Service - there is a move option that allows you to specify the position to move the rule to. Numbers are also now displayed on the page showing the content rules assigned to a Virtual Service to indicate the priority.

Note: Response body rules are not compatible with Kerberos Constrained Delegation (KCD). If KCD is enabled on a Virtual Service, it is not possible to assign a body rule to it.

Response Code Modification

The response code modification feature allows you to:

  • Obfuscate error codes returned by servers

  • Provide additional context (text) in server responses

In the above example, the endpoint does not exist. Returning this information to the client could be considered an information leak. Using the response code modification feature, you can modify the response on the way back to the client and change it to "Bad Request", for example.

If Response Code Modification is enabled, the error messages specified in the Response Mappings list that are coming from the Real Servers are replaced as specified. The text of the message is encoded in JSON and contains a { "status" : <status code>, "message": <message string> }, where status is the response code coming from the Real Server (unless this has been changed in the error response mappings) and the message string is the standard message text for that error message (as defined here: HTTP response status code). No Real Server-generated text or header fields are passed to the client.

Click Show Text & Mappings to open HTTP Response Code Management screen. Clicking Response Text displays a table of response codes and corresponding text messages you can select and edit. Click Save to save all updated text messages. To restore the default set of messages, click Reset to Defaults. You can select the desired response format (JSON/XML) from the Response Format drop-down list.

In the Response Mappings section, you can specify what response code to return to the client based on the response code from the server. For example, you could map the 404 Not Found response code from the server to 400 Bad Request before it is sent back to the client.

This section also displays the list of existing Error Response Code Mappings for a Virtual Service. Each server response code can only be mapped once per Virtual Service. However, you can map multiple different server response codes to the same client response code. For example, you can map errors 403 and 404 to error 400. You can select multiple server response codes at once if required.

Enable HTTP/2 Stack

Enable HTTP/2 client requests to be served by the LoadMaster directly. HTTP/2 requests are made using a secure connection. Please ensure the SSL Properties are configured and the BestPractices Cipher Set is selected if enabling this option. The Enable Caching check box should also be selected to optimize end user experience.

Enable Caching

This option enables caching of static content. This saves valuable Real Server processing power and bandwidth. You can enable caching on HTTP, offloaded HTTPS Virtual Services, and Virtual Services with SSL re-encryption enabled.

Before caching, the LoadMaster checks if there is any reason the content should not be cached. Some reasons the content may not be cached are:

  • The extension is on the File extensions that should not be cached list in Virtual Services > Cache Configuration.

  • The content is already cached.

  • The status code is not 200, 203, 300, 301, or 410.

  • The file was created in the last 60 seconds.

Items are held in the cache for a maximum of 1 hour. This time is not customizable. Every 15 minutes the LoadMaster checks if what is currently in the cache should still be there (it checks the maximum age of the header) and at that point it clears the cache as needed. The cache can be flushed on the browser by refreshing the page (for example, by pressing Ctrl + F5 on your keyboard). Disabling and re-enabling caching on the Virtual Service flushes the cache for that Virtual Service on the LoadMaster.

Note: Types of files that can be cached may be defined in Cache Configuration under the Virtual Services menu.

Maximum Cache Usage

If you enable caching on a Virtual Service, you can then limit the amount of cache being used by that service. The LoadMaster reserves 20% of the total system memory for the global cache value. For example, if a LoadMaster has 1GB of RAM - 20% (or 204MB) is reserved for caching and compression.

When you enable caching on a Virtual Service, you then have the option to set No Limit (which is the default value) or a percentage usage value. Selecting No Limit allows you to use all of the available cache. Alternatively, you can specify a percentage from 1 to 99%. This allows you to break up the 204MB in the example above into a percentage. For example, if you set 20% on the Virtual Service level - the Virtual Service has a total of 40MB available to cache server responses (20% of 204MB = 40.8MB). This leaves approximately 160MB available for other Virtual Services.

Note: This memory is also used by the LoadMaster for content switching and body response rules.

After selecting a percentage, the LoadMaster displays the overall total current usage assigned. This is a combination of the current usage assigned for all Virtual Services. For example, if there are two Virtual Services and on one the Maximum Cache usage is set to 10% and on the other it is set to 7%, the Current usage assigned value displays 17%. It is possible to over-provision/commit - if you attempt to do this, you will get a message saying Setting this value will overcommit the Cache memory by N%.

It is recommended to limit the cache size to prevent unequal use of the cache store. Ensure that the cache maximum usage is adjusted so that each Virtual Service has a percentage of cache to use. If there is no remaining space to be allocated for a cache-enabled Virtual Service, that service will not cache content.

Enable Compression

Files sent from LoadMaster are compressed with Gzip.

Note: If compression is enabled without caching, LoadMaster performance may suffer. When caching and compression are both enabled, caching has priority and therefore the first file is cached but not compressed. On second and subsequent requests, the file is found in the cache and then it is compressed.

The types of files that can be compressed may be defined in Compression Options in the Virtual Services menu of the LoadMaster WUI.

Note: Compression is not recommended for files 100MB or greater in size.
Note: More RAM may need to be added to Virtual LoadMasters using the hypervisor to compress large files.

Detect Malicious Requests

The Intrusion Prevention System (IPS) service will provide in-line protection of Real Server(s) by providing real-time mitigation of attacks and isolation of Real Server(s). Intrusion prevention is based on the industry standard SNORT database and provides real-time intrusion alerting.

Note: To get updated or customized rules, please refer to the SNORT website: https://www.snort.org/.
Note: The detection code only handles HTTP-classed rules.

Selecting the Detect Malicious Requests check box enables the IPS per HTTP and offloaded HTTPS Virtual Services. There are two options for handling of requests that match a SNORT rule. Drop Connection, where a rule match will generate no HTTP response, or Send Reject, where a rule match will generate a response to the client of HTTP 400 “Invalid Request”. Both options prevent the request from reaching the Real Server(s).

Enable Multiple Connect

Enabling this option permits the LoadMaster to manage connection handling between the LoadMaster and the Real Servers. Requests from multiple clients are sent over the same TCP connection.

Note: Multiplexing only works for simple HTTP GET operations. The Enable Multiple Connect check box will not be available in certain situations, for example if WAF, ESP or SSL Acceleration is enabled.

Reschedule on every HTTP Request

The Reschedule on every HTTP Request check box is only available on Virtual Services if the Protocol is set to tcp and the Service Type is set to HTTP-HTTP/2-HTTPS.

If the Reschedule on every HTTP Request option is enabled and content switching is not in use, this forces the reselection of a Real Server for each request. By default, the Real Server is selected only once per connection.

Note: You cannot enable the Reschedule on every HTTP Request checkbox if the Enable HTTP/2 Stack option is enabled.
Note: Persistence must be set to None (in Standard Options) to use the Reschedule on every HTTP Request feature.

Port Following

Port following is set when two services need to share persistence records. Typically, this is done for HTTP and HTTPS services so users maintain a server session, regardless of whether they connect securely or not.

If the Real Server for one of the Virtual Services fails, the persistence records for the same Real Server on the other Virtual Service will be cleared.

Port following has several requirements:

  • The Virtual Services must have the same set of Real Servers
  • The Virtual Service must be using the same persistence options

After meeting these conditions, in the Virtual Service modify screen there will be an option under Advanced Properties for Port Following. Ensure to set this on both Virtual Services to ensure that port following is done bi-directionally. Port following must be set up bi-directionally to ensure that, regardless of whether the client connects using HTTP or HTTPS, the persistence and session is saved.

Note: Prior to LoadMaster firmware version 7.2.51, it was not possible to configure port following for Virtual Services where the Service Type was set to Generic. This is possible in version 7.2.51 and above.

For further information, refer to the Port Following Feature Description.

Add Header to Request

Input the key and the value for the extra header that is to be inserted into every request sent to the Real Servers.

Click the Set Header button to implement the functionality.

Copy Header in Request

This is the name of the source header field to copy into the new header field before the request is sent to the Real Servers. Enter the name of the header field into which the source header is to be copied in the To Header text box.

Add HTTP Headers

This option allows you to select which headers are to be added to the HTTP stream. The options available include:

  • Legacy Operation(X-Forwarded-For)

  • None

  • X-Forwarded-For (+ Via)

  • X-Forwarded-For (No Via)

  • X-ClientSide (+ Via)

  • X-ClientSide (No Via)

  • Via Only

HTTP headers let the client and the server pass additional information with an HTTP request or response. Not all Virtual Services can handle HTTP data (header/body), for example, RDP Virtual Services. To improve the performance and to save unnecessary work, not all HTTP Virtual Services need to look at the HTTP data. Simple pass-through Virtual Services do not need to process the HTTP requests at all. If rules are defined on the Virtual Service, a header is added, or some more complicated feature is required, the Virtual Service does need to look at the HTTP data.

In older (legacy) versions of the LoadMaster, the setting for Add HTTP Headers was only global and it could not be set on a per Virtual Service basis. You can now update the setting for Add HTTP Headers on a specific Virtual Service if required. The default value is Legacy Operation(X-Forwarded-For) for backward compatibility reasons.

The Add HTTP Headers field is not configurable in the parent Virtual Service if a SubVS exists. We recommend not changing the Add HTTP Headers value in the parent Virtual Service if you intend to add a SubVS. If you need to change this in the parent Virtual Service after adding a SubVS, you can either use a content rule or run an API command to change the value, for example:

https://<LoadMasterIPAddress>/access/modvs?vs=<VSIndex>&Addvia=5

For further details on the RESTful API, including the valid values for the Addvia parameter, refer to the RESTful API documentation.

"Sorry" Server

Enter the IP Address and Port number in the applicable fields. If no Real Servers are available, the LoadMaster will forward to a specified IP:PORT, with no checking. The IP address of a "Sorry" Server must be on a network or subnet that is defined on the LoadMaster.

Note: When using a Layer 4 Virtual Service, the "Sorry" Server should be on the same subnet as the Real Server.
Note: When using a Layer 7 Virtual Service, the "Sorry" Server can be on any local network. It is also possible to add a non-local "Sorry" Server. For this, Transparency must be disabled, there must be a route to the "Sorry" Server and the Enable Non-Local Real Servers option must be enabled (System Configuration > Miscellaneous Options > Network Options).

Not Available Redirection Handling

When no Real Servers are available to handle the request you can define the error code and URL that the client should receive.

  • Error Code: If no Real Servers are available, the LoadMaster can terminate the connection with a HTTP error code. Select the appropriate error code.
  • Redirect URL: When there are no Real Servers available and an error response is to be sent back to the client, a redirect URL can also be specified. If the string entered in this text box does not include http:// or https:// the string is treated as being relative to the current location, so the hostname is added to the string in the redirect. This field also supports the use of wildcards such as %h and %s which represent the requested hostname and Uniform Resource Identifier (URI) respectively.
  • Error Message: When no Real Servers are available and an error response is to be sent back to the client, the specified error message is added to the response.

For security reasons, the returned HTML page only returns the text Document has moved. No request-supplied information is returned.

  • Error File: When no Real Servers are available and an error response is to be sent back to the client, the specified file is added to the response. This enables simple error HTML pages to be sent in response to the specified error.

The maximum size of this error page is 16KB.

"Sorry" Server/Port

In a UDP Virtual Service there is an option to specify a "Sorry" Server and Port. When there are no Real Servers available to handle the request, this option defines the URL that the client will receive.

Note: The value of the "Sorry" Server can only be changed for UDP if the service is not currently using the "Sorry" Server.

Add a Port 80 Redirector VS

If no port 80 Virtual Service is configured, one can be created. It will then redirect the client to the URL specified in the Redirection URL: field.

Click the Add HTTP Redirector button to implement the redirector.

Note: When the Add HTTP Redirector button is clicked, a redirect Virtual Service is created and this WUI option disappears from the relevant Virtual Service.

Default Gateway

Specify the Virtual Service-specific gateway to be used to send responses back to the clients. If this is not set, the global default gateway is used.

Click the Set Default Gateway button to implement the default gateway. The Default Gateway for a Virtual Service is only used for that Virtual Service.

Note: If the global Use Default Route Only option is set in System Configuration > Miscellaneous Options > Network Options, traffic from Virtual Services that have the Default Gateway set is only routed to the interface where the Virtual Service’s default route is located. This can allow the LoadMaster to be directly connected to client networks without returning traffic directly using the adjacent interface.

Alternate Default Gateway

This field is only visible if an Alternate Address is set for the Virtual Service. You should only use the Alternate Default Gateway field if all of the following conditions are met:

  • The Alternate Address has a different address family to the main Virtual Service address, for example, the Virtual Service address is IPv4 and the Alternate Address is IPv6 or the other way around.
  • The Virtual Service Default Gateway is set.
  • A second Virtual Service Default Gateway is set for the other address family.

Alternate Source Addresses

If no list is specified, the LoadMaster will use the IP address of the Virtual Service as its local address. Specifying a list of addresses ensures the LoadMaster will use these addresses instead.

Click the Set Alternate Source Addresses button to implement the Alternate Source Addresses.

Note: This option is only available if the Allow connection scaling over 64K Connections option is enabled in the L7 Configuration screen.

Service Specific Access Control

Allows you to change the Virtual Service-specific Access Control lists.

Note: If you implement the Access Control Lists option, the Extra Ports option will not work correctly.

When using Access Control Lists on a Virtual Service that has the same IP address as an interface (which we do not recommend) the following ports are never blocked for Real Servers on the same network interface accessing the VS as a client:

  • 443 (WUI)
  • 22 (SSH)
  • 53 (DNS)
  • 161 (SNMP)