1. Kemp Support
2. Documentation
3. LoadMaster
4. Release Notes

LoadMaster 7.2.52.0 Release Notes

Updated: April 27, 2022 10:01

LMOS Version 7.2.52 is a feature and bug-fix release made available in October 2020. Please read the sections below before installing or upgrading.

Contents

Before You Upgrade (READ ME FIRST)

This release updates the BestPractices cipher set as shown in the section below and this change is effective immediately after upgrade to this release from LMOS 7.2.51 or a previous release. This change is being made to improve LoadMaster security and conform to the latest industry best practices. For more information on the cipher suites being removed from the set, please see the section Best Practices Cipher Set Updated, below.

If you depend on any of the cipher sets being removed from the BestPractices set, then before you upgrade you must create a custom cipher set that contains these ciphers and assign this new custom cipher to the Virtual Services that are currently using the BestPractices cipher set. If you do not, any clients that depend on these ciphers being available will no longer be able to connect. After this is done, you can upgrade to LMOS 7.2.52 and your services will continue to use the old ciphers.

It is recommended, however, that you migrate your services as soon as possible to use the new BestPractices cipher set provided with LMOS 7.2.52.

Supported Models for Upgrade

This release of LMOS is supported on the Hardware and Virtual models shown in the first three columns of the table below. It is not supported and should not be installed on any model listed in the two columns at right. This update patch can be applied to any supported model regardless of licensing (e.g., SPLA, MELA) or platform (e.g., hardware, local cloud, public cloud).

Supported Virtual Models	Supported Hardware Models		Supported Bare Metal Models	UNSUPPORTED Hardware Models	UNSUPPORTED Virtual Models
VLM-200 VLM-500 VLM-2000 VLM-3000 VLM-5000 VLM-10G VLM-GEO VLM-MAX	LM-X1 LM-X3 LM-X15 LM-X25 LM-X40 LM-2400 LM-3000 LM-3400 LM-4000 LM-5000	LM-5400 LM-5600 LM-8000 LM-8020 LM-8020M LM-R320	LMB-1G LMB-2G LMB-5G LMB-10G LMB-MAX	LM-2000 LM-2200 LM-2500 LM-2600 LM-3500 LM-3600 LM-5300 LM-5500 LM-Exchange LM-GEO	VLM-100 VLM-1000

If your model number is not listed above, please see the list of End of Life models.

Upgrade Path

You can upgrade to this release of LMOS from any previous 7.2.x release. For full upgrade path information, please see the article Kemp LoadMaster Firmware Upgrade Path.

Upgrade Patch XML File Verification Notes

By default, verification of the digital signature on upgrade images is required in LMOS 7.2.50 and above. See the Update Verification Options setting under System Administration > Miscellaneous Options > WUI Settings. If the unit you are upgrading is set to require validation, you'll need to supply one of the two XML Verification Files supplied with this release:

• 7.2.52.0.19393.RELEASE.PATCH-64-MULTICORE-preV7.2.51.0.checksum.xml
  Use this file when upgrading a LoadMaster running a release prior to LMOS 7.2.51.

• 7.2.52.0.19393.RELEASE.PATCH-64-MULTICORE.checksum.xml
  Use this file when upgrading from LMOS 7.2.51 or repeating an upgrade to LMOS 7.2.52 (that is, LoadMaster is already running 7.2.52.0 and you want to repeat the upgrade process).

LoadMasters running an LMOS version prior to 7.2.49 do not provide the option of XML file verification in the UI or API. If you are upgrading from one of these releases to 7.2.52, you can verify the digital signatures using a manual process documented on the support website.

See Appendix A for a table that shows you which XML file to use for signature verification based on your current release and the release to which you want to upgrade.

Downgrading to Earlier Versions

Downgrading a LoadMaster running LMOS 7.2.52 to LMOS 7.2.51 can be performed using any desired Update Verification Options setting.

Downgrading to LMOS 7.2.50 or a previous release can only be done when the Update Verification Options setting is set to Optional or Legacy. When performing the downgrade, do not specify an XML file. If you want to verify the digital signature on the image before downgrading, you can do so using a manual process documented on the support website.

[Note that XML file verification is not part of the process of switching the active LoadMaster partition to the LMOS release that was running on LoadMaster before the last update.]

