> ## 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 10.1.10 Release Notes

> Release Date: 5 October 2026

Release Date: 5 October 2026

Release Notes Last Updated: 19 October 2026

## Corrected Issues in Aviatrix Release 10.1.10

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

  <tbody>
    <tr><td>AVX-73433</td><td>Fixed an issue where changing the Interface RX Queue Size setting on a gateway did not automatically apply the new value to interfaces created after the change. The updated RX Queue Size setting now applies to all interfaces without requiring a gateway reboot or reapplying the configuration.</td></tr>
    <tr><td>AVX-73436</td><td>Fixed an issue where, when onboarding an Azure route table using the `update_spoke_vpc_route_table` API, the default route (0.0.0.0/0) was not programmed into the spoke VNET route table if the Spoke Gateway had learned the default route from an attached Egress Transit Gateway, a Site-to-Cloud connection through a transit, or another Spoke Gateway.</td></tr>
    <tr><td>AVX-75452</td><td>Fixed an issue where, in Azure environments, Distributed Cloud Firewall (DCF) Security Group Orchestration changed the name of a subnet to all lowercase when attaching a Network Security Group (NSG) to it. This caused Infrastructure as Code tools such as Terraform, which treat resource names as case-sensitive, to flag the affected subnets for replacement.</td></tr>
    <tr><td>AVX-78524</td><td>Fixed an issue where new Azure China Gateway deployments failed because the Azure Marketplace VM image for Azure China North 3 was not yet published. The image is now available, and new Azure China Gateway deployments succeed.</td></tr>
    <tr><td>AVX-78671</td><td>Fixed an issue where enabling Logging on the Default Action Rule and then disabling it could cause the Monitor tab to continue showing log entries for that rule for up to one hour after Logging was turned off.</td></tr>
    <tr><td>AVX-79012</td><td>Fixed an issue where some gateways could become stuck in a failed configuration-push state for an extended period after an Image Upgrade to Aviatrix 10.0.0 (from 9.0.10), primarily on lower-memory gateway instance types (for example, AWS t3.micro). Affected gateways could show a "Not Up-To-Date" config status and a down backup tunnel hours after the image upgrade completed.</td></tr>
    <tr><td>AVX-79057</td><td>Fixed an issue where a failed Aviatrix gateway deployed in GCP (GCE) could fail to auto-restart, leaving the gateway in a down state until manually restarted.</td></tr>
    <tr><td>AVX-79521</td><td>Fixed an issue where the Controller allowed onboarding of multiple Aviatrix access accounts that mapped to the same underlying cloud service provider (CSP) account, which could lead to unpredictable configuration and operational behavior in features that assume a one-to-one relationship between an Aviatrix access account and a CSP account. The Controller now blocks new onboarding of duplicate access accounts across all supported CSPs (AWS, Azure, GCP, OCI, and Alibaba, including GovCloud and China variants). Existing duplicate access accounts onboarded on earlier Controller versions continue to operate as-is and are not automatically removed; Aviatrix recommends consolidating them to a single access account per CSP account.</td></tr>
    <tr><td>AVX-79580</td><td>Fixed an issue where the Controller could fail to remember that it had already notified users about an available new software version, which caused repeated new-release notification emails for the same available version. Users and distribution lists configured to receive new-release notification emails no longer receive duplicate daily emails for the same version.</td></tr>
    <tr><td>AVX-80347</td><td>Fixed an issue where a packet capture that had been stopped from the CoPilot UI (**Gateway Diagnostics > Packet Capture**) could continue running in the background on the affected gateway. This could cause any subsequent packet capture attempted on the same gateway to silently return no data, and in more severe cases could leave the Controller unresponsive.</td></tr>
    <tr><td>AVX-80983</td><td>Fixed an issue where Azure Security Group Management could unexpectedly delete and recreate a security group rule during gateway launch when an Azure API throttling response on a rule-existence check was misinterpreted as the rule not existing.</td></tr>
    <tr><td>AVX-80992</td><td>Fixed an issue where Cloud Asset Inventory (CAI) could time out when a GCP service account was linked to a very large number of project IDs, which could leave cleanup of deleted GCP resources incomplete and cause stale resource entries to accumulate.</td></tr>
    <tr><td>AVX-80997</td><td>Fixed an issue where GCP event logging could fail when a Cloud Asset Inventory service account was linked to more than approximately 100 GCP projects, causing the event logging filter to exceed the Google Cloud Logging API character limit.</td></tr>
    <tr><td>AVX-81404</td><td>Fixed an issue where, in large-scale environments with a high number of SmartGroups and IP prefixes, a Transit Gateway protecting Site-to-Cloud (S2C) traffic through FireNet could experience intermittent packet loss under sustained traffic load. This was observed primarily on Azure Transit Gateways, where compute resource limits were reached first at scale, but the underlying condition was not specific to any single cloud provider.</td></tr>
    <tr><td>AVX-81892</td><td>Fixed a rare deadlock in the internal policy-update path on gateways enforcing Distributed Cloud Firewall (DCF) policies that include SmartGroups with FQDN selectors. The deadlock could previously cause the gateway data-plane process to stop forwarding traffic while remaining alive. The gateway process did not exit and was not marked unhealthy by existing watchdogs. This was more likely when the FQDN selector resolved to a set of addresses that rotated frequently (short DNS TTL), because each resolution change triggered a policy reload that raced with an internal hit-counter update. Recovery previously required manually restarting the affected gateway. WebGroup (SNI-based) policies and gateways not using FQDN-selector SmartGroups were not affected by the deadlock.</td></tr>
  </tbody>
