Skip to content

Gateway Release: 25.02

25.02-02 - July 3, 2025

  • Enhancement: Adds support for M7i (2-core, 4-core, 8-core) instance type when deploying a Gateway in AWS. This enhancement accommodates Gateway deployments into recently introduced regions that require the latest M-class family. [VAL-16863]

  • Enhancement: Integrates the FIPs Teleport agent into the Gateway to accommodate both FIPS (FedRAMP) and non-FIPS (commercial) environments. Teleport is disabled by default. It can only be enabled by the customer when working in conjunction with Cisco Support for advanced troubleshooting. [VAL-14667]

  • Fix: Fixes an issue for traffic processed by a Forwarding policy with Network Intrusion (IDS/IPS) enabled. If a client uses a TCP RST to close the connection, there is a possibility that the RST will not be forwarded by the Gateway. This behavior could lead to application slow downs and timeouts. This fix ensures that the RSTs are properly forwarded through the Gateway to the destination. [VAL-18907]

  • Fix: Fixes a stability issue in the Gateway datapath that could cause the datapath to crash and restart. [VAL-18601]
  • Fix: Fixes an issue where active termination of a long-running flows during a policy change was not being applied properly, resulting in the connections being passively closed. This fix ensures that the long running sessions are actively terminated via a TCP Reset. [VAL-18563]
  • Fix: Fixes an issue with Anti-Malware detection that could cause high CPU, impacting the ability to process sessions. This issue could be seen if the protection is enabled for traffic processed by a Forward policy. This fix ensures that the anti-malware engine more efficiently processes traffic to properly detect malware without impacting performance. [VAL-18399]
  • Fix: Fixes an issue where disabling or enabling a Policy Ruleset Forwarding Rule causes a blue/green datapath replacement. In this scenario, a datapath replacement is not needed and the policy change should apply quickly with no impact to existing sessions. This fix ensures that this type of policy change is accommodated with no requirement for a blue/green datapath replacement. [VAL-18355]
  • Fix: Fixes an issue where an update to a certificate object would not apply the update to the Gateway. The Gateway would continue to use the old certificate until the Gateway instance is replaced or the datapath is restarted. This fix ensures the updated certificate is applied to teh Gateway policy and used for processing traffic. [VAL-18318]
  • Fix: Fixes an issue where a policy change that triggers a blue/green datapath replacement could cause longer than expected traffic processing delays that would result in the inability of the datapath to processing sessions. This scenario can occur when a policy uses DNS-based FQDN Address Objects with caching enabled on the Gateway and/or a diagnostic bundle is generated during the policy change. Each requires the datapath to service these requests in conjunction with processing sessions, causing delays in the latter. The fix ensures that the highest priority is given to the processing of the sessions to ensure no disruptions. [VAL-17887]
  • Fix: Fixes an issue where a Gateway policy change could become stuck in Updating state because the policy is incomplete due to lack of disk space. This scenario would only occur over a very long period of time that the Gateway instance is active. This fix addresses the root cause of the disk space issue so that long-running Gateway instances will successfully process policy changes. [VAL-17749, VAL-1991]
  • Fix: Fixes an issue related to dead connections causing higher than normal CPU and memory consumption. Dead connections are connections that are left open due to the client and server disappearing without actively closing or resetting the connection. The Gateway previously held onto these connections for up to 12 minutes, consuming connection pool capacity, causing an increase in CPU and memory, resulting in an unnecessary scale out to accommodate the additional capacity requirements. The fix is to introduce a tunable configuration to reduce the amount of time that dead connections are retained. If this scenario occurs, please contact Cisco Support to evaluate the scenario and adjust the setting to reduce the impact dead connections will have on the Gateway capacity. [VAL-17379]
  • Fix: Fixes an issue where an upgrade from a Gateway version that does not support VPN to a Gateway version that does support VPN could cause the new Gateway instances on the new version to not become active due to an instability related to populating route prefixes into the VPN route table. [VAL-17333]
  • Fix: Fixes an issue with an Ingress Gateway where a policy with WAF protection enabled could result in a disruption in traffic during a WAF ruleset update. This only occurs when the WAF Profile name is specified in a particular way. The fix addresses the issue by ensuring the name specified by the user, and permitted by the Controller/UI, is properly accepted by the Gateway ensuring no disruption during ruleset updates. [VAL-17155]
  • Fix: Fixes an issue where the CPU would be higher than expected for traffic that is processed by a policy with action set to deny. [VAL-17029]
  • Fix: Fixes an issue where a 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. [VAL-16928]
  • Fix: Fixes an issue where an Ingress policy that uses source IP/CIDR whitelisting would permit traffic from IPs outside of those whitelisted. [VAL-16887]
  • Fix: Fixes an issue with Data Loss Prevention (DLP) detection in multipart data. If the string being detected is at the file start or end, detection is successful. If anywhere else, then detection would fail. File size could also affect proper detection. This fix ensures that the string is detected in multipart data no matter where the string is located. [VAL-16886]
  • Fix: Fixes an issue for traffic processed by an Egress Gateway where DLP protection that has detected a malicious activity would mark the traffic as malicious, but the Events view for the session was missing the DLP event. This fix ensures the DLP event is represented in the session events. [VAL-16862]
  • Fix: 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. [VAL-16678]
  • Fix: Fixes an issue where a UDP session involving UDP fragmentation is not closed and cleaned up if a fragment is never received. [VAL-16583]
  • Fix: Fixes an issue where the Traffic Summary Log would not present the proper number of UDP fragments for a session where fragmentation is seen. [VAL-16484]
  • Fix: 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 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 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 will do 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. [VAL-15807]
  • Fix: Fixes an issue where an Azure Ingress Gateway could crash when the newly instantiated Gateway instance is becoming active. [VAL-15167]
  • Fix: Fixes an issue where traffic processing on an Ingress Gateway could cause high CPU resulting in an unnecessary auto-scale. The high CPU is a result of moving from a policy that initially processes a connection using an unencrypted HTTP proxy and then moving to an encrypted TCP proxy due to an HTTP redirection. [VAL-14852]