New Features

The following new features have been added to this release of LMOS.

Rate Limiting / Quality of Service for Incoming Connections

The ability to limit the number and rate of client connections to LoadMaster is now supported via controls on a new System Configuration > QoS/Limiting UI page. The following methods of limiting incoming connections are provided.

Global limits on all incoming connections to LoadMaster:

• Concurrent connection limit
• Connection per second (CPS) limit
• Request per second (RPS) HTTP request limit

Client limits specified by network addresses or ranges of addresses:

• Concurrent connection limit
• Connection per second (CPS) limit
• Request per second (RPS) HTTP request limit

URL-Based (or VS-based) RPS limits, specified by string-matching on specific URL fields:

• Request URL
• Host
• User Agent

Client limit statistics appear in the system logs and are visualized in the UI on the Statistics > Real Time Statistics > Client Limits page. Note that this page is available in the UI only if there is at least one client limit enabled in the Rate Limiting screen.

SSL Information in Client Request Headers

A new check box, Add Received Cipher Name, has been added to the SSL Properties section for HTTP/HTTPS Virtual Services. When this option is enabled, the LoadMaster adds the HTTP headers described in the table below to client requests with the indicated values. This option is disabled by default to be compatible with the behavior in previous releases.

The information added to the HTTP headers can also be used by destination real servers to, for example, maintain cipher sets over time, retiring old cipher sets that are no longer being used.

Header	Description	Example Value
X-SSL-Cipher	The cipher used.	ECDHE-RSA-AES256-GCM-SHA384
X-SSL-Protocol	The SSL protocol version used.	TLSv1.2
X-SSL-Serialid	The VS certificate serial number.	4900000006A2ABDC165ACEAD55000000000006
X-SSL-ClientSerialid	The client certificate serial number.	490000005D6898F3C7E590536100010000005D
X-SSL-SNIHost	The value of the received SNI name.	sni.test.com

These headers are added to the client request after load balancing has been performed on the client request; therefore, these headers are not available to content rules defined on the top-level Virtual Service (VS). They're available to content rules defined within a SubVS, and to rules defined in a 'nested' VS.

So, for example, if you want to add these headers to a client request and then use the header values to select the SubVS to which to send the client request, this can be acomplished through a second, 'nested' VS. Requests come in to the first VS, which has this option enabled and inserts the headers. This first VS has a Real Server defined in it that is actually the IP address of a second VS. Content rules are defined on the second VS which can then use the X-SSL header values that were injected by the first VS to send the request to a specific SubVS.

DHCPv6 Support

Support for DHCPv6 (Dynamic Host Configuration Protocol for IPv6) has been added for initial LoadMaster deployment and can optionally be enabled afterwards, if required.

On initial deployment, both DHCPv4 and DHCPv6 are enabled and attempt to obtain an IP address. After an IP address is obtained (either via DHCP or by assigning the fallback IPv4 address of 192.168.1.101), DHCP is disabled and will remain disabled until manually reactivated via the API or using the Enable DHCPv6 Client check box on the System Configuration > Logging Options > System Log Files > Debug Options page of the UI.

When this option is enabled, the DHCPv6 client runs on the primary interface to obtain an IPv6 address and will remain running across subsequent reboots until this option is disabled. It is recommended that DHCPv6 be disabled after an IPv6 address is obtained, unless you are running the system within an IPv6 network where running DHCPv6 during normal system operation is required.

RADIUS 2-Factor Plus LDAP Authentication

LoadMaster now supports RADIUS 2-factor plus LDAP authentication for Single Sign On (SSO). To configure this:

• Select RADIUS and LDAP as the Authentication Protocol when adding or modifying a client-side Single Sign On (SSO) domain in Virtual Services > Manage SSO. If the RADIUS server is configured to use two-factor authentication, the LoadMaster will detect this automatically and perform RADIUS two-factor authentication.
• Set the LDAP Endpoint and RADIUS Server(s) for this SSO domain. Note that LoadMaster will use the credentials specified for the LDAP Endpoint configuration to contact the RADIUS and LDAP servers and verify client SSO credentials. So, these administrative credentials must be configured on all the RADIUS and LDAP servers in the domain.
• Select Exchange or Blank as the SSO Image Set in the ESP Options section of the Virtual Service Modify screen.
• Set the other parameters as appropriate for your configuration.

