> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aviatrix.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Aviatrix Controller 9.0.10 Release Notes

> Release Date: 22 June 2026

Release Date: 22 June 2026

Release Notes Last Updated: 5 October 2026

<Warning>
  **Azure gateway customers**: This release includes the MANA driver fix, which
  is a kernel-level change delivered only via an image upgrade. Performing a
  software-only upgrade to 9.0.10 does **not** install the new MANA driver. To
  pick up the fix, perform an image upgrade of all Azure gateways at this
  release. For details, see the <a href={"/docs/enterprise/" + "9.0" + "/reference/release-notices/field-notices/index#long-term-fix-mana-compatible-images-and-upgrade-groups"}>MANA Field Notice</a>.
</Warning>

## Corrected Issues in Aviatrix Release 9.0.10

<table>
  <thead><tr><th>Issue</th><th>Description</th></tr></thead>

  <tbody>
    <tr><td>AVX-65016</td><td>Fixed an issue where the firewall state did not recover from the Unaccessible state after the first vendor integration failure.</td></tr>
    <tr><td>AVX-65590</td><td>Fixed an issue where editing the tunnel count of a HPE spoke-transit peering with customized SNAT could cause approximately 100–120 seconds of traffic outage per gateway during tunnel re-creation.</td></tr>
    <tr><td>AVX-73742</td><td>Fixed an issue with Site-to-Cloud single-IP HA failover where the Controller could process stale tunnel status messages and continue failing over tunnels after the active gateway recovered, prolonging recovery time.</td></tr>
    <tr><td>AVX-74739</td><td>Fixed an issue where the database migration timeout during Controller upgrade was hard-coded at 15 minutes, causing upgrades to fail and roll back in large-scale deployments with thousands of gateways and tunnels. The migration timeout is now user-configurable.</td></tr>
    <tr><td>AVX-74990</td><td>Fixed an issue where upgrading the Controller software from version 8.0.40 or 8.0.50 could cause CPU load to spike due to a database schema migration being skipped during the upgrade, resulting in sluggish Controller UI performance.</td></tr>
    <tr><td>AVX-75117</td><td>Fixed a memory leak in the TrafficServer (ATS) process on gateways with DCF intrusion analysis and decryption enabled under high-concurrency traffic conditions that could cause the ATS process to crash and enter a restart loop.</td></tr>
    <tr><td>AVX-75135</td><td>Fixed an issue where tunnel status report processing on the Controller was slower after upgrading from version 8.0 to 8.1 due to increased database query overhead. The database queries have been optimized to restore processing performance.</td></tr>
    <tr><td>AVX-75136</td><td>Fixed an issue where enabling DCF intrusion analysis could cause unexpected traffic drops on gateways that did not meet the minimum memory requirements for Suricata. Traffic is no longer dropped on non-qualified gateways when intrusion analysis is enabled.</td></tr>
    <tr><td>AVX-75414</td><td>Fixed an issue where a background service responsible for collecting network topology data experienced unbounded memory growth, which could eventually cause the process to be terminated due to excessive memory consumption.</td></tr>
    <tr><td>AVX-75496</td><td>Fixed an issue where a Controller upgrade could fail during a database migration step if a corrupted VPC record was present in the Controller database, causing the upgrade to fail and trigger a rollback.</td></tr>
    <tr><td>AVX-75582</td><td>Fixed an issue where the Aviatrix Controller retried Azure RequestDisallowedByPolicy errors unnecessarily, causing event handler congestion and delaying gateway deployments.</td></tr>
    <tr><td>AVX-75607</td><td>Fixed an issue where a supporting certificate-management image was not pre-baked into the gateway AMI, causing gateway launch failures when the bootstrap identity certificate expired before the image could be pulled.</td></tr>
    <tr><td>AVX-76296</td><td>Fixed an issue in GCP global VPC environments where the Controller removed all gateway routes during routine gateway operations such as resize or image upgrade, causing extended traffic blackholing.</td></tr>
    <tr><td>AVX-76719</td><td>Fixed an issue where Controller restore operations could stall for approximately 30 minutes during the scheduler shutdown phase due to connectivity issues with AWS API endpoints or invalid/expired IAM credentials.</td></tr>
    <tr><td>AVX-76919</td><td>Fixed an issue where the gateway state synchronization service (`avx-gw-state-sync`) could crash if the gateway's DNS configuration was not yet fully initialized, temporarily interrupting state synchronization between the Controller and gateways.</td></tr>
    <tr><td>AVX-77011</td><td>Fixed an issue where existing user tags on gateway VM instances could not be deleted from the Controller UI or CoPilot UI. Tag deletions are now correctly applied on both AWS and Azure gateway VM instances.</td></tr>
    <tr><td>AVX-77109</td><td>Fixed an issue where launching a FireNet FQDN gateway after upgrading the Controller could cause the gateway to enter a config\_fail state.</td></tr>
    <tr><td>AVX-77419</td><td>Fixed an issue where importing a system-defined Distributed Cloud Firewall (DCF) ruleset, such as the V1 Policy List or the Kubernetes Policy List, into Terraform state as an `aviatrix_dcf_ruleset` resource and then destroying the imported resource could delete the underlying system-defined ruleset on the Controller. Deletion of these system-defined rulesets is now prevented at the Controller.</td></tr>
  </tbody>
