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

> Release Date: 22 December 2025

Release Date: 22 December 2025

Release Notes Last Updated: 5 October 2026

## Corrected Issues in Aviatrix Release 8.1.20

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

  <tbody>
    <tr><td>AVX-64447</td><td>Fixed an issue where toggling between Active/Active and Active/Standby modes in Site2Cloud connections was not working properly. Users can now successfully switch between these high availability modes as expected.</td></tr>
    <tr><td>AVX-66324</td><td>Fixed an issue where bell notifications were missing for Distributed Cloud Firewall (DCF) L7 rules between Kubernetes pods and VMs when using HA gateways. Previously, traffic would work intermittently when DCF L7 rules were applied between Kubernetes services and VMs in different VPCs with HA gateways. The system now properly generates notifications when these rules are applied.</td></tr>
    <tr><td>AVX-67530</td><td>Fixed an issue where the traffic count displayed in the Controller interface could be inaccurate when using Distributed Cloud Firewall (DCF) with external groups that include multiple IP ranges.<br /><br />The Controller now reports traffic statistics correctly for DCF rules involving external groups, providing accurate visibility for monitoring, analysis, and validation of firewall policy behavior.</td></tr>
    <tr><td>AVX-68013</td><td>Resolved an issue where Spoke-to-Transit attachments initiated through Terraform could fail with a `decode check_task_status failed` error.<br /><br />The Controller now returns a valid response consistently, preventing Terraform failures during Spoke-to-Transit attachment operations.</td></tr>
    <tr><td>AVX-68606</td><td>Resolved an issue where Edge gateway upgrades from version 8.1 to 8.1.10 could cause temporary traffic disruption due to service restarts during the upgrade process.<br /><br />The upgrade workflow now handles service restarts more effectively, reducing traffic impact during Edge gateway upgrades, including in large-scale deployments.</td></tr>
    <tr><td>AVX-68726</td><td>Resolved an issue on Azure Controllers where **Controller Security Group Management** could cause gateway deployments to fail.<br /><br />The issue occurred when security group rules were not updated correctly while creating multiple gateways or HA gateways, which led to duplicate rule errors and prevented additional gateways from being deployed.</td></tr>
    <tr><td>AVX-69733</td><td>Resolved an issue where the **ESTABLISHED** rule disappeared after a Public Subnet Filtering (PSF) gateway image upgrade.<br /><br />This issue affected PSF gateways using the legacy stateful firewall on Controller versions 7.1 and later, and could result in traffic disruption after the upgrade. The rule is now preserved during PSF gateway image upgrades.</td></tr>
    <tr><td>AVX-70123</td><td>Fixed an issue with database schema type definitions that could trigger migration errors during the Controller upgrade process.<br /><br />The schema now uses the correct database type definition, ensuring compatibility with migration logic and preventing upgrade failures.</td></tr>
    <tr><td>AVX-70253</td><td>Fixed an issue where FireNet deployments with bootstrap enabled could fail in Google Cloud due to changes in how GCP credentials were handled during the bootstrap process.<br /><br />The bootstrap workflow has been updated to correctly retrieve and use GCP credentials, ensuring FireNet deployments with bootstrap complete successfully in Google Cloud environments.</td></tr>
    <tr><td>AVX-70506</td><td>Fixed an issue where deploying multiple GCP gateways through Terraform resulted in ResourceDuplicateId errors. The system now properly handles concurrent gateway deployments in different GCP zones, preventing resource ID conflicts during the creation process.</td></tr>
    <tr><td>AVX-71087</td><td>Fixed an issue where the default access control rules did not properly allow ICMP traffic used for debugging. The updated rules ensure ICMP-based troubleshooting continues to work after upgrades.</td></tr>
    <tr><td>AVX-71217</td><td>Resolved an issue where the VRRP state file could become empty when upgrading AEP and self-managed Edge-as-Spoke gateways in active-active HA configurations from version 7.2 to 8.0.30.<br /><br />With this fix, VRRP primary and backup state information is preserved during the upgrade, and newly created Edge-as-Spoke gateways with VRRP configuration no longer remain in the **Initializing** state.</td></tr>
    <tr><td>AVX-71807</td><td>Resolved an issue where eBPF packet marking could fail on transit gateways with **Network Segmentation** enabled, causing traffic to be associated with incorrect network domains.<br /><br />The packet marking logic has been corrected to ensure Network Segmentation policies are enforced consistently without requiring service restarts.</td></tr>
    <tr><td>AVX-73001</td><td>Fixed an issue where upgrading Spoke Gateways to version 8.1.20 in environments using Transit FireNet with Egress through Firewall and customized SNAT policies could result in loss of the default route, causing traffic disruption.</td></tr>
  </tbody>