Content Rule Page Updates

A number of usability improvements have been made to the content rule functionality based on customer feedback. These enhancements are summarized below:

• It is now possible to duplicate a content rule.
• There is now an In Use column on the Content Rules page that indicates rule usage:
  • The star icon means the content rule is not assigned to any Virtual Services
  • The tick icon means the content rule is assigned to at least one Virtual Service. The number of assigned Virtual Services is displayed next to the tick icon. Hover over the tick icon to display the list of Virtual Services to which this content rule is assigned. [Note that the hover text only displays the first 20 assigned Virtual Services.]
• Error handling for content rule creation has been improved - more detail is now provided when a content rule fails to get created.
• It is now easier to reorder the priority of rules within a Virtual Service, using a new move option that allows you to specify the position to which the rule should be moved. Numbers are displayed on the page showing the content rules assigned to a Virtual Service to indicate the priority.

Ability to use SNI in SubVS, as well as SNI-Hostname Pass Through

The Server Name Indication (SNI) feature has been enhanced to support the following:

• The ability to pass through the original hostname as the SNI hostname to the Real Server.
• The ability to specify a different (manual) SNI hostname per SubVS. This is the same as the previous functionality to specify this on the parent Virtual Service (Reencryption SNI Hostname) but on the SubVS level with content switching.

These new features help with scenarios where you may want to consolidate as many services as possible to the least amount of IP addresses.

The Pass through SNI hostname check box is available in the SSL Properties section of the Virtual Service modify screen. When this is enabled and when re-encrypting, the received SNI hostname is passed through as the SNI to be used to connect to the Real Server. If the Virtual Server has a Reencryption SNI Hostname set, this overrides the received SNI. It is also possible to set the Reencryption SNI Hostname in a SubVS (in the Basic Properties section). If it is set in a SubVS, this overrides the parent Virtual Service value and/or the received SNI value.

Permitted Groups in Multi-Domain Environment

In previous releases, values specified for the Permitted Groups parameter in the Virtual Service ESP Options must be groups defined within the same domain (or sub-domain) in which the user profile is defined, or the group check will fail. With this release, a new Multi-Domain Permitted Group Check option has been introduced within ESP Options. Once enabled, LoadMaster will check for permitted group membership within all sub-domains under the top-level domain. This option is disabled by default.

HTTP/HTTPS Health Check OPTIONS Method Support

A new HTTP/HTTPS health check option has been added to the Real Servers tab for all Virtual Services. When the Real Server Health Check Method is set to either HTTP Protocol or HTTPS Protocol, a new OPTIONS setting is available for the HTTP Method parameter. This specifies that the server will be marked up when LoadMaster receives a 200 OK in response to an HTTP (or HTTPS) OPTIONS request sent by LoadMaster.

The OPTIONS HTTP method requests a description of the permitted communication options from the server. A 200 OK response from the server contains a response body which can be optionally searched for specific text in order to provide an additional check. To search the response body, specify the search text in the Reply 200 Pattern text box that appears when you select the OPTIONS HTTP method. The server will be marked up if the provided text is found in the response body; otherwise, the server is marked down.

Quality of Service DSCP Pass Through Support

Support for the Differentiated Services Code Point (DSCP) architecture in previous releases allowed the setting of a specific DSCP option via the Virtual Service Quality of Service option (under Standard Options). A new option, Pass Through, has been added to the Quality of Service drop-down to support DSCP settings passed to LoadMaster in the client connection. When this option is enabled and there is a DSCP option received in a client request, LoadMaster will pass that DSCP option on to the server.  

GEO: DNS TXT Record Support

GEO has been enhanced to support a single Domain Name Service (DNS) TXT record that will be returned whenever GEO answers a TXT record request for any domain defined within GEO. A TXT (text) record is essentially unformatted data that can be used for almost any purpose, but typically contain information to be consumed by clients to classify a domain in some way, provide details about a domain, or specify resources available within a domain.

A new TXT Record parameter has been added to the Global Balancing > Miscellaneous Params UI page. In this release, the field is limited to a single string of 127 ASCII characters (without quotes). Multiple quoted strings and non-ASCII characters are not allowed. Future releases will expand TXT record functionality.

