> ## 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 8.2.20 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 8.2.20 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/" + "10.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 8.2.20

<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-74719</td><td>Fixed an issue where performing a Controller backup restore could cause a temporary traffic outage of approximately 40 seconds due to all routes being deleted and re-added during route reconvergence. Routes are now preserved during backup restore to prevent traffic disruption.</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-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-75256</td><td>Fixed an issue where FQDN gateway data was not correctly displayed after upgrading from version 7.2.x to 8.0 or later, causing the Egress FQDN Gateway View to appear empty. Gateways with FQDN tags now display correctly in the UI and are returned properly by the list\_fqdn\_gateways API.</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-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 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-77088</td><td>Fixed an issue where editing legacy FQDN domain name filters on a gateway could cause all FQDN filtering processes to stop simultaneously, resulting in a brief filtering outage until the processes were automatically restarted.</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>
    <tr><td>AVX-77767</td><td>Fixed an issue where Azure transit gateways with very large numbers of IPsec tunnels (3000+) could lose all spoke peerings and enter a high-CPU charon state under sustained high tunnel activity.</td></tr>
  </tbody>
</table>

## Known Issues in Aviatrix Release 8.2.20

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

  <tbody>
    <tr><td>AVX-62003</td><td>Azure gateway image upgrades may fail when the Controller does not have the required Azure image subscription access. During the upgrade, the system deletes the existing gateway before validating subscription availability, which can result in gateway deletion without a replacement being created. This leaves dangling gateways in the Controller and can cause potential service outages.<br /><br />**Impact:**<ul><li>Existing gateways may be deleted during image upgrade</li><li>Replacement gateway creation fails due to missing subscription</li><li>Customers may experience connectivity loss and dangling gateway entries in the Controller</li><li>Manual intervention required, leading to support escalations</li></ul>**Workaround:**<br /><br />None. To avoid outages, ensure the Controller subscription includes access to the required Azure image before attempting upgrades.</td></tr>
    <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-67180</td><td>In some environments running Aviatrix Controller version 8.1.x, the Controller UI may become inaccessible after the Controller is restarted. When this issue occurs, API requests fail with `RequestRefused` errors and the UI cannot be accessed, although SSH access to the Controller remains available.<br /><br />**Impact:**<br /><br />Users are unable to log in to the Controller UI or perform API operations.<br /><br />**Workaround:**<br /><br />Restart the VM where the Aviatrix Controller is running.</td></tr>
    <tr><td>AVX-68887</td><td>When attaching VPN users to profiles using the `attach_vpn_user_to_profile` API, the CoPilot or Controller UI may continue to display the user profile as **N/A** even though the attachment operation completes successfully.<br /><br />In some cases, users later reappear as active but still show no profile association in the UI. This results in a display inconsistency between the UI and the backend state.<br /><br />**Impact:** VPN user profile assignments may appear unsuccessful in the UI, which can cause confusion during profile management. There is no functional impact: the VPN profile is correctly assigned in the backend, and users can connect to the VPN as expected.<br /><br />**Affected Scenario:** OpenVPN profile management operations that use API-based user-to-profile attachment.<br /><br />**Workaround:** None.</td></tr>
    <tr><td>AVX-69649</td><td>The migration dry-run EIP accounting does not include public IPs that are not part of the Elastic IP quota, potentially producing inaccurate dry-run results.<br /><br />**Impact:**<ul><li>Dry-run migration reports may show incorrect EIP usage</li><li>Actual migration may encounter unexpected EIP limitations</li></ul>**Workaround:**<br /><br />Manually verify EIP allocation and quotas before performing the migration. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</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-70864</td><td>In Controller version 8.2.0, gateways may remain in a **Configuration Not Up-to-Date** state when applying Distributed Cloud Firewall (DCF) policies under certain conditions.<br /><br />This issue can occur when DCF policies with Web Groups and IDS or IPS enabled are pushed to gateways. The configuration update does not complete within the expected time, which may leave the gateway out of sync.<br /><br />**Impact:**<br /><br /><ul><li>Gateway shows **Configuration Not Up-to-Date** status</li><li>DCF policies may not be fully applied</li><li>Traffic may be dropped unexpectedly</li></ul>**Affected Scenario:**<br /><br />Gateways running Controller 8.2.0 with DCF policies that include IDS or IPS features, particularly on smaller gateway instance sizes.<br /><br />**Workaround:** Restart the affected gateway to clear the condition and allow the configuration to be applied successfully. If the issue persists, contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</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-71245</td><td>Additional Distributed Cloud Firewall (DCF) log support records end-session events for IDS and IPS signature matches. These logs include a reason field indicating the match type (IPS\_POLICY\_DENY or IDS\_POLICY\_ALERT) along with the Signature ID (SID) of the matched rule.<br /><br />Due to a bug, the end-session log is omitted when Decryption is not enabled for Intrusion Analysis.<br /><br />**Impact:**<br /><br /><ul><li>Missing end-session log entries for IDS/IPS signature matches when Decryption is disabled</li><li>No impact to DCF policy actions</li><li>No impact to existing Intrusion Analysis logs</li></ul>**Affected Version:** 8.2.0<br /><br />**Workaround:** Enable Decryption under Intrusion Analysis to ensure end-session logs are generated.</td></tr>
    <tr><td>AVX-71441</td><td>When upgrading gateways from version 8.1.20 to 8.2.0, in very rare cases, the gateway can enter an infinite retry loop attempting to download a non-existent configuration file from the Controller, causing the upgrade process to fail completely<br /><br />**Impact:**<br /><br /><ul><li>Gateway upgrade fails and cannot be completed.</li><li>Gateway becomes stuck in upgrade state.</li><li>Network connectivity through the affected gateway will be disrupted.</li></ul><br />**Workaround:** Retry the gateway upgrade operation from the Controller UI or Copilot UI. If the issue persists, perform an image upgrade of the impacted gateway.</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:**<ul><li>SSH access to the existing gateway may stop working</li><li>Gateway recovery may require manual intervention</li></ul>**Affected Scenario:**<ul><li>Gateway creation using a name that already exists</li></ul>**Workaround:**<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-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-74577</td><td>Users are unable to modify tags on third-party firewall instances when those tags contain values with multiple colons (for example, `team:iac:module.version:v1.5.3`). Attempts to update tags after deployment fail with a `too many values to unpack` error. Initial deployment is unaffected because tags are passed via a different code path during creation.<br /><br />**Impact:**<ul><li>Third-party firewall instance tag updates fail when tag values contain multiple colons</li><li>Initial deployment with multi-colon tags is not affected</li></ul>**Workaround:**<br /><br />Avoid using multiple colons in tag values when modifying tags after deployment. Use alternative delimiters such as hyphens or underscores.</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-75607</td><td>Gateway launch may fail with a `tls: bad certificate` error when pulling container images. The Controller's registry TTL eviction (garbage collection) may fire while images are being downloaded to the gateway, corrupting in-flight blob transfers. The gateway's container initialization cannot complete, and a supporting certificate-management process on the gateway exits with code 125.<br /><br />**Impact:**<br /><br /><ul><li>Gateway creation fails with tls: bad certificate or unexpected EOF errors during container image pull</li><li>The certificate-management process crash-loops with exit code 125</li><li>Manual intervention is required to recover</li></ul>**Workaround:**<br /><br />Restart the Controller's application service to reset the registry state, then retry gateway creation. 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 Controller's state synchronization service starts up and finds gateways stored as "Down" in its internal state store, 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-77958</td><td>When performing a gateway software rollback from version 8.2.20 to 8.1.40 on a Controller deployed in GCP, AWS and AWS GovCloud spoke gateways may fail to roll back successfully. The rollback may partially succeed, leaving affected gateways in an inconsistent state.<br /><br />**Impact:**<br /><br /><ul><li>Software rollback from 8.2.20 to 8.1.40 may fail for AWS and AWS GovCloud spoke gateways managed by a Controller deployed in GCP.</li><li>Affected gateways may be left in an inconsistent state and require manual recovery.</li></ul>**Workaround:**<br /><br />Retry the rollback, as the issue is timing-related. If the issue persists, contact [Aviatrix Support](https://support.aviatrix.com/) for further assistance.</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-78859</td><td>IP rules for a Site-to-Cloud mapped connection could be erased when the gateway started up.<br /><br />**Impact:**<br /><br />Traffic loss occurs for the affected Site-to-Cloud connection. The condition can persist across gateway reboots and does not resolve on its own; the gateway configuration must be reapplied.<br /><br />**Workaround:**<br /><br />Reconfigure the affected Site-to-Cloud mapped connection to restore the IP rules. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</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-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-80806</td><td>A Controller upgrade from 8.1.x to 8.2.20 could fail during data migration with an IP-pool allocation error.<br /><br />**Impact:**<br /><br />The Controller upgrade aborts and cannot complete until remediated.<br /><br />**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance. A fix is planned for a future release.</td></tr>
    <tr><td>AVX-79866</td><td>NAT rules could fail to install on gateways with legacy tunnel peerings that predated recent tunnel-peering enhancements.<br /><br />**Impact:**<ul><li>NAT rule pushes fail on the affected gateway on every subsequent configuration push.</li><li>In some cases, previously installed NAT rules are removed from the affected gateway, resulting in a loss of expected NAT behavior.</li></ul>**Workaround:**<br /><br />Re-establish the affected legacy tunnel peering so it picks up the current tunnel-peering fields. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance identifying affected peerings.</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.