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

> Release Date: 16 September 2025

Release Date: 16 September 2025

Release Notes Last Updated: 5 October 2026

## Corrected Issues in Aviatrix Release 8.1.10

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

  <tbody>
    <tr><td>AVX-61355</td><td>Fixed an issue where Azure `Standard_B1ms` SNAT-enabled Egress Spoke Gateways experienced severe throughput drops under high connection loads. Resource handling has been optimized to sustain expected connection levels without traffic collapse.</td></tr>
    <tr><td>AVX-63846</td><td>Resolved a CoPilot UI bug where SmartGroups and ExternalGroups with multiple filter sets did not display correctly after being saved. The UI now accurately preserves and displays all configured filter sets.</td></tr>
    <tr><td>AVX-64136</td><td>Fixed an issue in OCI environments where new CIDRs added to a VCN were not reflected in the Controller after the initial spoke-transit attachment. The Controller now correctly refreshes and includes newly added CIDRs, enabling gateway deployment in those ranges.</td></tr>
    <tr><td>AVX-66630</td><td>Fixed a problem where PEM certificate files containing a Unicode Byte Order Mark (BOM) failed to apply and could crash the Controller with a `missing private key` error. The Controller now strips BOM markers automatically, ensuring reliable certificate uploads.</td></tr>
    <tr><td>AVX-66737</td><td>Corrected Controller UI upgrade messaging during large-scale gateway software upgrades. The workflow no longer shows repeated, incomplete, or "undefined" entries. Status reporting now accurately reflects upgrade progress and completion.</td></tr>
    <tr><td>AVX-66781</td><td>Fixed an issue where OpenVPN Okta authentication did not support the new Okta Integrator Free Plan URL format (`https://integrator-xxxxxx.okta.com`). The Controller now accepts both the legacy `dev-xxxxxx.okta.com` format and the new Integrator Free Plan format.</td></tr>
    <tr><td>AVX-66808</td><td>Fixed an issue where, after upgrading to 8.1.0, Edge gateways with multiple WAN interfaces bound the StrongSwan service only to the first interface. IPSec tunnels now establish properly across all WAN interfaces without requiring manual restarts.</td></tr>
    <tr><td>AVX-66893</td><td>Resolved an issue where refreshing VPC/VNet route tables in CoPilot caused the primary gateway SNAT IP to be removed from all route tables, or HA routes to be missing. The refresh process now consistently preserves and propagates both primary and HA gateway SNAT/DNAT routes.</td></tr>
    <tr><td>AVX-66961</td><td>Fixed a memory leak in the DCF Traffic Server (TS\_MAIN process) that could cause gateway memory exhaustion and potential `traffic impact`. The issue occurred on gateways running Distributed Cloud Firewall (DCF) with WebGroups enabled.</td></tr>
    <tr><td>AVX-67474</td><td>Fixed a CoPilot bug where using **Administration > Upgrade > Upgrade Plan** to upgrade a Gateway image from 8.0.0 to 8.1.0 did not launch the correct containerized image, leaving the Gateway on the original version. Upgrade plans now correctly trigger containerized image upgrades.</td></tr>
    <tr><td>AVX-67493</td><td>Fixed an issue where restarting the Controller (`cloudxd`) or upgrading it could cause high CPU utilization and temporary traffic loss when BGP communities were configured. Route propagation logic has been improved to avoid disruption and reduce CPU spikes.</td></tr>
    <tr><td>AVX-67527</td><td>Fixed a regression where deleting a cloud account from the Controller failed to trigger email notifications. Notification handling now ensures emails are sent to configured recipients, restoring audit visibility.</td></tr>
  </tbody>
</table>

## Known Issues in Aviatrix Release 8.1.10