Change Notices

Best Practices Cipher Set Updated

In LoadMaster firmware version 7.2.52, the BestPractices cipher set was updated. The cipher set is now based on the recommendations provided in the Use Secure Cipher Suites section of the following SSL Labs article: SSL and TLS Deployment Best Practices. The following table shows the ciphers that remain in the BestPractices cipher in LMOS 7.2.52 in the left column, and the ciphers removed from the set in the right column:

Carried Forward	Removed
ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-ECDSA-AES256-SHA384 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-ECDSA-AES128-SHA256	DHE-RSA-AES256-GCM-SHA384 DHE-DSS-AES256-GCM-SHA384 DHE-RSA-AES256-SHA256 DHE-DSS-AES256-SHA DHE-RSA-AES256-SHA DHE-RSA-AES128-GCM-SHA256 DHE-DSS-AES128-GCM-SHA256 DHE-RSA-AES128-SHA256 DHE-RSA-AES128-SHA DHE-DSS-AES128-SHA256 ECDHE-RSA-AES256-SHA ECDHE-ECDSA-AES256-SHA ECDHE-RSA-AES128-SHA ECDHE-ECDSA-AES128-SHA

In addition to the above, the following two ciphers were added to the BestPractices set:

ECDHE-ECDSA-CHACHA20-POLY1305

ECDHE-RSA-CHACHA20-POLY1305

Adjustable Timeout for KCD Connections

In previous releases, when Server Side Authentication is set to KCD (Kerberos Constrained Delegation) in a Virtual Service's ESP Options, LoadMaster will always wait up to 2 seconds to determine whether or not the connection was rejected. Unfortunately, in configurations where large POSTs are common, this can lead to latency issues.

A new L7 Wait after POST parameter on the System Administration > Miscellaneous Options > L7 Configuration page of the UI allows you to set the time to wait for a server response, so that the timeout can be set appropriately for different configurations. The default value is 2000ms (or, 2 seconds). Valid values are 1 to 2000.

Per-VS Health Check Settings

In previous releases, health check settings were global-only, located on the Rule & Checking > Check Parameters UI page:

• Check Interval
• Connect Timeout
• Retry Count

These settings now also appear within the Virtual Service Real Servers tab, so that you can tune health check behavior for specific VSs and SubVSs. By default, real server health checks use the global settings, and so the VS or SubVS settings change as the global settings change (as in previous releases). Once you change a check parameter on a VS or SubVS, however, the VS or SubVS setting will remain unchanged regardless of changes made to the global setting. The UI indicates whether the currently in-use value is the global value or is set to a custom value.

Disabling SSL Master Secret Extension Handling

LoadMaster by default will process the SSL Master Secret Extension (as defined in RFC7627). This can cause problems for some legacy clients, so this behavior can be disabled by turning on the Disable Master Secret Handling option, found in the UI on the System Configuration > Miscellaneous Options > Network Options page.  Disable Master Secret Handling. By default, the LoadMaster processes the Master Secret SSL Extension.

Modified EC Curves in LoadMaster Client Hello

In previous releases, the LoadMaster proposed the following EC curves for ECDHE ciphers in the client hello:

• secp256r1
• secp384r1
• secp521r1
• x25519
• x448

The last two curves (x25519 and x448) are no longer supported to meet Common Criteria security requirements.

Enhanced HA Sync Parameters

When you select the Inter HA L4 TCP Connection Updates check box in the HA Parameters screen of the User Interface (UI), three new options appear: 

• L4 Sync Threshold: The minimum number of incoming packets that a connection must receive before the connection is synchronized. The range of the threshold is from 0 to (the Sync Period -1). The default value is 3. 
• L4 Sync Period: A connection is synchronized every time the number of its incoming packets modulus Sync Period equals the threshold. Valid values range from the Sync Threshold+1 to 255. The default value is 50. 
• L4 Sync Refresh Period: The difference (in seconds) in the reported connection timer that triggers a new sync message. Valid values range from 0-10. The default value is 0. 

When the Sync Period and Sync Refresh Period are 0, syncs are only sent for state changes or only once when the packets match the Sync Threshold. 