</table>

## Known Issues in Aviatrix Release 8.1.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><br />**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 />**Workaround:**<br /><br />To avoid this issue, follow the correct upgrade sequence:1. Upgrade the PSF Gateway first.<br />2. Wait for the PSF Gateway upgrade to complete successfully.<br />3. Then upgrade the dependent Spoke Gateways.<br /></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><br /></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:**<br /><br />Controller UI may show incorrect VRRP status such as both peers reporting **Primary** or **Initializing**<br /><br />No impact on actual VRRP traffic handling or failover behavior.<br /><br />**Workaround:**<br /><br />Use diagnostic logs to verify actual VRRP state</td></tr>
    <tr><td>AVX-65016</td><td>In some environments, the Firewall state may not recover from **Unaccessible** after the first vendor integration failure. This issue has been observed when integrating with third-party firewall vendors, leaving the gateway firewall state stuck even after the environment stabilizes.<br /><br />**Impact:**<br /><br />Firewall integration appears stuck in **Unaccessible** state<br /><br />Recovery does not occur automatically after initial failure<br /><br />May require manual intervention to restore proper firewall state reporting<br /><br />**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for manual correction.</td></tr>
    <tr><td>AVX-65590</td><td>When editing the HPE spoke-transit peering tunnel count via API on gateways with customized SNAT configured, a traffic outage of approximately 100-120 seconds per gateway may occur. During the tunnel count change, the primary spoke gateway deletes and recreates tunnels, causing the transit gateway to temporarily remove the metric 100 route for the primary SNAT IP. The HA spoke gateway loses the metric 200 route for the primary SNAT IP during this period, leading to a traffic blackhole until tunnels are fully recreated.<br /><br />**Affected Scenario:**<ul><li>HPE spoke-transit peering with customized SNAT configured</li><li>Editing tunnel count via API while traffic is flowing</li><li>Gateways with HA enabled</li></ul><br />**Impact:**<ul><li>Approximately 100-120 seconds of traffic outage per gateway during tunnel count changes</li><li>Total VPC workload outage may be 3-4 minutes as primary and HA gateways sequentially recreate tunnels</li></ul><br />**Workaround:**<br /><br />Schedule tunnel count changes during a maintenance window when traffic disruption is acceptable. Avoid editing tunnel counts during peak traffic periods.</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 />**Impact:**<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><br />**Workaround:**<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 the CoPilot UI.</li></ul><br /></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.<br /><br />**Workaround:**<br /><br />None.</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-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:**<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><br />**Workaround:**<br /><br />No current workaround. Users may temporarily switch to OKTA or LDAP authentication if feasible.</td></tr>
    <tr><td>AVX-68108</td><td>When upgrading the Controller from version 8.0.30 to 8.1.10, the UI may display a misleading **"Service temporarily unavailable"** error message immediately after the upgrade begins. This message can persist for 5–10 minutes but does not indicate upgrade failure. The upgrade continues normally in the background and the Controller becomes accessible again once the upgrade finishes.<br /><br />**Impact:**<ul><li>Users may believe the upgrade has failed.</li><li>Error message persists for 5–10 minutes, especially in larger deployments (50+ gateways).</li><li>No effect on upgrade success or Controller functionality.</li></ul><br />**Workaround:**<ul><li>Ignore the message during upgrade.</li><li>Wait 10–15 minutes for the process to complete.</li><li>Refresh the browser and verify the new Controller version after reconnection.</li></ul><br /></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:**<ul><li>Gateway configurations may show as out of sync in the Controller UI</li><li>Controller CPU utilization (conduit process) increases significantly</li><li>Performance degradation may occur during DCF S2C operations</li><li>Issue may persist after disabling DCF S2C</li></ul><br />**Workaround:**<ul><li>Monitor Controller CPU usage before enabling DCF S2C in large-scale environments.</li><li>Consider enabling DCF S2C during scheduled maintenance windows.</li><li>For deployments with 1300+ gateways, evaluate the necessity of DCF S2C functionality.</li></ul><br /></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:**<br /><br />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:**<br /><br />OpenVPN profile management operations that use API-based user-to-profile attachment.<br /><br />**Workaround:**<br /><br />None.</td></tr>
    <tr><td>AVX-69342</td><td>When a Controller experiences out-of-memory conditions followed by upsizing and restart, duplicate resource ID entries may be created in the database. This prevents the Controller from starting properly and blocks access to the web UI.<br /><br />**Impact:**<ul><li>Controller fails to start after restart</li><li>Web UI becomes inaccessible</li><li>Database contains duplicate resource entries for GCE networks and other resources</li></ul><br />**Affected Scenario:**<br /><br />Controllers that have experienced memory issues, been upsized, and restarted may encounter this database corruption.<br /><br />**Workaround:**<br /><br />Connect directly to the Controller database and manually remove the duplicate resource ID entries to restore normal operation.</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><br />**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 DPI/IDS or Layer7 policies are configured with "Destination: Anywhere" on HA-enabled spoke gateways where the destination smart group contains private CIDRs, the policies become invalid and cause traffic drops.<br /><br />**Affected Scenario:**<br /><br />Spoke gateways with HA enabled using DPI/IDS or Layer7 policies that have destination smart groups containing private CIDR ranges and "Destination: Anywhere" configuration.<br /><br />**Impact:**<ul><li>All egress traffic matching the policy rules gets dropped</li><li>Network connectivity loss for affected traffic flows</li><li>Policy validation failures preventing proper traffic inspection</li></ul><br />**Workaround:**<br /><br />Modify the policy destination from "Anywhere" to specific target destinations that exclude conflicting private CIDR ranges, or disable HA on the affected spoke gateway if operationally acceptable.</td></tr>
    <tr><td>AVX-70958</td><td>When clients use HTTP/2 protocol, Trafficserver incorrectly reuses origin connections, which can cause SSL/TLS verification issues and potential security concerns with SNI (Server Name Indication) handling.<br /><br />**Affected Scenario:**<br /><br />HTTP/2 client connections through Trafficserver proxy<br /><br />**Impact:**<ul><li>SSL/TLS certificate verification may fail</li><li>SNI matching issues between client requests and origin servers</li><li>Potential security vulnerabilities due to connection reuse</li></ul><br />**Workaround:**<br /><br />Configure records.yaml to match on both IP address and SNI to ensure proper connection handling.</td></tr>
    <tr><td>AVX-70995</td><td>When a gateway is downsized in environments with IPS (Intrusion Prevention System) enabled, L7 traffic (HTTP/HTTPS) is dropped instead of being allowed through. The system blocks traffic when it detects that security policies cannot be properly enforced due to insufficient gateway resources, preventing the traffic-server from running.<br /><br />**Affected Scenario:** Gateways with IPS enabled that undergo downsizing operations.<br /><br />**Impact:**<br /><br /><ul><li>HTTP and HTTPS traffic is completely blocked</li><li>Security policies cannot be enforced on downsized gateways</li><li>Service disruption for applications relying on L7 traffic</li></ul>**Workaround:** Resize the gateway back to adequate specifications that support IPS functionality and traffic-server operations.</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:**<br /><br />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:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) to manually update the SAML certificate on the Controller.</td></tr>
    <tr><td>AVX-71135</td><td>The AM4.0 database migration may fail when the tunnel database `timestamp` field contains string values instead of the expected integer type. This can block Controller upgrades that include the AM4.0 migration step.<br /><br />**Impact:**<ul><li>Controller upgrade may fail during database migration</li><li>The Controller will remain on the previous version</li></ul><br />**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance with correcting the database field values before retrying the upgrade.</td></tr>
    <tr><td>AVX-71630</td><td>On Azure Aviatrix gateways with **accelerated networking** enabled and using **Distributed Cloud Firewall (DCF)** features, intermittent traffic drops may occur after upgrading from a version earlier than **7.2.2994** to **7.2.2994 or later**.<br /><br />This issue is caused by incorrect eBPF filters being applied to the slave `eth1` interface during the upgrade process.<br /><br />**Affected Scenario:**<br /><br /><ul><li>Azure gateways with accelerated networking enabled</li><li>DCF features enabled</li><li>Upgrading from a version prior to 7.2.2994 to 7.2.2994 or later</li></ul>**Impact:**<br /><br /><ul><li>Intermittent traffic drops across affected gateways</li></ul>**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) 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.<br /><br />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:**<ul><li>Upgrade to 8.1 cannot complete</li><li>Controller remains on the previous version</li></ul><br />**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-71719</td><td>When ICMP traffic passes through Suricata inspection on gateways, alert rules trigger only once until the Suricata process restarts. This limitation affects the eBPF → proxyPcap → Suricata traffic path and likely impacts UDP and other non-TCP protocols as well.<br /><br />**Impact:**<br /><br /><ul><li>Security alerts may not fire for subsequent ICMP traffic</li><li>Potential gaps in threat detection for non-TCP protocols</li><li>Reduced visibility into network security events</li></ul>**Affected Scenario:** Gateways with Suricata-based security inspection enabled for ICMP and potentially UDP traffic.<br /><br />**Workaround:** Contact [Aviatrix Support](https://support.aviatrix.com/) to restore the alert functionality for ICMP traffic.</td></tr>
    <tr><td>AVX-71720</td><td>When processing decrypted POST traffic through the ATS tee plugin, PSF gateways may experience crashes during request body processing. This occurs specifically with decrypted traffic that contains POST requests being processed by the tee plugin's request body handling path.<br /><br />**Impact:**<ul><li>Gateway crashes affecting traffic processing</li><li>Service disruption for decrypted POST requests</li><li>Potential data loss during crash events</li></ul><br />**Affected Scenario:**<br /><br />PSF gateways processing decrypted POST traffic through ATS tee plugin<br /><br />**Workaround:**<br /><br />Avoid routing decrypted POST traffic through affected PSF gateways until the fix is implemented. Consider using alternative routing paths or temporarily disabling tee plugin functionality for POST request processing if operationally feasible.</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:**<ul><li>VPN gateway deployment fails</li><li>Error message does not clearly indicate the root cause</li></ul><br />**Affected Scenario:**<br /><br />Load balancer–enabled VPN gateway deployments on Controller versions 8.0, 8.1, and 8.2.<br /><br />**Workaround:**<ul><li>Ensure that the VPN CIDR does not overlap with existing gateways behind the load balancer before deployment.</li><li>Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</li></ul><br /></td></tr>
    <tr><td>AVX-71826</td><td>In Aviatrix software versions 8.1.x and 8.2.0, the VRRP state file may be empty on AEP and self-managed Edge-as-Spoke gateways configured in active-active HA pairs. This prevents VRRP state updates from being sent from the edge gateways to the Aviatrix Controller, and Aviatrix CoPilot will not display the updated VRRP states. This is a cosmetic issue and there will be no disruption to traffic.<br /><br />**Impact:**<ul><li>VRRP state information for edge gateways is not shown accurately in Aviatrix CoPilot</li><li>Aviatrix CoPilot may display both primary and HA edge gateways with the same VRRP state</li><li>The VRRP state information will not be updated in Aviatrix CoPilot when VRRP failovers occur on the data plane. This is a display-only issue and the data plane will not be disrupted</li><li>The VRRP state information may show Initializing in Aviatrix CoPilot for Edge-as-Spoke gateways which are created in version 8.1 and 8.2</li></ul><br />**Affected Scenario:**<br /><br />AEP and self-managed Edge-as-Spoke gateways in active-active HA deployments with VRRP enabled upgrade from 8.0 to 8.1 or created in 8.1 and 8.2<br /><br />**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance to help you fix the incorrect display of VRRP states in Aviatrix CoPilot.</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 />OpenVPN enabled gateways with profiles that include policies using FQDNs.<br /><br />**Impact:**<br /><br />Users once connected to VPN, cannot access the whitelisted FQDNs in the OpenVPN Profiles.<br /><br />**Workaround:**<br /><br />There is currently no workaround. Users should roll back the affected gateways to a previous 8.0.x release to restore normal functionality.</td></tr>
    <tr><td>AVX-72363</td><td>The Controller may display an incorrect warning message during a platform upgrade, stating the release is under development or unsupported.<br /><br />**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</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><br />**Workaround:**<br /><br />Manually re-add the required gateways to the affected syslog profiles after the upgrade.</td></tr>
    <tr><td>AVX-72568</td><td>When deploying FireNet for Centralized Egress with FQDN gateways in AWS, DCF policies may block traffic unexpectedly.<br /><br />**Impact:**<ul><li>Traffic through FQDN gateways may be blocked by DCF policies</li><li>Centralized Egress functionality may not work as expected</li></ul><br />**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance with adjusting DCF policy configuration for FQDN gateway deployments.</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:**<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><br />**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 the error `Please reload the page in order to 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:**<ul><li>The upgrade to version 8.1 will not be completed</li><li>The Controller will remain on the previous version</li></ul><br />**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-72932</td><td>The CloudWatch agent migration may fail when processing legacy database records that are missing required fields, preventing the migration from completing successfully.<br /><br />**Workaround:**<br /><br />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 once 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><br />**Affected Scenario:**<br /><br />Gateway creation using a name that already exists<br /><br />**Workaround:**<ul><li>Do not reuse gateway names</li><li>Contact [Aviatrix Support](https://support.aviatrix.com/) if recovery is required</li></ul><br /></td></tr>
    <tr><td>AVX-72966</td><td>Launching an AWS gateway may fail the public subnet validation check due to a delay in subnet route table association updates from the cloud provider.<br /><br />**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-73036</td><td>Mapped standby tunnels had cleanup issues with mangle rules and route tables during tunnel failover operations.<br /><br />**Workaround:**<br /><br />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-73136</td><td>Agent certificate renewal may fail for 8.0.x gateways managed by 8.1.x Controllers due to differences in SPIRE versions.<br /><br />Controller 8.1.x uses SPIRE v1.12.0, while 8.0.x gateways use SPIRE v1.0.1. In mixed-version deployments, 8.0.x gateways may fail to renew the agent\_SVID certificate.<br /><br />As a result, users may begin receiving repeated PKI agent expiry alert emails indicating that the agent certificate could not be renewed.<br /><br />**Impact:**<br /><br /><ul><li>No impact to gateway data plane traffic.</li><li>No impact to gateway operational status.</li><li>When agent\_SVID expires, the gateway agent automatically restarts and successfully re-attests to the Controller.</li></ul>**Affected Scenario:**<br /><br /><ul><li>Mixed-version environments where:<br /><br /><ul><li>Controller is running 8.1.x</li><li>Gateway is running 8.0.x</li></ul></li></ul>**Workaround:**<br /><br /><ul><li>Perform mTLS Re-Attest on the affected gateway. This suppresses PKI expiry alerts for approximately 15 days.</li><li>If renewal fails again after around 15 days, repeat the re-attestation process.</li></ul></td></tr>
    <tr><td>AVX-73182</td><td>An invalid VPC ID format during spoke gateway initialization can cause a failed lookup and may result in a duplicate VPC object being created.<br /><br />**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</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:<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:**<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><br />**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-73589</td><td>In some high-traffic environments using FQDN filtering, the Legacy Egress FQDN process may stall due to a deadlock. If the signal interrupts a thread that is already executing a non-reentrant function, the signal handler may attempt to acquire the same lock, causing a deadlock.<br /><br />**Impact:**<br /><br />The Legacy Egress FQDN process may stall and stop processing traffic until the service is restarted.<br /><br />**Workaround:**<br /><br />Restart the instance to continue processing traffic.</td></tr>
    <tr><td>AVX-73629</td><td>The VPC name field could be overwritten with incorrect data during the AM4.0 migration, causing affected VPC records to become unfindable via index lookups. The migration logic now correctly preserves the VPC name field.<br /><br />**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-73742</td><td>Two issues with single IP HA tunnel failover in Site-to-Cloud deployments. The Controller no longer sends stale IPsec session teardown messages to gateways that temporarily lost connectivity, and now stops failover of pending tunnels to the HA gateway if the active gateway reconnects quickly, reducing unnecessary tunnel downtime.<br /><br />**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-74055</td><td>In some environments running 8.0.30 or later builds, duplicate iptables **mangle** table MARK rules may remain on gateways during mapped Site-to-Cloud tunnel failover, gateway image upgrade, or rollback scenarios.<br /><br />These rules may accumulate due to incomplete cleanup during tunnel role transitions.<br /><br />**Impact:**<br /><br />No traffic impact has been observed. The issue only affects residual rule cleanup on the gateway.<br /><br />**Workaround:**<br /><br />No workaround is required. The extra rules do not affect traffic forwarding.</td></tr>
    <tr><td>AVX-74146</td><td>Prolonged traffic loss could occur during a Controller software upgrade from version 8.1.20 to 8.1.30.<br /><br />**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-74251</td><td>Some Azure gateways displayed the Image Version without the Image Build timestamp, making it difficult to identify the exact gateway image.<br /><br />**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-74418</td><td>In some environments running Aviatrix Controller version 8.1.x, the Controller UI may become inaccessible after the Controller is restarted.<br /><br />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 />Stop and then restart the Aviatrix Controller VM on the CSP.</td></tr>
    <tr><td>AVX-74711</td><td>The gateway firewall may leave an unnecessary TCP port open due to a misconfiguration in the routing service.<br /><br />**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-74739</td><td>For Controllers with large-scale deployments (for example, several thousand gateways and tunnels), the database migration during upgrade can exceed the current hard-coded 15-minute timeout, causing the Controller upgrade to fail and roll back. The migration timeout is not configurable in affected versions, so customers with very large environments are more likely to encounter this issue during Controller upgrades.<br /><br />**Impact:**<ul><li>Controller upgrade fails and rolls back due to migration timeout</li><li>Large-scale environments with thousands of gateways and tunnels are most affected</li></ul><br />**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance with adjusting the migration timeout for large-scale deployments.</td></tr>
    <tr><td>AVX-74990</td><td>Controller software upgrade from version 8.0.40/8.0.50 to 8.1.20 may cause Controller CPU utilization to spike due to a schema migration being skipped during the upgrade. This can result in sluggish Controller UI performance.<br /><br />**Impact:**<br /><br /><ul><li>CPU utilization spikes after upgrading from 8.0.40/8.0.50 to 8.1.20</li><li>Controller UI may show sluggish performance</li></ul>**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance with applying the workaround to fix the skipped schema migration.</td></tr>
    <tr><td>AVX-75135</td><td>After upgrading the Controller from version 8.0 to 8.1, tunnel status report processing on the Controller takes longer due to increased database query overhead. Average processing time increases from approximately 150ms to 230ms per report, which may be noticeable in large-scale deployments with many tunnels.<br /><br />**Impact:**<br /><br /><ul><li>Tunnel status updates may take longer to process on the Controller.</li><li>Large-scale deployments may experience delayed tunnel status reporting in CoPilot.</li><li>No impact on tunnel connectivity or data plane traffic.</li></ul>**Workaround:**<br /><br />None. This is a performance issue with no traffic impact.</td></tr>
    <tr><td>AVX-75256</td><td>After upgrading the Aviatrix Controller from version 7.2.x to 8.0 or later, gateways with FQDN tags attached may no longer be visible in the Egress FQDN Gateway View tab. The list\_fqdn\_gateways API returns an empty list despite the gateways being present and properly associated with their FQDN tags.<br /><br />**Impact:**<br /><br /><ul><li>Egress FQDN-enabled gateways are not displayed in the Controller UI after upgrade</li><li>The list\_fqdn\_gateways API returns an empty list</li><li>Gateways remain operational and FQDN tag associations are intact</li></ul>**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-75299</td><td>Due to a temporary Oracle Cloud Infrastructure (OCI) Marketplace partner agreement issue, new OCI gateway images cannot be published for this release. OCI gateway pointers have been reverted to previous versions to ensure stability. As a result, OCI gateways will not receive patched images as part of this release.<br /><br />**Impact:**<ul><li>OCI gateways will not receive the latest patched images in this release</li><li>Customers using OCI gateways will remain on previous image versions until the OCI Marketplace issue is resolved</li></ul><br />**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance with OCI gateway image updates.</td></tr>
    <tr><td>AVX-75452</td><td>In Azure environments, when Distributed Cloud Firewall (DCF) Security Group Orchestration attaches a Network Security Group (NSG) to a subnet, the subnet name is changed to all lowercase. Although Azure resource names are generally case-insensitive, this modification causes issues with Infrastructure as Code tools such as Terraform, which treat resource names as case-sensitive. Terraform may flag affected subnets for replacement, potentially disrupting existing deployments.<br /><br />**Impact:**<ul><li>Subnet names in Azure are modified to lowercase when Security Group Orchestration attaches NSGs</li><li>Terraform plans may show unexpected resource replacements for affected subnets</li><li>Customer naming conventions in the cloud may be altered without consent</li></ul><br />**Workaround:**<br /><br />In Terraform, add a `lifecycle` block with `ignore_changes` for `subnet_id` (as well as `id` in the `azurerm_subnet` resource) to prevent forced resource replacement. Note that this workaround does not restore the original subnet name casing.</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:**<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><br />**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-75944</td><td>When migrating an existing Controller to a new Controller VM, a database migration issue can cause configuration changes to be applied to gateways too early during the migration process.<br /><br />**Impact:**<br /><br />Gateways with NAT configured may experience a temporary datapath disruption during Controller migration.<br /><br />**Workaround:**<br /><br />There is no workaround. Upgrade to a version that includes the fix (8.0.60, 8.1.30, 8.2.10, or 9.0.0). Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-76288</td><td>The Controller may incorrectly request client certificates from browser clients when the Controller hostname shares a domain suffix with the gateway certificate domain, which can prevent users from accessing the Controller UI.<br /><br />**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-76296</td><td>During routine gateway operations (such as resize or image upgrade) in GCP global VPC environments, traffic may be blackholed due to incorrect route handling.<br /><br />**Impact:**<ul><li>Traffic through the affected gateway may be dropped during operations</li><li>GCP global VPC routing may be temporarily disrupted</li></ul><br />**Workaround:**<br /><br />Schedule gateway operations during maintenance windows. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-76413</td><td>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:**<br /><br />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:**<br /><br />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-77088</td><td>On Controller and gateway running 8.1.x or 8.2.x, editing legacy FQDN domain name filters can cause all FQDN filtering processes on the gateway to stop simultaneously. Gateway monitoring restarts the processes automatically, but a brief filtering outage may occur during the restart.<br /><br />**Impact:**<br /><br /><ul><li>FQDN filtering on the gateway may experience a short interruption when domain name filters are edited.</li><li>Traffic that depends on FQDN filtering may be briefly affected until the filtering processes restart.</li></ul>**Workaround:**<br /><br />Schedule edits to legacy FQDN filters during a maintenance window. 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.