25.02-01 - February 28, 2025

  • Enhancement: Enhancement: Adds support for UDP fragmentation. This enhancement requires a Gateway setting to be enabled, which can be specified in the Terraform Gateway resource. [VAL-14474]
  • Enhancement: Improved session state summary information. Improvements include: Marking sessions that have been closed due to Gateway and proxy timeout sessions; Resetting all connections that have been closed by the Gateway for any reason (timeouts, datapath restarts); Sending connection reset to both client and server for sessions that have been closed by the Gateway; Session summary log generated periodically for long-running sessions. [VAL-14425]
  • Enhancement: Provides an enhanced Gateway image that supports the BoringCrypto required for use in Gateways deployed in a FedRamp. This is continued effort towards Multicloud Defense being FedRamp compliant. [VAL-14339]
  • Enhancement: Adds support for a custom banner to be displayed when an SSH session to the Gateway is established through Teleport. [VAL-14339]
  • Enhancement: Added support for logging the duration of a session in the Traffic Summary Log. The duration is from TCP SYN or first UDP packet to the time the session is closed or terminated. [VAL-13897]
  • Enhancement: Enhances the Network Intrusion (IDS/IPS) engine to detect and block HTTP evasion techniques, including HTTP 0.9, deflate compression, gzip compression, double compression (deflate + gzip), chunked transfer and HTTP/1.1 100 ok response code. [VAL-13463]
  • Enhancement: Provides an enhancement to honor the No Log Action of a Policy Rule Set Rule by not sending the Log to any destination configured in a Gateway-enabled Log Forwarding Profile. [VAL-11938]
  • Enhancement: Continued enhancements to Gateway hardening to accommodate STIG and CIS level 2 requirements necessary for deploying into FedRamp environments. [VAL-11341, VAL-11218]
  • Enhancement: Changed the base image from CentOS to RHEL9 to accommodate FedRamp requirements. This change will eventually be rolled into the non-FedRamp Gateway base image in a future release. [VAL-9183]
  • Enhancement: Adds support for periodically recording Traffic Summary Logs for long-running sessions. Historically, a Traffic Summary Log was recorded only when a session ends. This works well for shorter duration sessions, but not for long-running sessions. The enhancement generates a Traffic Summary Log every 5 minutes with the same session ID and tuple information, but with updated statistics (bytes/packets). A final Log will also be generated when the session ends. [VAL-9029]

  • Enhancement: Provides a Gateway setting for configuring the drain timeout. The default setting is 2 minutes. When applying this Gateway setting, the user can configure the drain timer. If there is a requirement to change the default, please contact Cisco Support. [VAL-8822]

  • Fix: Fixes an occasional datapath instability when processing client traffic where post-quantum cryptography is enabled. The instability would result in a datapath self-heal. The fix ensures datapath stability, resulting in no need to self-heal. [VAL-16246]

  • Fix: Fixes a downstream issue related to obtaining the SNI when a browser-based client has post-quantum cryptography enabled. The post-quantum cryptography scenario causes the TLS hello to be fragmented into multiple packets. If the first packet arrives, but the second packet does not, the Gateway would never release the session-allocated CPU upon session cleanup. This fix ensures that the CPU is released and does not build up over time. [VAL-15840]
  • Fix: 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 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 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 will do 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. [VAL-15807]
  • Fix: Fixes an issue with a Group Address Object exclusion list where the IPs/CIDRs specified in the excluded Address Objects were not properly applied to the Gateway policy. This ensures that both the included and excluded Address Objects are applied for proper traffic matching. [VAL-15757]
  • Fix: Fixes an issue where a Gateway in GCP could bounce between healthy and unhealthy due to Health Check Service failing, potentially resulting in instance replacement. [VAL-15541]
  • Fix: Fixes an issue where some long-lived active connections would not be properly reset (TCP RST) during Gateway replacement, policy change or timeout expiry. [VAL-14645]
  • Fix: Fixes an issue related to new Talos Rulesets where a Ruleset change could cause issues with applying the new Rulesets to the Gateway. The Gateway will become stuck in Policy Ruleset Status "Updating..." state. This issue was caught prior to new Talos Rulesets being published. The issue has is resolved with this update such that new Talos Rulesets can be successfully applied. [VAL-14879]
  • Fix: Fixes an issue where traffic processing on an Ingress Gateway could cause high CPU resulting in an unnecessary auto-scale. The high CPU is a result of moving from a policy that initially processes a connection using an unencrypted HTTP proxy and then moving to an encrypted TCP proxy due to an HTTP redirection. [VAL-14852]
  • Fix: Fixes an issue related to a UDP connection pool leak caused by specific UDP session behavior that could eventually result in a datapath restart. When the datapath restart occurs, the instance will be unhealthy for the duration of the restart. If that unhealthy period is long enough, the Controller will mark the instance for replacement. [VAL-14777]
  • Fix: Fixes an issue where an Egress Gateway Forward Proxy policy could get stuck in attempting to match traffic to the proper Policy Rule. [VAL-14677]
  • Fix: Fixes an issue where a Gateway could unnecessarily consume CPU in a proxy scenario where the backend connection is unresponsive causing delays in processing traffic. [VAL-14604]
  • Fix: Fixes a Gateway crash that is caused by detection of malware in an Ingress Gateway reverse proxy policy. [VAL-14573]
  • Fix: Fixes an issue where a TLS session that contains Kyber cipher suites could cause increased CPU usage resulting in the inability to process traffic. [VAL-14413]
  • Fix: Fixes a stability issue where the Gateway datapath could self-heal when proxied sessions are actively terminated during policy change or Gateway instance replacement. [VAL-14341]
  • Fix: Fixes an issue where the generation of a Diagnostic Bundle could fail. [VAL-14219] Fixes an issue where a Forwarding SNAT Policy could not retrieve the Service Name Indication (SNI) from a TLS Client Hello message causing the Gateway to close the connection with a TCP RST. This is caused by a change made in Chrome in April 2024 to shift to Post-Quantum Cryptography. With this change, the Client Hello is larger than 1415 bytes, which can result in an inability to retrieve the SNI, which is used by the policy to match or filter by domain. The fix ensures the Forwarding SNAT Policy can support Client Hello sizes greater than 1415 bytes. [VAL-14058]
  • Fix: Fixes an issue where a proxy policy could not retrieve the SNI from a TLS Client Hello message causing the Gateway to close the connection with a TCP RST. This is caused by a change made in Chrome in April 2024 to shift to Post-Quantum Cryptography. With this change, the Client Hello is larger than 1415 bytes, which can result in an inability to retrieve the Server Name Indication (SNI), which is used by the proxy to determine what certificate to issue. The fix ensures the proxy policy can support Client Hello sizes greater than 1415 bytes. [VAL-14041]
  • Fix: Fixes an issue where a change to DNS for a domain used in an FQDN-based Address Object would be received by the Gateway datapath agent, but not applied to the datapath workers. This would result in the DNS change not being applied to the dynamic nature of the Address Object, impacting proper traffic processing. [VAL-14006]
  • Fix: Fixes issues in the Anti-Malware engine where known malware was not being detected and blocked. The fix includes updating the anti-malware engine. [VAL-13921]
  • Fix: Fixes an issue where properly detecting malware signatures could occur intermittently. [VAL-13828]
  • Fix: Fixes an issue where the Gateway-side cipher suites used in a Gateway SSH session were potentially flagged as weaker cipher suites. The fix accommodates only the most secure GCM-based cipher suites. [VAL-13820]
  • Fix: Fixes an issue where a Decryption Profile that is configured differently than the default configuration would not properly apply to the Gateway, resulting in TLS negotiation failures due to cipher suite mismatches between the client and the Gateway. [VAL-13683]
  • Fix: Fixes the recording of Stats related to Active Connections and Connection Rate where UDP sessions were not being properly counted. [VAL-13486]
  • Fix: Fixes and issue where the Gateway will self-heal if an empty FQDN/URL Filtering Profile is assigned to the Policy Rule Set Rule. [VAL-13352]
  • Fix: Fixes a deny Rule Action issue related to the use of domains as a 6-tuple match. If the first Rule match is a 6-tuple match (includes an assigned FQDN Match Profile) and the Policy Action is set to Deny, the Deny action will be based on the 5-tuple match and will not include the domain for match consideration. This fix ensures that all 6-tuples are considered when evaluating the Rule and its action. If the traffic does not match the Rule based on the 6-tuple match, then it will refine its match to a subsequent Rule and take action based on the matched Rule's configuration. [VAL-12731]
  • Fix: Fixes an issue where an Azure Ingress Gateway will get stuck in Health Checking Pending state after a policy update is applied. This issue also includes new Gateway deployments. [VAL-12474]
  • Fix: Fixes an issue related to the use of GeoIP. Countries with many providers have a very large number of advertised prefixes. When those country codes are used in a GeoIP Address Group, the Address Group will contain a large number of CIDR blocks. The GeoIP Address Group was restricted to 64k CIDRs where exceeding this limit would result in a partial set of CIDRs applied to the policy. This fix relaxes the limit to ensure the full set of CIDRs will be applied to the policy. It is recommended to use an 8-core instance type due to the additional memory requirements imposed by GeoIP. [VAL-11872]
  • Fix: Fixes an issue where a Egress Policy Rule Set that uses an decryption-based Forward Proxy (TLS, HTTPS, WebsocketS) is initially matching on 5-tuple and retrieving the domain from the SNI, but not performing a match refinement based on the 6th tuple resulting in a TLS error. The fix ensures that 6-tuple match refinement occurs such that the traffic can be successfully processed by the proper decryption Rule. [VAL-11739]
  • Fix: Fixes an issue where sessions with TLS negotiation errors were not recording the SNI as a Traffic Summary -> Event. [VAL-11422]
  • Fix: Fixes an allow Rule match issue related to the use of domains as a 6-tuple match. If the first Rule match is a 6-tuple match (includes an assigned FQDN Match Profile), the Policy Action is set to Allow and there are no subsequent Rules that are consistent with the 5-tuple match of the first Rule, then all domains will be allowed and domains will be denied. This fix ensures that only the domains that are matched in the Rule will be allowed and all other domains will be denied. [VAL-11996, VAL-10848]
  • Fix: Fixes an issue where a TCP reset was not being sent for traffic processed by a Forward policy with a Deny action that uses an FQDN Match Profile when Reset on Deny is enabled. [VAL-10542] Fix: Fixes an issue where multiple SNI events were being recorded for each Forward Proxy full decrypted session. [VAL-10429] Fix: Fixes an issue where the Address Group size could be exceeded, causing all IPs/CIDRs in excess of the size to not be included in the Address Group. The Address Group size has been increased to 20k IPs/CIDRs. [VAL-10369]
  • Fix: Adds a System Log message if the GeoIP limitations of the Gateway are exceeded. [VAL-10365]
  • Fix: Fixes an issue where the wrong action would be taken for URL Filtering Category matching if a timeout occurs when attempting to retrieve the URL Filtering Category if the URL is not found in the cache. [VAL-9456]
  • Fix: Updating Gateway libraries to address various CVEs. [VAL-9419]
  • Fix: Fixes various issues related to update of private key for certificates when the certificate is configured to access the private key from a CSP service like Key Vault, Secrets Manager and KMS. This fix ensures that any update to the resource in the CSP service is detected by the Gateway for the Gateway to retrieve the update and during traffic processing. [VAL-9167]
  • Fix: Ensures that a user with administrator access to configure a URL Filtering Profile cannot use the custom URL response to inject Javascript. The fix enforces HTML encoding in the custom URL response. [VAL-8300]
  • Fix: Fixes an issue where changing the PCAP for a Web Protection (WAF) or Network Intrusion (IDS/IPS) Profile would unnecessarily trigger a blue/green datapath replacement. [VAL-8233, VAL-8234]
  • Fix: Fixes an issue where enabling or disabling PCAP in a Network Intrusion (IDS/IPS) Profile would unnecessarily trigger a blue/green datapath restart. [VAL-8232]
  • Fix: Fixes an issue where enabling or disabling SNAT in a Forwarding Service Object would unnecessarily trigger a blue/green datapath restart. [VAL-8230]
  • Fix: Fixes an issue where changing the name of an advanced security Profile (WAF, IDS/IPS, Anti-Malware, etc.) would unnecessarily trigger a blue/green datapath replacement. [VAL-8225]