These settings might be useful in a scenario where a load balanced application is using an SSH session that requires a secure token. Adjusting these settings appropriately could prevent the SSH session from failing when a HA failover occurs. 

There are some other settings that should also be configured to support SSH sessions: 

• On LoadMaster, the Switch to Preferred Server option should be set to No Preferred Server. 
• An SSH keep-alive must be configured either on the client side (for example, ServerAliveInterval) or server-side (for example, ClientAliveInterval). 

Security Updates

The following changes to existing LMOS features and behavior have been made in this release to improve LoadMaster's security profile.

Best Practices Cipher Set Updated

See the section above under Change Notices.

GEO: Response Contains Internal IP Address

In LMOS Version 7.2.50 / GEO Version 2.3.50, a change was introduced that caused GEO responses to DNS requests for any FQDN defined within GEO to include an additional record that listed the internal IP address of a NATed LoadMaster, rather than the public IP address. This issue has been addressed by instead returning "0.0.0.0" in the additional records sections unless a specific IP4 or IPv6 address is configured in the Global Balancing > Miscellaneous Params > Glue Record IP text box.

Enhanced Server-Side KCD Authentication Cipher Option

A new option for server-side Kerberos Constrained Delegation (KCD) authentication improves the security of LoadMaster's server side KCD connections to meet evolving security policies.

In previous release, KCD was configured to use RC4, DES, and DES3 ciphers for server connections; these ciphers could not be modified. With this release, you can now enable the Use AES 256 SHA1 KCD Cipher option on the Virtual Services > Manage SSO UI page to specify that the RC4, DES, and DES3 ciphers be disabled for server-side KCD and that the aes256-cts-hmac-sha1-96 cipher be used instead. This option can be enabled/disabled as needed within different server-side Single Sign On (SSO) configurations.

Certificate Signing Request (CSR) Generation

In previous releases, both the unsigned Certificate Signing Request (CSR) generated by LoadMaster and the associated private key were displayed in the UI (or returned via the API). A new option has been provided to allow the private key to be managed more securely, preventing unintentional disclosure or improper handling of the private key by the user.

This new option appears only when the Certificates & Security > Remote Access > Self-Signed Certificate Handling option is set to EC certs with an EC signature -- which means that an elliptical curve cipher will be used for both the certificate and the digital signature.

Once the above option is selected, a new Display Private Key check box appears on the  Certificates & Security > Generate CSR UI page.

• When Display Private Key is disabled (the default), the private key is not displayed in the UI after the CSR is created. The unsigned CSR is downloaded by the user as in previous releases. Once it is signed by a Certificate Authority, the user uploads the signed certificate to the LoadMaster -- the difference from previous releases being that the user does not have to also upload the private key, since LoadMaster maintains it internally when Display Private Key is disabled. If the saved private key matches the new certificate, the certificate gets imported and the saved private key is deleted. The stored private key is not encrypted but there is no access to it from the outside and it cannot be seen or displayed.
• When Display Private Key is enabled, LoadMaster behaves as in previous releases: the private key is displayed to the user and must be uploaded to LoadMaster along with the private key.

Syslog and LDAPS Server Certificate Validity Checking

LoadMaster has been modified to use OCSP to check the validity of the server certificates supplied by syslog and LDAPS servers configured into the configuration. If these checks fail, connections to the server are not permitted.

Enhanced Random Number Generator Seeding

In previous releases, seeding the system random number generator was performed on all platforms using entropy sources that were available directly to the kernel after boot, providing an acceptably high level of entropy. Best practices in the industry (e.g., Common Criteria) have evolved to generally recommend that, when available, systems running on Intel architectures take advantage of Intel's Digital Random Number Generator (DRNG) software to provide additional entropy sources from the processor at boot time.

LoadMaster has been enhanced to attempt to use the Intel DRNG architecture's RDSEED and RDRAND processor instructions to provide additional entropy for seeding the random number generator. This behavior is disabled by default; to enable:

1. In the UI, navigate to Certificates & Security > Remote Access.
2. Set the Self-Signed Certificate Handling option to EC certs with an EC signature.
3. Reboot LoadMaster.

On the next boot, LoadMaster will attempt to use RDSEED as an entropy source and, if that fails, RDRAND. If successful, the message sslproxy: Initial Random Vector appears in the system log.

