> ## 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.0.70 Release Notes

> Release Date: 22 June 2026

Release Date: 22 June 2026

Release Notes Last Updated: 5 October 2026

## Corrected Issues in Aviatrix Release 8.0.70

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

  <tbody>
    <tr><td>AVX-75872</td><td>Fixed a locking race condition during Controller upgrade where the initial setup process and post-upgrade actions could acquire conflicting locks, causing post-upgrade configuration steps to fail or require manual intervention.</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-77487</td><td>Fixed an issue on Site-to-Cloud (S2C) gateways where customized NAT rules configured on S2C interfaces were not honored by the gateway's NAT translator, leading to incorrect or missing address translation on traffic traversing those tunnels.</td></tr>
  </tbody>
</table>

## Known Issues in Aviatrix Release 8.0.70

<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-62506</td><td>During a gateway software upgrade, traffic matching DCF WebGroup rules may be briefly dropped during the upgrade. This impacts both Layer 7 (HTTP/HTTPS) and Layer 4 traffic and occurs across all supported cloud providers (AWS, Azure, and GCP). The disruption typically lasts a few seconds but may vary depending on gateway load and policy complexity.<br /><br />**Workaround:**<br /><br />None<br /><br />**Recommendations:**<ul><li>Schedule gateway upgrades during maintenance windows or low-traffic periods.</li><li>Use HA deployments and upgrade gateways one at a time in HA pairs.</li><li>Monitor logs for "Failed to load policy" messages to confirm when policies are reloaded.</li></ul></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-67571</td><td>In Oracle Cloud Infrastructure (OCI) environments, OpenVPN clients cannot connect to VPN gateways configured with DUO multi-factor authentication (MFA). Connection attempts fail with `ECONNREFUSED` errors during tunnel establishment, preventing authentication from completing.<br /><br />**Impact:**<br /><br /><ul><li>VPN tunnels cannot be established to DUO-enabled OCI gateways</li><li>Only affects OCI deployments with DUO MFA</li><li>Other authentication methods (OKTA, LDAP) work normally</li></ul>**Workaround:** No current workaround. Users may temporarily switch to OKTA or LDAP authentication if feasible.</td></tr>
    <tr><td>AVX-68013</td><td>In Controller version 8.0.10, Spoke-to-Transit attachments initiated through Terraform may fail with a `decode check_task_status failed` error during gateway creation.<br /><br />This issue occurs when multiple API calls are executed in rapid succession, causing the Controller to occasionally return an empty response body for the `check_task_status` API.<br /><br />**Affected Scenario:**<ul><li>Spoke-to-Transit attachments created using the Aviatrix Terraform provider.</li><li>More likely during parallel or batch gateway deployments across any cloud (AWS, Azure, GCP, OCI).</li></ul>**Impact:**<ul><li>Terraform reports an error such as `unexpected end of JSON input`.</li><li>The Spoke-to-Transit attachment may still succeed, but Terraform marks the operation as failed.</li></ul>**Workaround:**<ul><li>Retry the Terraform operation.</li><li>Reduce parallelism for Terraform runs if possible.</li></ul></td></tr>
    <tr><td>AVX-68561</td><td>In large-scale deployments with 1300+ gateways, enabling Distributed Cloud Firewall Site-to-Cloud (DCF S2C) can cause gateway configurations to become out of sync with the Controller. Even after disabling DCF S2C, the issue may persist and lead to elevated Controller resource usage.<br /><br />**Impact:**<br /><br />Gateway configurations may show as out of sync in the Controller UI<br /><br />Controller CPU load (conduit process) increases significantly<br /><br />Performance degradation may occur during DCF S2C operations<br /><br />Issue may persist after disabling DCF S2C<br /><br />**Workaround:**<br /><br />Monitor Controller CPU usage before enabling DCF S2C in large-scale environments.<br /><br />Consider enabling DCF S2C during scheduled maintenance windows.<br /><br />For deployments with 1300+ gateways, evaluate the necessity of DCF S2C functionality.</td></tr>
    <tr><td>AVX-68726</td><td>On Azure Controllers with **Controller Security Group Management** enabled, existing gateway might go to keepalive fail status while creating a new gateway.<br /><br />Due to this bug, while creating a new gateway the Controller may automatically disable Controller Security Group Management, which impacts the connectivity between gateway and controller.<br /><br />**Impact:**<ul><li>Controller Security Group Management may be disabled unexpectedly.</li><li>Security group rules of the SG attached to controller might get deleted</li></ul>**Workaround:** Enable "Controller Security Group Management" manually, or contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</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-71122</td><td>In some environments, after the Identity Provider (IdP) rotates its SAML signing certificate, the Aviatrix Controller may fail to fetch and update the new certificate from the configured metadata URL.<br /><br />As a result, the Controller continues to use a stale certificate, which causes signature verification errors during SAML authentication.<br /><br />**Impact:** SAML single sign-on (SSO) authentication fails. Users may experience repeated login failures or timeouts and are unable to access the Controller dashboard using SAML.<br /><br />**Workaround:** Contact Aviatrix Support to manually update the SAML certificate on the Controller.</td></tr>
    <tr><td>AVX-71135</td><td>When upgrading to Controller 8.1, the database migration may fail if VPC tunnel records contain string values in the **timestamp** field instead of numeric values.<br /><br />During migration, the process attempts to convert these non-numeric timestamp strings to floating-point values, which results in a conversion error and causes the upgrade to fail.<br /><br />**Impact:** The upgrade to Controller 8.1 cannot complete and the system remains on the previous version.<br /><br />**Workaround:** Contact Aviatrix Support for assistance.</td></tr>
    <tr><td>AVX-71672</td><td>When upgrading the Controller to version 8.1, the database migration may fail if the tunnel `rtt_avg` field contains `None` values. The migration logic expects either a numeric value or the string `"N/A"`, and encountering a `None` value causes the upgrade to stop.<br /><br />**Impact:**<br /><br /><ul><li>Upgrade to 8.1 cannot complete</li><li>Controller remains on the previous version</li></ul>**Workaround:** Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance in correcting the database values before retrying the upgrade.</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-72207</td><td>When upgrading OpenVPN gateways to Controller version 8.1 (including 8.1.11 and 8.1.20), where profiles that contain FQDN-based policies may result in service disruption due to a DNS resolution limitation.<br /><br />**Affected Scenario:**<br /><br /><ul><li>OpenVPN enabled gateways with profiles that include policies using FQDNs.</li></ul>**Impact:**<br /><br /><ul><li>Users once connected to VPN, cannot access the whitelisted FQDNs in the OpenVPN Profiles.</li></ul>**Workaround:**<br /><br /><ul><li>There is currently no workaround. Users should roll back the affected gateways to a previous 8.0.x release to restore normal functionality.</li></ul></td></tr>
    <tr><td>AVX-72369</td><td>When multiple syslog profiles are configured on the Controller, performing a gateway image upgrade results in gateways being removed from syslog profiles that have only a subset of gateways specified in the include list.<br /><br />**Impact:**<ul><li>Remote syslog logs are no longer forwarded to the configured syslog servers for the affected gateways</li></ul>**Workaround:**<br /><br />Manually re-add the required gateways to the affected syslog profiles after the upgrade.</td></tr>
    <tr><td>AVX-72835</td><td>When upgrading to Controller 8.1, the database migration may fail if a High Availability Gateway (HAGW) entry appeared before its corresponding primary gateway in the database collection. During migration, the process relies on a strict ordering: primary gateway data must be initialized before the HAGW is processed to correctly populate gateway group data. The migration may fail or leave behind gateway entries in the wrong order in the database, which can lead to further issues.<br /><br />**Impact:**<br /><br /><ul><li>The upgrade to Controller 8.1 may fail to complete</li><li>Gateway entries may be stored in an incorrect order in the database</li></ul>**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-72871</td><td>Controller software upgrade to version 8.1 may fail with an error indicating that the page must be reloaded to complete the upgrade, due to an issue with the database migration when the database contains string values instead of integers for the cloud\_type field.<br /><br />**Impact:**<br /><br /><ul><li>The upgrade to version 8.1 will not be completed.</li><li>The Controller will remain on the previous version.</li></ul>**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance in correcting the database values before retrying the upgrade.</td></tr>
    <tr><td>AVX-73001</td><td>n environments where Spoke Gateways are configured with customized SNAT policies pointing to Transit Gateway VTI interfaces, upgrading Controller to version 8.1.20 may result in loss of the default route. This issue is not limited to Transit FireNet with Egress through Firewall setups, it can also occur when a default route is learned over BGP by the Transit Gateway and propagated to Spoke Gateways, as long as customized SNAT is in use.<br /><br />This issue may remove the default route in the spoke gateway pointing to the Transit Gateway tunnels, resulting in traffic egressing through unintended interfaces.<br /><br />**Affected Scenario:** Spoke gateways configured with customized SNAT policies pointing to Transit Gateway VTI interfaces, upgrading Controller to version 8.1.20<br /><br />This includes but is not limited to Transit FireNet with Egress through Firewall setups and environments using BGP-learned default routes propagated from Transit to Spoke Gateways.<br /><br />**Impact:**<br /><br />Traffic may bypass the Transit Gateway, leading to traffic disruption or loss.<br /><br />**Workaround:**<br /><br />No workaround is currently available. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-73061</td><td>The Cloud Asset Inventory (CAI) service has a memory leak in its L1 cache. When cloud instances such as VMs are removed from the cloud provider, the associated network interfaces remain cached and are never cleaned up.<br /><br />**Impact:**<br /><br /><ul><li>In environments that regularly cycle VMs (such as those using spot instances), the CAI service memory consumption grows over time and is never reclaimed.</li><li>This can lead to high memory usage by the CAI service, potentially affecting Controller performance.</li></ul>**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance with periodic CAI service restarts to reclaim memory.</td></tr>
    <tr><td>AVX-73629</td><td>During a Controller software upgrade from version 8.0 to 8.1, the database migration may overwrite the VPC name field with incorrect data when an old VPC record contains a pre-existing 'name' key set to the gateway name. Affected VPC records become unfindable via index lookups, which can disrupt Controller operations that reference those VPCs.<br /><br />**Impact:**<br /><br /><ul><li>Controller upgrades from 8.0 to 8.1 may corrupt the VPC name field for records containing a stale 'name' key.</li><li>Affected VPC records cannot be retrieved through standard index lookups.</li><li>Controller operations referencing those VPCs may behave unexpectedly.</li></ul>**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-74226</td><td>CoPilot deployments and migrations may fail with "Unsupported instance size" errors when selecting valid instance types. The instance type validation incorrectly blocks supported sizes during CoPilot deployment or migration operations.<br /><br />**Impact:**<br /><br />CoPilot deployment or migration may fail when selecting certain valid instance types<br /><br />Error message "Unsupported instance size" is displayed even for supported sizes<br /><br />**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance with CoPilot deployment using the affected instance types.</td></tr>
    <tr><td>AVX-74465</td><td>Aviatrix HPE gateway (including HA gateway) creation failed in OCI VCNs with DNS disabled. Gateways can now be created regardless of VCN DNS configuration.<br /><br />**Workaround:**<br /><br />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-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:**<br /><br />VPN gateway authentication using LDAP with TLS may not function as expected<br /><br />Manual intervention may be required to ensure VPN authentication is properly configured<br /><br />**Workaround:**<br /><br />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. 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-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-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 />Azure security group rules can be unexpectedly deleted and recreated during gateway launch when the Azure API throttles the read call.<br /><br />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.<br /><br />**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-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 />The user's profile displays as N/A until the user's next reconnection, even though the profile attachment succeeded.<br /><br />This can cause confusion when auditing or verifying profile-based access policies shortly after attachment.<br /><br />**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>
  </tbody>
</table>


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