<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 />**Workaround:**<br /><br />To avoid this issue, follow the correct upgrade sequence:<ol><li>Upgrade the PSF Gateway first.</li><li>Wait for the PSF Gateway upgrade to complete successfully.</li><li>Then upgrade the dependent Spoke Gateways.</li></ol></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-64447</td><td>Site2Cloud High Availability (HA) tunnels may not behave correctly when toggling between Active/Active and Active/Standby modes.<br /><br />**Problem 1:**<br /><br />When disabling Active/Active HA, the HA Gateway (HAGW) may retain metric 100 routes pointing to tunnel interfaces in the Gateway Route table, even though they should be removed.<br /><br />**Problem 2:**<br /><br />When enabling Active/Active HA from Active/Standby, the HA Gateway tunnel may not be properly enabled. This can result in missing routes despite the UI showing Active/Active status.<br /><br />**Impact:**<ul><li>Inconsistent routes on the gateway while switching the S2C HA Mode.</li><li>Potential routing gaps on the gateway lead to incorrect traffic distribution.</li></ul>**Workaround:**<br /><br />If you encounter this issue, contact Aviatrix Support for assistance.</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.<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:**<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:**<ul><li>Firewall integration appears stuck in `Unaccessible` state</li><li>Recovery does not occur automatically after initial failure</li><li>May require manual intervention to restore proper firewall state reporting</li></ul>**Workaround:**<br /><br />Contact Aviatrix Support for manual correction.</td></tr>
    <tr><td>AVX-66324</td><td>When using Distributed Cloud Firewall (DCF) Layer 7 rules with Smart Groups that contain `tagged resources`, no bell notifications appear when configuration issues potentially block traffic. This affects deployments where Smart Groups match resources by `tags` (such as AWS instance tags) rather than static IPs or CIDRs. Although traffic is enforced correctly, administrators may not be alerted to the problematic configuration.<br /><br />**Affected Scenario:**<ul><li>DCF Layer 7 rules configured between Smart Groups based on resource tags (for example, Kubernetes pods and VMs)</li><li>Both VPCs use RFC1918 IP addresses</li><li>Gateways are deployed in High Availability (HA) mode</li></ul>**Impact:**<br /><br />Only affects notifications. Traffic enforcement continues to function as expected.<br /><br />**Workaround:**<ul><li>Monitor traffic flow manually</li><li>Use Smart Groups with static IPs or CIDRs if alerting is critical</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 />**Impact:**<ul><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>**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></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-67530</td><td>When Distributed Cloud Firewall (DCF) rules are configured with external groups as sources or destinations, the traffic count displayed in the **Security > Distributed Cloud Firewall > Policies** page may be significantly lower than the actual traffic volume shown in the **Security > Distributed Cloud Firewall > Monitor** page.<br /><br />**Impact:**<br /><br /><ul><li>DCF UI traffic counters underreport hits for rules using external groups.</li><li>Discrepancy can occur for both deny and permit rules.</li><li>May affect deployments using selective spoke VPCs.</li><li>Analysis may be misleading if relying solely on DCF UI counters.</li></ul>**Workaround:**<br /><br /><ul><li>Use the **Security > Distributed Cloud Firewall > Monitor** page logs for accurate traffic counts</li></ul></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>**Workaround:**<br /><br />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-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>**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></td></tr>
    <tr><td>AVX-68319</td><td>In some cases, the Controller UI may not display the kernel version for gateways, even though the correct version is present on the gateway itself. This typically affects environments with a large number of gateways (500+) that have gone through multiple upgrade cycles.<br /><br />**Impact:**<ul><li>Gateway functionality is not affected; the issue is limited to the UI display.</li><li>Administrators may see missing kernel version information in the Controller UI, which could cause confusion during troubleshooting or compliance checks.</li></ul>**Workaround:**<br /><br />Perform an image upgrade on the affected gateway to restore the proper kernel version display in the Controller UI.</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>**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></td></tr>
    <tr><td>AVX-68606</td><td>During software upgrades of Edge gateways from 8.1 to 8.1.10, services may restart as part of the upgrade process, which can cause temporary traffic disruption.<br /><br />**Impact:**<ul><li>Temporary traffic loss during Edge gateway upgrades</li><li>Service disruption due to container restarts</li><li>More noticeable in large-scale deployments</li></ul>**Workaround:**<br /><br />None. Users should plan for possible disruption during upgrades.<br /><br />**Recommendations:**<ul><li>Schedule upgrades during maintenance windows</li><li>Notify stakeholders of expected downtime</li><li>Monitor gateway status during upgrades</li></ul></td></tr>
    <tr><td>AVX-68692</td><td>The Controller may fail to automatically restart gateways after a Controller power cycle or restart. This occurs because the auto-restart task scheduler does not resume properly after reboot, preventing the gateway auto-recovery function from working.<br /><br />**Impact:**<ul><li>Failed gateways are not automatically restarted after Controller restarts</li><li>Gateway availability and recovery rely on manual intervention</li><li>Increases recovery time and operational overhead in large-scale environments</li></ul>**Affected Configuration:**<ul><li>Multicloud environments (AWS and Azure)</li><li>Deployments with large numbers of spoke gateways (for example, more than 100 gateways)</li><li>Controller version 8.1.10</li></ul>**Workaround:**<ul><li>Monitor gateway status manually after Controller restarts</li><li>Restart failed gateways manually using one of the following:</li><li>Cloud provider console (AWS/Azure portal)</li><li>Controller GUI gateway management</li><li>Gateway restart API calls</li></ul></td></tr>
    <tr><td>AVX-68726</td><td>On Azure Controllers with `Controller Security Group Management` enabled, gateway deployments may fail when multiple gateways or HA gateways are created.<br /><br />In this scenario, network security group rules may be overwritten or duplicated, which can cause Azure to return duplicate rule name errors. As a result, new gateways may fail to launch, and the Controller may automatically disable Security Group Management.<br /><br />**Impact:**<ul><li>Gateway deployments may fail in Azure</li><li>Security group rules may not be updated correctly</li><li>Controller Security Group Management may be disabled unexpectedly</li></ul>**Workaround:**<br /><br />Disable Controller Security Group Management and manage Azure network security group rules manually, or contact Aviatrix Support for assistance.</td></tr>
    <tr><td>AVX-69733</td><td>When upgrading Public Subnet Filtering (PSF) gateway images on Controller version 7.1 or later, the **ESTABLISHED** iptables firewall rule may be removed during the upgrade process.<br /><br />This issue occurs on PSF gateways using the legacy stateful firewall and can alter existing firewall behavior after the upgrade.<br /><br />**Impacted Scenario:**<br /><br /><ul><li>PSF gateway traffic filtering becomes incomplete</li><li>Network security policies may not be enforced correctly</li><li>Existing connections may be disrupted</li></ul>**Affected Scenario:** PSF gateways using the legacy stateful firewall on Controller version 7.1 or later that undergo image upgrades.<br /><br />**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-70253</td><td>FireNet deployment with bootstrap enabled may fail in Google Cloud due to changes in how GCP credentials are handled.<br /><br />The system no longer reads GCP credentials from local files during bootstrap. Instead, credentials are retrieved as encoded data from the database, which causes bootstrap operations to fail in certain FireNet deployment workflows.<br /><br />**Impact:**<br /><br />FireNet deployment with bootstrap fails in the Google Cloud environment.<br /><br />**Affected Scenario:**<br /><br />FireNet deployments with bootstrap enabled in Google Cloud.<br /><br />**Workaround:**<br /><br />Do not use bootstrap when deploying FireNet in Google Cloud. Alternatively, perform the bootstrap process directly from the GCP cloud.</td></tr>
    <tr><td>AVX-70506</td><td>When deploying multiple GCP gateways in parallel, such as through Terraform, the deployment may create a duplicate ID in the database. When the Controller later experiences a restart, the duplicate resource ID will prevent the Controller from starting properly and block 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 GCP resources</li></ul>**Workaround:**<br /><br />Deploy GCP gateways sequentially instead of in parallel. If duplicate resource IDs already exist, contact Aviatrix Support for assistance in cleaning up the database and restoring normal operation.</td></tr>
    <tr><td>AVX-71087</td><td>When upgrading to Controller versions 8.0 or 8.1, ICMP traffic may be blocked by default due to updated access control rules that do not include allowances for ICMP-based debugging.<br /><br />**Affected Scenario:**<br /><br />Environments where ICMP is used for network troubleshooting and diagnostic workflows.<br /><br />**Impact:**<ul><li>ICMP-based debugging tools may stop functioning</li><li>Network troubleshooting capabilities may be limited</li><li>Existing workflows that depend on ICMP may be disrupted</li></ul>**Workaround:**<br /><br />Manually add access control rules to the Controller to explicitly allow ICMP traffic for debugging. Contact Aviatrix Support for assistance if needed.</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:**<br /><br />The upgrade to Controller 8.1 cannot complete and the system remains on the previous version.<br /><br />**Workaround:**<br /><br />Contact Aviatrix Support for assistance.</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-71807</td><td>On transit gateways with **Network Segmentation** enabled, packet marking for network domains may fail under certain conditions. This can affect the correct enforcement of Network Segmentation policies.<br /><br />**Impact:**<br /><br /><ul><li>Traffic segmentation using multicloud transit Network Segmentation may not function as expected.</li></ul>**Workaround:** Follow the steps below to restart the **conduit** service on the affected gateway:<br /><br /><ol><li>From **Controller UI > Troubleshoot > Diagnostics > Gateway**</li><li>From **Service Actions**, select the affected gateway, choose **Conduit** as the service name, and then choose **Restart Service** as the action.</li><li>Click **OK** to restart the service.</li></ol></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>**Affected Scenario:**<br /><br />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 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), 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-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-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-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>
  </tbody>
</table>


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