All current LoadMaster hardware supports either RDSEED or RDRAND, as do many legacy hardware platforms. Whether or not this option can be used for a Virtual, Cloud, or Bare Metal LoadMaster deployment depends entirely on the processor of the hardware platform on which the hypervisor is running.

If the processor does not support RDSEED/RDRAND, then LoadMaster becomes unavailable due to the lack of an "approved" entropy source. The following occurs:

• The UI displays only this message (no functionality):
  
  Could not start CC mode - system disabled.
• A CRITICAL log message is created in the messages file:
  
  Cannot initialize RNG, CC mode disabled.
• An authlog messages is also created.
  
  Failed to start RNG, CC mode not started.

To get out of this mode, you have to log into the system console, navigate to the Local Administration > Web Address screen, and select Confirm switch out of CC mode. Once the system restarts, you will be able to access the system as usual, but it will not operating in Common Criteria mode -- the kernel will generate entropy after boot as in previous releases. This is evidenced by the following authlog message:

 

Enhanced NTP Key Exchange Algorithms

The SHA-1 hashing algorithm has been added to the key types supported for NTP on the System Configuration > System Administration > Date/Time UI page. Click Show NTP Authentication Parameters to display the NTP Key Type parameter. Note that, in previous releases, SHA-1 was presented as a choice, but this was actually implementing the legacy SHA (a.k.a. SHA-0) hashing algorithm. This has also been corrected in this release, so that the three key types supported are now: MD5, SHA-1, and legacy SHA.

 

Issues Resolved

The following issues from previous LMOS releases have been addressed in this release.

PD-15788 PD-15337	Login Security: Fixed a bug that caused two issues: (1) the Failed Login Attempts parameter is ignored and users are not getting locked out; and, (2) it is possible under specific circumstances for a user to be logged into another user's current session.
PD-15689	MELA: Fixed an issue that caused the LoadMaster MELA Activation Check to fail when LoadMaster contacts Kemp 360 Central.
PD-15648	Logging: Fixed an issue where the full path of an intermediate certificate is recorded in the log when the certificate is deleted.
PD-15618	Clustering: Fixed an issue that prevents adding a LoadMaster to an existing cluster if packet filtering is enabled.
PD-15585	SSL: Fixed an issue that, starting with LMOS 7.2.49, caused TLS 1.3 to be offered to clients even though it was disabled on the VS.
PD-15578	NTLM: In previous releases, when NTLM is enabled on a VS, the LoadMaster reads the request headers, determines that the Authorization header is not present, and sends a 401 reply without waiting for any in-transit client data (such as a POST) to complete. This has been fixed; LoadMaster will now wait for all data before sending a response.
PD-15563	Base System: Fixed an issue that caused spurious “kernel: hpet1: lost x rtc interrupts” messages to be seen in the logs.
PD-15521	GEO: Fixed issues with DNS requests returning the eth0 IP address and nonexistent NS/SOA names. These issues were introduced in LMOS 7.2.49.1. As part of this work, a new check box was added to Global Balancing > Miscellaneous Params called Apply to Zone Only. When disabled (the default), the SOA parameters are returned for all Fully Qualified Domain Names (FQDNs). If this option is enabled, the Source of Authority (SOA) parameters are returned only for queries on the Zone.
PD-15496	WAF API: Fixed an issue where the getwafsettings call returns a different date for the last WAF update than is seen in the UI.
PD-15495	VS Alternate Source Addresses: In previous releases starting with LMOS 7.2.50, if a VS had a very large number of connections, an internal error could cause the LoadMaster to ignore the Alternate Source Address. This problem has been fixed.
PD-15493	WAF: Fixed an issue where WAF enabled in audit mode is breaking connections to virtual services when the received data is in chunked format.
PD-15473	API: Fixed an issue that caused API calls containing files to fail if the API port is changed to anything other than 443.
PD-15471	API: Modified the ping, ping6, and traceroute APIs to support an FQDN or hostname as input.
PD-15470	GEO / DNS: Fixed an issue where the name resolution cache was not being flushed when the configuration was reloaded.
PD-15466	API: Fixed an issue with the getraidinfo and getraiddisksinfo APIs, where the response contained HTML-encoded angle brackets, instead of ASCII-encoded brackets.
PD-15451	GEO API: Fixed an issue (in the API only) where deleting a search domain using searchlist  resulted in a configuration file with a blank search entry.
PD-15413	SSO: Fixed an issue that caused spurious ssomgr log messages containing “transcode_credentials_for_basic” if the Logon Transcode option is enabled on an SSO domain and a related VS is set to use Basic Authentication in ESP Options.
PD-15315	Powershell API: Added MatchBodyPrecedence and MatchBodyPrecedencePos parameters to the modvs command, so that body response rules can be promoted through the PS API.
PD-15312	API: The ability to upload an Error File for Not Available Redirection Handling in a Virtual Service or SubVS has been added to the API. (This functionality was added to the UI in a previous release).
PD-15281	API: Added IP address validation for the localbindaddr parameter value used in addvs and modvs.
PD-15235	GEO: Fixed an issue that caused location co-ordinates on a Site to be changed after disabling and re-enabling the GSLB feature. Location co-ordinates now persist after disabling and re-enabling GSLB.
PD-15118	SSH Load Balancing & Failover: Load balanced SSH session fails when a failover occurs. The SSH connection was disconnecting after 3 to 4 attempts of fail-over. This issue has been fixed so that the SSH Connection is maintained across a failover caused by hardware failure.
PD-14951	ESP Single Sign On: Fixed an issue that could cause Virtual Services to become unresponsive, accompanied by this message in the logs: "ssomgr: ERROR: ssomgr too many threads:128".
PD-14339	WAF: Fixed logging issues when disabling WAF remote logging, as well as redundant enable/disable log messages.

 

