Version 24.06-10 March 31, 2025

Fixes

The following fixes are included in this release:

• Fixes an issue where the CPU would be higher than expected for traffic that is processed by a policy with action set to deny.

• Fixes an issue where a Multicloud Defense Gateway datapath could enter a stuck state when processing SMB traffic. When this occurs, the datapath will self heal. The fix addresses the issue such that the datapath does not enter the state and successfully processes SMB traffic.

• Fixes an issue with an Ingress Gateway Reverse Proxy Policy where a build-up of CPU could occur for a particular type of session behavior. If a successful end-to-end session is established and the client and server communicate and then each disappear without closing their respective sessions, the proxy will eventually close the sessions, but will not fully clean up the session allocation. This results in a build-up of CPU over time. If the session behavior occurs at a greater volume, the CPU could build-up more rapidly. This fix addresses the session cleanup to ensure the CPU does not build up over time and remains stable.

• Fixes an issue with establishing a full end-to-end session for legacy applications when using a TCP Forward Proxy Policy. Examples of legacy applications could include SSHv1 and database management traffic (Oracle). For these types of applications, after the TCP connection is established, the next packet will arrive from the server, not the client. In a TCP Forward Proxy Policy, the Multicloud Defense Gateway first establishes the frontend TCP connection (client-to-gateway) and expects the next packet to arrive from the client, not the server. Since no packet ever arrives, the backend TCP connection (gateway-to-server) is never established. This results in no end-to-end session and the application communication will fail.

  This fix addresses the issue in the following two ways: (1) enabling a gateway setting and (2) evaluating the policy rule that is processing the traffic to determine if a domain evaluation (FQDN Match, FQDN Filtering) is configured. If both (1) and (2) are configured, the Multicloud Defense Gateway will assume the traffic will be TLS encrypted and the next packet to arrive will be the TLS Hello from the client. If just (1) is configured, the gateway will assume the traffic is not TLS encrypted, therefore it will not expect the next packet to arrive from the client, and will immediately establish the backend connection. The next packet to arrive, whether from the client or server, will have a full end-to-end session to process and send the packet to its intended destination.

  In the scenario where (1) is not configured, when the traffic is TLS encrypted and a domain is obtained from the TLS Hello SNI, the gateway does a domain resolution and use one of the resolved IPs as the destination for the backend connection. In the scenario where (1) is configured, or a scenario where traffic is not TLS encrypted, the frontend TCP connection destination IP will be used as the backend TCP connection destination IP since no domain can be obtained and no domain resolution is possible.

  In order to employ this fix, a gateway setting is required. If you feel you're running into this issue, please contact Cisco Support to evaluate and obtain information on how this setting can be enabled. In a future release, this behavior will be configurable on a per-rule basis, such that a rule can be created to segment this type of traffic, where the change described above can apply only to specific traffic.