</table>

## Known Issues in Aviatrix Release 10.1.10

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

  <tbody>
    <tr><td>AVX-80977</td><td>A VPN user's profile assignment could appear as N/A immediately after the user was attached to a profile through the API, until the user's next reconnection.<br /><br />**Impact:**<br /><br /><ul><li>The user's profile displays as N/A until the user's next reconnection, even though the profile attachment succeeded.</li><li>This can cause confusion when auditing or verifying profile-based access policies shortly after attachment.</li></ul>**Workaround:**<br /><br />Have the affected user reconnect to update the displayed profile assignment. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-81230</td><td>Enabling both Policy-Based Routing (PBR) and NAT logging under User VPN settings can cause high CPU utilization on the User VPN gateway during data-plane traffic. The high CPU usage occurs because NAT log entries generated by PBR are written to the gateway's serial console.<br /><br />**Impact:**<br /><br />User VPN gateways with both PBR and NAT logging enabled may experience elevated CPU utilization while passing data-plane traffic, which can degrade VPN gateway performance.<br /><br />**Workaround:**<br /><br />Disable NAT logging on the affected User VPN gateway. If NAT logging must remain enabled, contact [Aviatrix Support](https://support.aviatrix.com/) to apply a backend workaround.</td></tr>
    <tr><td>AVX-81576</td><td>**Description:** During a Gateway resize operation (for example, changing the Gateway's underlying instance or VM size), the Gateway can experience a temporary period of traffic loss during the resize. This has been observed during testing on GCP, AWS, and Azure Gateways, where a resize between certain instance sizes produced approximately 2 minutes of packet loss.<br /><br />**Impact:**<ul><li>A Gateway resize can result in a brief traffic interruption, observed at approximately 2 minutes in testing.</li><li>This has been confirmed to occur on GCP, AWS, and Azure Gateways.</li></ul>**Workaround:**<br /><br />No workaround is currently available. A fix is planned for a future 10.1.x maintenance release.</td></tr>
    <tr><td>AVX-81949</td><td>After a gateway software rollback, a small subset of HA gateways may incorrectly display the previous software version as the same value as the current software version, instead of the pre-rollback version.<br /><br />**Impact:**<ul><li>Affects the reported **Previous Version** on HA gateways after a Gateway Software Rollback.</li><li>The rollback itself completes successfully and the gateway runs on the intended target version; only the version display is affected.</li><li>Other gateways in the same rollback operation display the previous and current versions correctly.</li></ul>**Workaround:**<br /><br />No functional workaround is required. The rollback operation is successful despite the display discrepancy. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</td></tr>
    <tr><td>AVX-82309</td><td>**Description:** When a new pod joins a Kubernetes Workload SmartGroup after a gateway's Distributed Cloud Firewall (DCF) policy has already been computed, the gateway continues enforcing the previous member list and does not permit traffic from the new pod. The gateway's cached copy of the SmartGroup's members is not refreshed to include the new address until state sync restarts. The same condition can also affect other SmartGroup types, such as CIDR-based or CSP-tag-based SmartGroups, when a new address appears in a VPC that did not previously have any matching addresses.<br /><br />**Impact:**<ul><li>New pod IPs, or other newly added addresses, that join an affected SmartGroup are not enforced by the gateway's DCF policy until state sync restarts, which can allow or deny traffic in a way that does not match the configured policy intent.</li><li>The condition can recur each time a new address is added to an affected SmartGroup, including through routine Infrastructure as Code (for example, Terraform) changes.</li></ul>**Workaround:**<br /><br />Restart ConduitDaemon on the Controller to refresh the affected gateway's SmartGroup membership. In CoPilot, go to **Settings > Resources > System Health > Monitor - Controller > Services**, select **View All Resources**, locate **ConduitDaemon**, and click the restart icon. Because the condition can recur whenever a new address is added to an affected SmartGroup, this is a partial mitigation rather than a permanent fix. If restarting ConduitDaemon does not resolve the issue, 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.
Issue	Description
AVX-73433	Fixed an issue where changing the Interface RX Queue Size setting on a gateway did not automatically apply the new value to interfaces created after the change. The updated RX Queue Size setting now applies to all interfaces without requiring a gateway reboot or reapplying the configuration.
AVX-73436	Fixed an issue where, when onboarding an Azure route table using the `update_spoke_vpc_route_table` API, the default route (0.0.0.0/0) was not programmed into the spoke VNET route table if the Spoke Gateway had learned the default route from an attached Egress Transit Gateway, a Site-to-Cloud connection through a transit, or another Spoke Gateway.
AVX-75452	Fixed an issue where, in Azure environments, Distributed Cloud Firewall (DCF) Security Group Orchestration changed the name of a subnet to all lowercase when attaching a Network Security Group (NSG) to it. This caused Infrastructure as Code tools such as Terraform, which treat resource names as case-sensitive, to flag the affected subnets for replacement.
AVX-78524	Fixed an issue where new Azure China Gateway deployments failed because the Azure Marketplace VM image for Azure China North 3 was not yet published. The image is now available, and new Azure China Gateway deployments succeed.
AVX-78671	Fixed an issue where enabling Logging on the Default Action Rule and then disabling it could cause the Monitor tab to continue showing log entries for that rule for up to one hour after Logging was turned off.
AVX-79012	Fixed an issue where some gateways could become stuck in a failed configuration-push state for an extended period after an Image Upgrade to Aviatrix 10.0.0 (from 9.0.10), primarily on lower-memory gateway instance types (for example, AWS t3.micro). Affected gateways could show a "Not Up-To-Date" config status and a down backup tunnel hours after the image upgrade completed.
AVX-79057	Fixed an issue where a failed Aviatrix gateway deployed in GCP (GCE) could fail to auto-restart, leaving the gateway in a down state until manually restarted.
AVX-79521	Fixed an issue where the Controller allowed onboarding of multiple Aviatrix access accounts that mapped to the same underlying cloud service provider (CSP) account, which could lead to unpredictable configuration and operational behavior in features that assume a one-to-one relationship between an Aviatrix access account and a CSP account. The Controller now blocks new onboarding of duplicate access accounts across all supported CSPs (AWS, Azure, GCP, OCI, and Alibaba, including GovCloud and China variants). Existing duplicate access accounts onboarded on earlier Controller versions continue to operate as-is and are not automatically removed; Aviatrix recommends consolidating them to a single access account per CSP account.
AVX-79580	Fixed an issue where the Controller could fail to remember that it had already notified users about an available new software version, which caused repeated new-release notification emails for the same available version. Users and distribution lists configured to receive new-release notification emails no longer receive duplicate daily emails for the same version.
AVX-80347	Fixed an issue where a packet capture that had been stopped from the CoPilot UI (Gateway Diagnostics > Packet Capture) could continue running in the background on the affected gateway. This could cause any subsequent packet capture attempted on the same gateway to silently return no data, and in more severe cases could leave the Controller unresponsive.
AVX-80983	Fixed an issue where Azure Security Group Management could unexpectedly delete and recreate a security group rule during gateway launch when an Azure API throttling response on a rule-existence check was misinterpreted as the rule not existing.
AVX-80992	Fixed an issue where Cloud Asset Inventory (CAI) could time out when a GCP service account was linked to a very large number of project IDs, which could leave cleanup of deleted GCP resources incomplete and cause stale resource entries to accumulate.
AVX-80997	Fixed an issue where GCP event logging could fail when a Cloud Asset Inventory service account was linked to more than approximately 100 GCP projects, causing the event logging filter to exceed the Google Cloud Logging API character limit.
AVX-81404	Fixed an issue where, in large-scale environments with a high number of SmartGroups and IP prefixes, a Transit Gateway protecting Site-to-Cloud (S2C) traffic through FireNet could experience intermittent packet loss under sustained traffic load. This was observed primarily on Azure Transit Gateways, where compute resource limits were reached first at scale, but the underlying condition was not specific to any single cloud provider.
AVX-81892	Fixed a rare deadlock in the internal policy-update path on gateways enforcing Distributed Cloud Firewall (DCF) policies that include SmartGroups with FQDN selectors. The deadlock could previously cause the gateway data-plane process to stop forwarding traffic while remaining alive. The gateway process did not exit and was not marked unhealthy by existing watchdogs. This was more likely when the FQDN selector resolved to a set of addresses that rotated frequently (short DNS TTL), because each resolution change triggered a policy reload that raced with an internal hit-counter update. Recovery previously required manually restarting the affected gateway. WebGroup (SNI-based) policies and gateways not using FQDN-selector SmartGroups were not affected by the deadlock.
Issue	Description
AVX-80977	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. Impact: The user's profile displays as N/A until the user's next reconnection, even though the profile attachment succeeded. This can cause confusion when auditing or verifying profile-based access policies shortly after attachment. Workaround: Have the affected user reconnect to update the displayed profile assignment. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.
AVX-81230	Enabling both Policy-Based Routing (PBR) and NAT logging under User VPN settings can cause high CPU utilization on the User VPN gateway during data-plane traffic. The high CPU usage occurs because NAT log entries generated by PBR are written to the gateway's serial console. Impact: User VPN gateways with both PBR and NAT logging enabled may experience elevated CPU utilization while passing data-plane traffic, which can degrade VPN gateway performance. Workaround: Disable NAT logging on the affected User VPN gateway. If NAT logging must remain enabled, contact [Aviatrix Support](https://support.aviatrix.com/) to apply a backend workaround.
AVX-81576	Description: During a Gateway resize operation (for example, changing the Gateway's underlying instance or VM size), the Gateway can experience a temporary period of traffic loss during the resize. This has been observed during testing on GCP, AWS, and Azure Gateways, where a resize between certain instance sizes produced approximately 2 minutes of packet loss. Impact: A Gateway resize can result in a brief traffic interruption, observed at approximately 2 minutes in testing. This has been confirmed to occur on GCP, AWS, and Azure Gateways. Workaround: No workaround is currently available. A fix is planned for a future 10.1.x maintenance release.
AVX-81949	After a gateway software rollback, a small subset of HA gateways may incorrectly display the previous software version as the same value as the current software version, instead of the pre-rollback version. Impact: Affects the reported Previous Version on HA gateways after a Gateway Software Rollback. The rollback itself completes successfully and the gateway runs on the intended target version; only the version display is affected. Other gateways in the same rollback operation display the previous and current versions correctly. Workaround: No functional workaround is required. The rollback operation is successful despite the display discrepancy. Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.
AVX-82309	Description: When a new pod joins a Kubernetes Workload SmartGroup after a gateway's Distributed Cloud Firewall (DCF) policy has already been computed, the gateway continues enforcing the previous member list and does not permit traffic from the new pod. The gateway's cached copy of the SmartGroup's members is not refreshed to include the new address until state sync restarts. The same condition can also affect other SmartGroup types, such as CIDR-based or CSP-tag-based SmartGroups, when a new address appears in a VPC that did not previously have any matching addresses. Impact: New pod IPs, or other newly added addresses, that join an affected SmartGroup are not enforced by the gateway's DCF policy until state sync restarts, which can allow or deny traffic in a way that does not match the configured policy intent. The condition can recur each time a new address is added to an affected SmartGroup, including through routine Infrastructure as Code (for example, Terraform) changes. Workaround: Restart ConduitDaemon on the Controller to refresh the affected gateway's SmartGroup membership. In CoPilot, go to Settings > Resources > System Health > Monitor - Controller > Services, select View All Resources, locate ConduitDaemon, and click the restart icon. Because the condition can recur whenever a new address is added to an affected SmartGroup, this is a partial mitigation rather than a permanent fix. If restarting ConduitDaemon does not resolve the issue, contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.