New Known Issues

The following issues appear for the first time in this release of LMOS.

PD-15872	LDAP/Syslog: StartTLS is not working when the Server Certificate Validation flag is enabled.
PD-15633	GEO: If you add a Zone Name to GEO after you have created working FQDNs, GEO may no longer respond to queries for one or more of the FQDN safter the Zone Name is added. The workaround is to remove and then re-add the FQDNs that are no longer working.
PD-15475	VS Redirects: If you attempt to upload a new redirect error HTML file to a Virtual Service with Not Available Redirection Handling enabled while traffic is currently being redirected, then traffic to the VS is dropped. Click the Error Message radio button in the UI and the VS begins accepting connections again.
PD-15396	GEO: LM sends a spurious "KEMP GEO" TXT record in DNS responses if the TXT record field is empty and the queried FQDN is not a sub-domain of the ZoneName.
PD-15367	TLS 1.3 Hardware Acceleration Performance: On the LM-X15 and LM-X25 hardware LoadMasters with a hardware SSL accelerator card installed, lower TLS 1.3 performance has been observed after upgrading to LMOS Versions 7.2.48.1 and above. The workaround is to disable the hardware acceleration card and use software SSL acceleration, which will provide improved performance. Please contact Kemp support for instructions.
PD-15354	SSO Timeout: In LMOS 7.2.51, a fix was introduced for issues that caused an SSO client to not be properly logged out when the configured session timeout expires. It has been observed that while sessions do timeout, they are not always closed immediately upon the expiry of the timer; it can take close to a minute longer for the session to actually be closed.

 

Existing Known Issues

The following issues appeared in the Release Notes for the previous release of LMOS.