</table>

## Known Issues in Aviatrix Release 9.0.10

<table>
  <thead><tr><th>Issue</th><th>Description</th></tr></thead>

  <tbody>
    <tr><td>AVX-62299</td><td>When upgrading from Controller version 7.1 to 7.2 or 8.0, Spoke Gateways with routing through a Public Subnet Filtering (PSF) Gateway may fail to upgrade and become unreachable if the PSF Gateway has not been upgraded first. This issue affects AWS environments where Spoke Gateway route tables are configured to point to a PSF Gateway.<br /><br />To avoid this issue, follow the correct upgrade sequence:1. Upgrade the PSF Gateway first.<br /><br />2. Wait for the PSF Gateway upgrade to complete successfully.<br /><br />3. Then upgrade the dependent Spoke Gateways.</td></tr>
    <tr><td>AVX-64868</td><td>In some scenarios involving rapid VRRP state transitions, the keepalived VRRP state may not be reported accurately to the Controller. This can result in temporary discrepancies between the actual VRRP status and what is displayed in the Controller UI, leading to confusion and difficulties during troubleshooting.<br /><br />**Impact:**<ul><li>Controller UI may show incorrect VRRP status such as both peers reporting `Primary` or `Initializing`</li><li>No impact on actual VRRP traffic handling or failover behavior.</li></ul>**Workaround:**<ul><li>Use diagnostic logs to verify actual VRRP state</li></ul></td></tr>
    <tr><td>AVX-66631</td><td>Transit gateways with large-scale tunnel deployments (1300+ tunnels) may experience extended traffic loss during image upgrades. Although the image upgrade completes successfully, traffic may remain down for several minutes afterward due to delayed tunnel reconfiguration.<br /><br />**Workaround:**<br /><br /><ul><li>Schedule maintenance windows to account for potential traffic loss beyond upgrade completion.</li><li>Consider staggering upgrades across transit gateways to reduce impact.</li><li>Monitor tunnel and route service status post-upgrade through CoPilot UI.</li></ul>**Impact:**<br /><br /><ul><li>Traffic loss may persist after image upgrade completes</li><li>Route service startup is blocked until all tunnels are sequentially reconfigured</li><li>Configuration push may time out with `Context cancelled during Phase 1 Create` error</li></ul></td></tr>
    <tr><td>AVX-67126</td><td>Dry-run validation may fail when upgrading the Controller from version 8.0.10 to 8.1.0 due to a gateway version mismatch error. This occurs when the upgrade path starts from 8.0.0, progresses to 8.0.10 successfully, but encounters a dry-run failure when proceeding to 8.1.0.</td></tr>
    <tr><td>AVX-70543</td><td>When HA-enabled spoke gateways have DPI/IDS or Layer7 policies configured with "Destination: Anywhere" and the destination smart group contains private CIDRs, the policies become invalid and cause traffic drops.<br /><br />**Affected Scenario:** Spoke gateways with HA enabled using DPI/IDS or Layer7 policies where destination smart groups include private CIDR ranges.<br /><br />**Impact:**<br /><br /><ul><li>All egress traffic matching the policy gets dropped</li><li>Network connectivity failures for affected traffic flows</li><li>Policy validation errors in gateway configuration</li></ul>**Workaround:** Modify the destination in DPI/IDS or Layer7 policies to use specific target addresses instead of "Anywhere" when the destination smart group contains private CIDRs on HA-enabled spoke gateways.</td></tr>
    <tr><td>AVX-70958</td><td>When clients use HTTP/2 connections, TrafficServer incorrectly reuses origin connections, potentially causing connection handling issues in MITM SNI verification scenarios.<br /><br />**Impact:**<ul><li>Origin connections may be shared inappropriately between different client requests</li><li>MITM SNI verification may not function as expected</li></ul>**Workaround:**<br /><br />Use both IP address and SNI instead of IP alone to ensure proper connection isolation.</td></tr>
    <tr><td>AVX-71559</td><td>When performing a batch gateway image upgrade in Azure, some gateways may fail during the upgrade process.<br /><br />**Impact:**<ul><li>Gateway image upgrades in Azure environments may partially fail, with some gateways reporting errors during the replacement process.</li><li>Affected gateways may show an error indicating that gateway information cannot be retrieved in Azure ARM cloud.</li></ul>**Workaround:**<br /><br />Retry the gateway image upgrade for the failed gateways individually rather than as a batch operation. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-71820</td><td>When deploying a load balancer–enabled VPN gateway with an overlapping VPN CIDR on Controller versions 8.0, 8.1, or 8.2, the gateway creation fails.<br /><br />**Impact:**<br /><br /><ul><li>VPN gateway deployment fails</li><li>Error message does not clearly indicate the root cause</li></ul>**Affected Scenario:** Load balancer–enabled VPN gateway deployments on Controller versions 8.0, 8.1, and 8.2.<br /><br />**Workaround:**<br /><br />Ensure that the VPN CIDR does not overlap with existing gateways behind the load balancer before deployment. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-72940</td><td>Creating a new gateway with the same name as an existing gateway may cause local files of the existing gateway to be deleted when the creation fails. The existing gateway name disappears from the Controller CLI when this issue occurs.<br /><br />This can break SSH access (sshgw) for the existing gateway.<br /><br />**Impact:**<br /><br /><ul><li>SSH access to the existing gateway may stop working</li><li>Gateway recovery may require manual intervention</li></ul>**Affected Scenario:**<br /><br /><ul><li>Gateway creation using a name that already exists</li></ul>**Workaround:**<br /><br /><ul><li>Do not reuse gateway names</li><li>Contact [Aviatrix Support](https://aviatrix.com/support) if recovery is required</li></ul></td></tr>
    <tr><td>AVX-73334</td><td>After upgrading a VPN gateway image to Controller 9.0 with FIPS 140-3 enabled, the Aviatrix VPN Client (AVPNC 2.17.7, which uses OpenVPN 2.4.9) cannot connect to the gateway and returns `AUTH_FAILED — client incompatible with this server`. FIPS 140-3 on the gateway side requires OpenVPN 2.6.0 or later (RFC 5705 TLS Keying Material Exporters), which AVPNC 2.17.7 does not support.<br /><br />**Impact:**<ul><li>All VPN users running the Aviatrix VPN Client (macOS and Windows) cannot connect to a 9.0 VPN gateway with FIPS 140-3 enabled.</li><li>**For deployments that must remain in FIPS mode**, no client-side workaround is available. An updated Aviatrix VPN Client built on OpenVPN 2.6.x is required. A new client is in development; this RN will be updated when it ships.</li><li>Third-party VPN clients built on OpenVPN 2.6.0 or later are not affected.</li></ul>**Workaround:**<ul><li>**Non-FIPS deployments**: use a third-party OpenVPN 2.6+ client (e.g., Tunnelblick on macOS); or, if compliance allows, disable FIPS on the VPN gateway before the image upgrade.</li><li>**FIPS-required deployments**: roll back the VPN gateway to 8.2.x, or disable FIPS on the gateway, until the updated Aviatrix VPN Client is available. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</li></ul></td></tr>
    <tr><td>AVX-73436</td><td>When using the update\_spoke\_vpc\_route\_table API to onboard an Azure route table, the default route (0.0.0.0/0) is not programmed in the spoke VNET route table if the Spoke Gateway has learned the default route from any of the following sources:<br /><br /><ul><li>An attached Egress Transit Gateway (Transit with egress functionality enabled)</li><li>A Transit Gateway that learned the default route via an external Site-to-Cloud (S2C) connection (for example, from an on-premises network or third-party appliance advertising 0.0.0.0/0 over IPSec/BGP)</li><li>Another Spoke Gateway that is propagating the default route within the Aviatrix network</li></ul>In all of the above cases, although the Spoke Gateway has successfully learned and installed the default route in its own routing table, the route is not re-programmed into the associated Azure VNET route table during the onboarding operation.<br /><br />**Impact:**<br /><br /><ul><li>Default route (0.0.0.0/0) is not installed in the onboarded Azure spoke VNET route table.</li><li>Traffic that depends on the default route, including traffic destined for the internet through an egress transit, for on-premises networks through an S2C-connected transit, or for another spoke, may not be routed correctly from the Azure VNET.</li></ul>**Workaround:**<br /><br />Manually add the default route to the Azure route table. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-75586</td><td>When using Terraform to create gateways and immediately attach them to transit gateways, a race condition can occur where the Terraform provider attempts to create the spoke-to-transit attachment before the gateway has fully transitioned to the "Up" state. The gateway creation API returns before the gateway is operationally ready, causing subsequent attachment operations to fail.<br /><br />**Impact:**<ul><li>Terraform-driven spoke-to-transit gateway attachments may fail intermittently</li><li>Gateway creation appears successful but the gateway is not yet operationally ready</li><li>Terraform apply operations may require re-running to complete successfully</li></ul>**Workaround:**<br /><br />Add a delay or polling mechanism in Terraform configurations between gateway creation and spoke-to-transit attachment resources. Use `depends_on` with a `time_sleep` resource to allow the gateway to reach the "Up" state before attempting attachment.</td></tr>
    <tr><td>AVX-75599</td><td>The TrafficServer (ATS) process on gateways may crash with a signal 6 (Aborted) when a custom Suricata rule feed containing a large number of rules (20,000+) is applied to a DCF intrusion analysis profile. The crash occurs due to an assertion failure in the IDS inspection queue handling, causing traffic interruption on affected gateways.<br /><br />**Impact:**<ul><li>ATS process crashes and enters a restart loop on gateways with large custom Suricata rule feeds</li><li>Traffic is interrupted during ATS process restarts</li><li>Gateways using the system default IPS profile are not affected</li></ul>**Workaround:**<br /><br />Reduce the number of custom rules to under 1,000, or remove the custom rule feed from the intrusion analysis profile and use the system default IPS profile until a fix is available in a future release. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-76132</td><td>Unable to configure more than one OpenVPN gateway behind a UDP Load Balancer. Only the first gateway is retained while additional gateways are incorrectly excluded. This issue affects versions 6.9, 7.x, 8.x, and 9.0.0.<br /><br />**Impact:**<br /><br /><ul><li>Multi-gateway VPN deployments relying on UDP load balancing for redundancy or scale are affected.</li><li>No impact on single-gateway deployments or data plane traffic.</li><li>Existing multi-gateway configurations set up in 6.x continue to function after upgrading to 7.x or 8.x. Only new deployments or modifications to existing configurations are affected.</li></ul>**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance in applying the workaround.</td></tr>
    <tr><td>AVX-76413</td><td>**Description:** When the `avx-ctrl-state-sync` service starts up and finds gateways stored as "Down" in etcd, the controller reprograms the network as if those gateways are down, without allowing time for the gateways to connect and prove they are up. This can occur when the controller has previously lost connectivity to gateways (for example, during a transient network issue) and the service then restarts while the gateways themselves remain healthy and continue forwarding traffic.<br /><br />**Impact:** A temporary data plane disruption occurs while the controller has the gateways marked as down. The controller automatically detects the gateways are up and reprograms the network correctly immediately afterward. In a large-scale user deployment (\~1,400 gateways), full recovery completed in approximately 6 minutes. The underlying behavior has existed for 4+ years and has been observed in a user environment only once.<br /><br />**Workaround:** Not applicable. The system recovers automatically, no user action required. Recovery typically completes within minutes (\~6 min observed in a \~1,400-gateway deployment; smaller deployments recover faster).</td></tr>
    <tr><td>AVX-77135</td><td>When the **Use SSL to connect** option is enabled for LDAP configuration, VPN gateway configuration updates may not apply correctly.<br /><br />**Impact:**<ul><li>VPN gateway authentication using LDAP with TLS may not function as expected</li><li>Manual intervention may be required to ensure VPN authentication is properly configured</li></ul>**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-77618</td><td>Running Controller diagnostics may report NTP-related errors that do not reflect the actual NTP synchronization status of the Controller.<br /><br />**Impact:**<ul><li>Controller diagnostics output may show NTP errors even when time synchronization is functioning correctly.</li><li>These spurious diagnostic messages may cause unnecessary concern when reviewing Controller health output.</li></ul>**Workaround:**<br /><br />Verify Controller time synchronization through other means before acting on NTP-related diagnostic errors. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-77714</td><td>When creating a Smart Group with the Kubernetes workload resource type, attempting to use Region, Account Name, or Account ID as a match criterion fails with error AVXERR-SMARTGROUP-0007 ("invalid selector combination for k8s resource type"). Region, Account Name, and Account ID are not supported selectors for the Kubernetes workload resource type.<br /><br />**Impact:**<ul><li>Smart Groups for Kubernetes workloads cannot be created using Region, Account Name, or Account ID as the match criterion.</li></ul>**Workaround:**<br /><br />Use one of the supported Kubernetes workload selector combinations (cluster ID, namespace, service, or pod, alone or in supported groupings) when creating Smart Groups. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-78190</td><td>When upgrading the Aviatrix Controller from version 8.2.x to 9.0.10 in GCP environments, the upgrade may fail during the database migration phase because an internal security-group configuration value is stored in a format the migration code does not expect. This causes a JSON unmarshalling failure in the security group configuration migration step.<br /><br />**Impact:**<br /><br />Controller upgrade from 8.2.x to 9.0.10 fails in GCP environments; the security group configuration migration step fails with a JSON unmarshalling error. This issue is specific to GCP controllers. AWS and Azure controllers are not affected.<br /><br />**Workaround:**<br /><br />This is a permanent Known Issue for Controller 9.0.10; no additional 9.0.x release is planned to address it. The recommended fix is to upgrade to Controller 10.0.1. If you must stay on Controller 9.0.10, you can work around the upgrade failure by temporarily disabling the **Controller Access Security Group Management** feature before upgrading from 8.2.x to 9.0.10, and re-enabling it after the upgrade succeeds. Otherwise, contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-78500</td><td>When Distributed Cloud Firewall (DCF) is disabled on a gateway, DCF policy enforcement may not be fully removed from all gateway interfaces. As a result, traffic can continue to be evaluated against the previously applied DCF policy even though DCF appears disabled. This can occur when DCF is disabled without any accompanying policy change.<br /><br />**Impact:**<br /><br />\* After DCF is disabled, a gateway may continue enforcing the last applied DCF policy on some interfaces.<br />\* This residual enforcement is not reflected in the DCF status shown for the gateway and may persist until DCF is re-enabled or the gateway configuration changes.<br /><br />**Workaround:**<br /><br />When disabling DCF, also make a minor DCF policy change (for example, add and then remove a rule) so enforcement is fully cleared from all interfaces. If you suspect DCF policy is still being enforced after disabling DCF, contact [Aviatrix Support](https://support.aviatrix.com/).</td></tr>
    <tr><td>AVX-78616</td><td>When a single gateway image-upgrade or delete request includes both members of an ActiveMesh-enabled HA pair (a primary gateway and its HA peer), the operation can partially fail.<br /><br />**Impact:**<br /><br />Gateways in the request are processed in parallel, so whichever gateway in the pair is drained second fails with an error similar to: `Cannot drain <gateway-name> as it is the last undrained gateway in the group.`<br /><br />**Workaround:**<br /><br />Submit gateway image-upgrade or delete requests with primary gateways and HA gateways grouped into separate requests, rather than including both members of an ActiveMesh HA pair together. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-78671</td><td>Enabling Logging on the Default Action Rule and then disabling it can cause the Monitor tab to continue showing log entries for that rule for up to one hour after Logging is turned off.<br /><br />**Impact:**<br /><br />\* After you disable Logging on the Default Action Rule (following a period when Logging was enabled and traffic was flowing), the Monitor tab continues to display log entries for that rule for up to one hour.<br />\* Excess log volume during that hour can make it harder to review logs for other Distributed Cloud Firewall (DCF) rules.<br /><br />**Workaround:**<br /><br />No action is required. Logging for the Default Action Rule stops automatically once the one-hour period elapses. Until then, you can filter Monitor tab entries by rule name to distinguish residual Default Action Rule logs from current rule activity.</td></tr>
    <tr><td>AVX-79173</td><td>During a Controller-initiated image upgrade, an Aviatrix gateway can intermittently be left in a partially configured state because of a timing-related issue in the gateway's post-upgrade configuration sequence.<br /><br />**Impact:**<br /><br />The affected gateway's image upgrade is reported as only partially successful. The gateway remains in a partially configured state until an administrator intervenes to restore it to the UP state.<br /><br />**Workaround:**<br /><br />Retry the image upgrade on the affected gateway. Because the issue is timing-related, a subsequent retry typically succeeds without further action.</td></tr>
    <tr><td>AVX-79855</td><td>When Distributed Cloud Firewall is disabled on a transit gateway with Site2Cloud (S2C) or other external connections landing on it, and no policy change is queued at the time, existing DCF filtering rules on the interface are not removed. The disable path is skipped when there is no policy difference to push.<br /><br />**Impact:**<ul><li>After DCF is disabled on the affected transit gateway, previously installed DCF filtering rules remain in effect on the interface and continue to filter traffic.</li><li>Customers may see traffic still being subject to DCF filtering long after the feature was disabled.</li></ul>**Workaround:**<br /><br />Restart the Aviatrix gateway to remove the stale DCF filter rules. Alternatively, contact [Aviatrix Support](https://support.aviatrix.com/) to have the stale DCF filter rules manually removed.</td></tr>
    <tr><td>AVX-79905</td><td>Automatic Controller Access Security Group Management enforcement could unintentionally disable Security Group Management when a transient error occurred during an enforcement check.<br /><br />**Impact:**<br /><br />When Security Group Management became disabled, all gateways experienced keep-alive failures and new gateways could not come up.<br /><br />**Workaround:**<br /><br />Manually re-enable Security Group Management if it becomes disabled. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-80992</td><td>**Description:** Cloud Asset Inventory (CAI) inventories every project ID listed in a GCP service account by default. In GCP environments with a very large number of project IDs under a single service account, this inventory operation can exceed the allotted timeout period.<br /><br />**Impact:**<ul><li>Large-scale GCP deployments with many project IDs per service account may experience CAI inventory timeouts.</li><li>When an inventory cycle times out, cleanup of deleted GCP resources does not complete, which can cause stale resource entries to accumulate over time.</li></ul>**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) if you observe CAI inventory timeouts or stale resource accumulation in a large-scale GCP deployment. A configuration option to scope inventory to a single project ID is planned for a future release.</td></tr>
    <tr><td>AVX-81091</td><td>**Description:** The Controller's GCP event monitoring can fail to query event logs for a GCP account when that account's associated service account is linked to a very large number of GCP projects. The constructed log-query filter can exceed an internal size limit, causing the query to fail.<br /><br />**Impact:**<ul><li>GCP account event log data does not update in the Controller for GCP accounts whose service account is linked to a very large number of projects.</li></ul>**Workaround:**<br /><br />Upgrade to 8.2.30, 9.0.20, 10.0.10, or later, which includes the fix. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-80983</td><td>When Azure Security Group Management reads the current state of a security group rule before adding a new gateway's IP address to it during gateway launch, an Azure API throttling response on that read can be misinterpreted as the rule not existing. In that case, the existing rule is deleted and a new rule is created instead of the existing rule being updated.<br /><br />**Impact:**<br /><br /><ul><li>Azure security group rules can be unexpectedly deleted and recreated during gateway launch when the Azure API throttles the read call.</li><li>The delete-and-recreate sequence can result in a brief gap in security group coverage for the affected rule, or in duplicate rules if the sequence does not fully complete.</li></ul>**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) if you observe unexpected security group rule changes on gateway launch in an Azure environment.</td></tr>
    <tr><td>AVX-79860</td><td>New gateway deployment, or a software or image upgrade for an existing gateway, could fail if a container responsible for gateway-to-Controller secure communication did not start within the default 15-minute initialization window.<br /><br />**Impact:**<br /><br /><ul><li>Gateway deployment or upgrade fails and the gateway does not become operational.</li><li>Retrying the deployment or upgrade before the initialization window expires may succeed.</li></ul>**Workaround:**<br /><br />Retry the gateway deployment or upgrade. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-80977</td><td>A VPN user's profile assignment could appear as N/A immediately after the user was attached to a profile through the API, until the user's next reconnection.<br /><br />**Impact:**<br /><br /><ul><li>The user's profile displays as N/A until the user's next reconnection, even though the profile attachment succeeded.</li><li>This can cause confusion when auditing or verifying profile-based access policies shortly after attachment.</li></ul>**Workaround:**<br /><br />Have the affected user reconnect to update the displayed profile assignment. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-81892</td><td>On gateways enforcing Distributed Cloud Firewall (DCF) policies that include SmartGroups with FQDN selectors, an internal policy-update path can deadlock in rare cases, causing the gateway data-plane process to stop forwarding traffic while remaining alive. The deadlock is more likely when the FQDN selector resolves to a set of addresses that rotate frequently (short DNS TTL), because each resolution change triggers a policy reload that races with an internal hit-counter update.<br /><br />**Impact:**<ul><li>Affected gateways stop forwarding traffic when the deadlock occurs, even though the gateway process itself does not exit and is not marked unhealthy by existing watchdogs.</li><li>WebGroup policies (SNI-based) are not affected.</li><li>Gateways carrying no DCF policies, or DCF policies that do not use FQDN-selector SmartGroups, are not affected.</li><li>Recovery requires manually restarting the affected gateway.</li></ul>**Workaround:**<ul><li>Where equivalent coverage is available via a cloud provider external service feed (for example, the **AzureDevOps** service feed for traffic to Azure DevOps endpoints), remove the redundant FQDN-selector SmartGroup from the affected policy rule and rely on the service feed, which updates on a much slower cadence.</li><li>If the deadlock occurs, restart the affected gateway to restore traffic.</li><li>Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance identifying exposed gateways and reviewing DCF policy configurations.</li></ul></td></tr>
  </tbody>
</table>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.