PD-15294	ESP Verify Bearer Header: LoadMaster does not return an error when an encrypted token is received and there is no SSL certificate assigned to the VS to decrypt the token.
PD-15172	ESP Verify Bearer Header: Validation is not working when "Allowed Virtual Hosts" and "Allowed Virtual Directories" are blank on the Virtual Service.
PD-14943	Single Sign On: When Form Based Authentication is enabled on the server side, it is possible that after filling out correct credentials and submitting the login form, the form will be presented again; once the second login form is submitted with correct credentials, the login succeeds.
PD-14256	SNMP: The VS and RS IN/OUT OIDs are not displaying any data.
PD-12838	ESP / SSO: The ESP Permitted Group SID(s) setting is not working as expected when configured on a subVS.
PD-12616	WAF / Compression: With Web Application Firewall (WAF) enabled, compressed files are incorrectly decompressed. As a workaround, ensure compression is enabled in VS Advanced Properties by selecting the Enable Compression option.
PD-12492	Downgrade: If an Azure VLM is downgraded to the LTS firmware release (7.1.35.x), the WUI may display in the top right-hand corner that the VLM is a Hyper-V VLM. This indicates that the Azure VLM Add-On Package must be added to the system to provide full Azure VLM functionality. If this occurs, please contact Kemp Support to get the required add-on package.
PD-12354 PD-10466	Hardware Support: The LoadMaster models LM-X15, LM-X25, and LM-X40 do not support the following SFP+ modules: LM-SFP-SX (SFP+ SX Transceiver 1000BASE-SX 850nm, 550m over MMF), LM-SFP-LX (SFP+ LX Transceiver 1000BASE-LX 1310nm, 10KM over SMF).
PD-12237	HA / NTP: Configuring NTP for the first time after the system is running in High Availability (HA) mode and when the current time on the machines is not correct, may cause the systems to both go into the Master state.
PD-12147	ESP / RADIUS: In a LoadMaster configuration with ESP and Radius server-side authentication enabled, sessions may fail to be established.
PD-12058	Browser Support: An issue exists when connecting to the LoadMaster WUI when using newer versions of the Firefox browser on initial configuration of a hardware FIPS LoadMaster.
PD-11861	RADIUS / IPv6: IPv6 is not supported by the current RADIUS implementation in the LoadMaster for both WUI Authorization and ESP Authentication.
PD-11166	Networking: Azure LoadMasters are not translating the additional network address between the Master and Slave correctly.
PD-11044	Sharepoint Virtual Services: A second authentication prompt is presented when a file is uploaded to SharePoint with the following configuration: WAF is configured with Process Responses enabled on the main Virtual Service and KCD is enabled on the SubVS level for server-side authentication.
PD-10917	HA: An issue exists when setting up a 2-armed HA Virtual LoadMaster in Azure.
PD-10784	HA: Configuring LoadMaster HA using eth1 on an Amazon Web Services (AWS) Virtual LoadMaster does not work.
PD-10586	GEO: If a GEO FQDN is configured with All Available as the Selection Criteria, IP addresses are returned even if the cluster is disabled.
PD-10490	Content Rules: The vsremovewafrule RESTful API command does not allow multiple rules to be removed.
PD-10474	Intrusion Detection: A SNORT rule is triggering a false positive in certain scenarios.
PD-10193	Exchange 2010 Virtual Services: A WAF, ESP, and KCD configuration with Microsoft Exchange 2010 is not supported.
PD-10188	Browser Support: (Safari) When adding a Real Server to a Virtual Service or SubVS using the Safari browser, the list of available Real Servers is not available.
PD-10159	Statistics: When upgrading firmware from version 7.1.35.n, CPU and network usage graphs are not appearing. As a workaround, reset the statistics in the WUI.
PD-10136	Clustering: In a LoadMaster cluster configuration, a new node can be added with the same IP address as an existing node.
PD-9816 PD-9476	WAF: There is an API command to list individual rules in a ruleset, but there is no command to list the available rulesets themselves.
PD-9765	GEO: DNS TCP requests from unknown sources are not supported.
PD-9507	Networking: Unable to add an SDN controller using the RESTful API/WUI in a specific scenario.
PD-9375	Sharepoint Virtual Services: Microsoft Office files in SharePoint do not work in Firefox and Chrome when using SAML authentication.

 

Appendix A: Verifying Upgrade Image Signatures

This table shows you which XML file to use to verify the digital signature on an upgrade image, based on the currently running LMOS version and the version to which you want to upgrade.

Current Release	Use this file to verify the digital signature on the 7.2.52 update image
7.2.52	7.2.52.0.19393.RELEASE.PATCH-64-MULTICORE.checksum.xml
7.2.51	7.2.52.0.19393.RELEASE.PATCH-64-MULTICORE.checksum.xml
7.2.50	7.2.52.0.19393.RELEASE.PATCH-64-MULTICORE-pre7.2.51.0.checksum.xml
7.2.49.1	7.2.52.0.19393.RELEASE.PATCH-64-MULTICORE-pre7.2.51.0.checksum.xml
7.2.48.1 and below	Offline Validation Only

---

Comments