Aviatrix Controller 10.1.0 Release Notes

Release Date: 17 September 2026 Release Notes Last Updated: 19 October 2026

​

Corrected Issues in Aviatrix Release 10.1.0

Issue	Description
AVX-64868	Fixed an issue where the keepalived VRRP state was not always reported accurately to the Controller during rapid VRRP state transitions, which could cause the Controller UI to show incorrect VRRP status such as both peers reporting Primary or Initializing.
AVX-66631	Fixed an issue where transit gateways with large-scale tunnel deployments (1300+ tunnels) could experience extended traffic loss after an image upgrade completed, due to delayed tunnel reconfiguration.
AVX-70543	Fixed an issue where DPI/IDS or Layer7 policies configured with “Destination: Anywhere” on HA-enabled spoke gateways became invalid and caused traffic drops when the destination smart group contained private CIDRs.
AVX-71320	Fixed an issue where source IP translation (SNAT) did not function correctly for policy-based Site-to-Cloud connections when traffic flowed from cloud to site. The configured SNAT IP is now correctly applied instead of the original source IP.
AVX-71559	Fixed an issue where a batch gateway image upgrade in Azure could cause some gateways to fail during the upgrade process, with affected gateways showing an error indicating that gateway information could not be retrieved in Azure ARM cloud.
AVX-72940	Fixed an issue where creating a new gateway with the same name as an existing gateway could delete local files for the existing gateway when the creation failed, which could break SSH access to the existing gateway.
AVX-73334	Fixed an issue where the Aviatrix VPN Client could not connect to a VPN gateway with FIPS 140-3 enabled, returning an AUTH_FAILED - client incompatible with this server error. FIPS 140-3 on the gateway requires OpenVPN 2.6.0 or later (RFC 5705 TLS Keying Material Exporters), which older Aviatrix VPN Client versions did not support. An updated Aviatrix VPN Client built on OpenVPN 2.6.x or later now supports connecting to FIPS 140-3-enabled VPN gateways.
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-75244	Fixed an issue in the Controller’s asset management service where periodic full inventory cycles could exhaust available TCP ports when connecting to its internal database, which could cause intermittent connection failures in other Controller services and temporarily delay asset inventory and SmartGroup updates.
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, which caused Infrastructure as Code tools such as Terraform, which treat resource names as case-sensitive, to flag the affected subnets for replacement.
AVX-75586	Fixed a race condition where Terraform-driven spoke-to-transit gateway attachments could fail intermittently because the gateway creation API returned before the gateway was operationally ready.
AVX-75599	Fixed an issue where the TrafficServer (ATS) process on gateways could crash when a custom Suricata rule feed containing a large number of rules (20,000 or more) was applied to a Distributed Cloud Firewall intrusion analysis profile, which caused traffic interruption on affected gateways.
AVX-76132	Fixed an issue where more than one OpenVPN gateway could not be configured behind a UDP Load Balancer. Only the first gateway was retained, and additional gateways were incorrectly excluded.
AVX-77490	Fixed an issue where the Controller UI displayed a “Syntax Error” message when creating an HA gateway for a spoke or transit gateway on Controller 10.0.0. HA gateway creation from the Controller UI now succeeds on Controller 10.1.0.
AVX-77618	Fixed an issue where Controller diagnostics could report NTP-related errors that did not reflect the actual NTP synchronization status of the Controller.
AVX-77714	Fixed an issue where creating a Smart Group with the Kubernetes workload resource type could fail with an “invalid selector combination” error when using Region, Account Name, or Account ID as a match criterion. Supported Kubernetes workload selectors (cluster ID, namespace, service, and pod) are unchanged.
AVX-78500	Fixed an issue where disabling Distributed Cloud Firewall (DCF) on a gateway did not fully remove DCF policy enforcement from all gateway interfaces when there was no accompanying policy change, which could leave traffic evaluated against a previously applied DCF policy even though DCF appeared disabled.
AVX-78524	Fixed an issue where new Azure China Gateway deployments failed on Controller 10.0.0 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 on Controller 10.1.0.
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 enter a config_fail state and remain stuck 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-79173	Fixed a timing-related issue in the gateway’s post-upgrade configuration sequence that could intermittently leave an Aviatrix gateway in the config_fail state after an image upgrade.
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. Starting in Controller 10.1.0, the Controller 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-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.

​

Known Issues in Aviatrix Release 10.1.0

Issue	Description
AVX-62299	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. To avoid this issue, follow the correct upgrade sequence: 1. Upgrade the PSF Gateway first. 2. Wait for the PSF Gateway upgrade to complete successfully. 3. Then upgrade the dependent Spoke Gateways.
AVX-67126	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.
AVX-70958	When clients use HTTP/2 connections, TrafficServer incorrectly reuses origin connections, potentially causing connection handling issues in MITM SNI verification scenarios. Impact: Origin connections may be shared inappropriately between different client requests MITM SNI verification may not function as expected Workaround: Use both IP address and SNI instead of IP alone to ensure proper connection isolation.
AVX-71820	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. Impact: VPN gateway deployment fails Error message does not clearly indicate the root cause Affected Scenario: Load balancer-enabled VPN gateway deployments on Controller versions 8.0, 8.1, and 8.2. Workaround: Ensure that the VPN CIDR does not overlap with existing gateways behind the load balancer before deployment. Contact Aviatrix Support for assistance.
AVX-76413	Description: When the controller’s gateway-status tracking restarts and finds gateways recorded as “Down,” the controller reprograms the network as if those gateways are down, without allowing time for the gateways to reconnect and confirm they are up. This can occur when the controller has previously lost connectivity to gateways (for example, during a transient network issue) and the tracking service then restarts while the gateways themselves remain healthy and continue forwarding traffic. Impact: A temporary data plane disruption occurs while the controller has the gateways marked as down. The controller automatically detects the gateways are up and reprograms the network correctly immediately afterward. In a large-scale user deployment (~1,400 gateways), full recovery completed in approximately 6 minutes. The underlying behavior has existed for 4+ years and has been observed in a user environment only once. Workaround: Not applicable. The system recovers automatically, no user action required. Recovery typically completes within minutes (~6 min observed in a ~1,400-gateway deployment; smaller deployments recover faster).
AVX-77135	When the Use SSL to connect option is enabled for LDAP configuration, VPN gateway configuration updates may not apply correctly. Impact: VPN gateway authentication using LDAP with TLS may not function as expected Manual intervention may be required to ensure VPN authentication is properly configured Workaround: Contact Aviatrix Support for assistance.
AVX-79855	When Distributed Cloud Firewall is disabled on a transit gateway with Site2Cloud (S2C) or other external connections landing on it, and no policy change is queued at the time, existing DCF filtering rules on the interface are not removed. The disable path is skipped when there is no policy difference to push. Impact: After DCF is disabled on the affected transit gateway, previously installed DCF filtering rules remain in effect on the interface and continue to filter traffic. Customers may see traffic still being subject to DCF filtering long after the feature was disabled. Workaround: Restart the Aviatrix gateway to remove the stale DCF filter rules. Alternatively, contact Aviatrix Support to have the stale DCF filter rules manually removed.
AVX-80343	Description: When multiple Kubernetes clusters have namespaces with the same name and those namespaces are referenced as source SmartGroups in a Distributed Cloud Firewall rule, the Controller may generate incorrect Kubernetes NetworkPolicies inside the target clusters. Impact: The generated NetworkPolicies may allow or deny traffic in a way that does not match the intent of the DCF rule. Pods in an unintended namespace may be selected as the source of the policy. Workaround: When authoring intra-cluster DCF rules, add a specific Kubernetes cluster ID in addition to any other selector (such as labels or namespace name) so the policy is scoped to the intended cluster. Contact Aviatrix Support if this affects a production environment.
AVX-80572	Description: When Distributed Cloud Firewall is enabled, the Controller allows Single IP SNAT to be enabled on a spoke gateway that is attached to an egress transit. After Distributed Cloud Firewall is subsequently disabled, this configuration remains, leaving the spoke in a state where Single IP SNAT is enabled while it is still attached to an egress transit. This combination is normally blocked by design. Impact: Egress traffic behavior on the affected spoke may not match the intended egress topology because the standard configuration guardrail was bypassed by the enable/disable sequence. Workaround: If Single IP SNAT was enabled on a spoke gateway while it was using local egress with Distributed Cloud Firewall enabled, manually disable Single IP SNAT on that spoke gateway after disabling Distributed Cloud Firewall to return it to a supported egress configuration.
AVX-80753	Description: In AWS GovCloud environments, after enabling IntraVPC micro-segmentation on a VPC, the orchestration status may continue to show no VPCs in progress for an extended period, even though enablement was accepted. This occurs because asset discovery for AWS GovCloud accounts does not receive the same near-real-time update signals used in commercial AWS regions, so status information only refreshes on the periodic full inventory cycle (approximately every 4 hours) unless manually refreshed. Impact: After enabling IntraVPC micro-segmentation on an AWS GovCloud VPC, the orchestration status may show no VPCs in progress for up to several hours. This delayed status reporting can be mistaken for a failure to enable micro-segmentation, even though security group orchestration is proceeding correctly in the background. Workaround: In CoPilot, use Refetch CSP Resources for the affected AWS GovCloud account to immediately refresh the orchestration status instead of waiting for the next periodic inventory cycle.
AVX-80823	Description: On Controller 10.1.0, a Distributed Cloud Firewall (DCF) DENY rule that matches on a WebGroup (SNI) is enforced correctly for traffic using the local egress path, but is not enforced for traffic using the default egress path through a FireNet whose inline firewall is a third-party appliance rather than a DCF-enabled gateway. On that path, the connection completes instead of being blocked. Layer 4 DENY rules are not affected; they continue to be enforced correctly on the same path. Impact: A WebGroup (SNI) DENY rule can silently fail to block traffic on the default egress path through FireNet when the inline firewall is not a DCF-enabled gateway. Traffic that is expected to be blocked is instead permitted, with no warning that the policy was not enforced. Layer 4 DENY rules are unaffected and continue to enforce correctly in this configuration. Workaround: When DCF is used together with a third-party firewall in FireNet, create consistent policies between DCF and the third-party firewall configuration.
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 for assistance.
AVX-80992	Description: Cloud Asset Inventory (CAI) inventories every project ID listed in a GCP service account by default. In GCP environments with a very large number of project IDs under a single service account, this inventory operation can exceed the allotted timeout period. Impact: Large-scale GCP deployments with many project IDs per service account may experience CAI inventory timeouts. When an inventory cycle times out, cleanup of deleted GCP resources does not complete, which can cause stale resource entries to accumulate over time. Workaround: Contact Aviatrix Support if you observe CAI inventory timeouts or stale resource accumulation in a large-scale GCP deployment. A configuration option to scope inventory to a single project ID is planned for a future release.
AVX-81091	Description: The Controller’s GCP event monitoring can fail to query event logs for a GCP account when that account’s associated service account is linked to a very large number of GCP projects. The constructed log-query filter can exceed an internal size limit, causing the query to fail. When this occurs, the Controller logs an error similar to Filter cannot be longer than 20000 characters. Impact: GCP account event log data does not update in the Controller for GCP accounts whose service account is linked to a very large number of projects. Workaround: No workaround is available at this time. A fix is being delivered in upcoming maintenance releases for the 8.2.x, 9.0.x, and 10.0.x lines.
AVX-81149	Description: Enabling the global VRF (segmentation attach) setting on a Controller that has existing Transit-to-Transit peerings created before VRF was enabled can cause the affected Transit Gateways to report a “Configuration Not Up-To-Date” status. A brief traffic interruption may also occur on the affected peerings when VRF is enabled in this scenario. Impact: Transit Gateways with pre-existing Transit-to-Transit peerings may show a “Configuration Not Up-To-Date” status after enabling the global VRF setting. A brief traffic interruption (up to a few minutes) may occur on the affected peerings. Workaround: No workaround is currently available. Contact Aviatrix Support before enabling VRF on a Controller with existing Transit-to-Transit peerings.
AVX-81256	Description: During a gateway software upgrade, an automatic security-certificate rotation on the gateway can occur at nearly the same time the upgrade process validates the gateway’s certificate. When this timing overlap occurs, the upgrade can intermittently fail with a certificate validation error. Impact: The gateway upgrade can fail intermittently due to a certificate validation error caused by the timing overlap described above. This is a timing-dependent (race) condition; most upgrades are not affected. Workaround: Retry the upgrade. This has been confirmed to resolve the issue in observed cases. If the upgrade continues to fail after a retry, this indicates a separate, unrelated issue rather than a recurrence of this one; contact Aviatrix Support for further investigation.
AVX-81404	Description: In large-scale environments with a high number of SmartGroups and IP prefixes, a Transit Gateway protecting Site-to-Cloud (S2C) traffic through FireNet may experience intermittent packet loss under sustained traffic load. This has been observed primarily on Azure Transit Gateways, where compute resource limits are reached first at scale, but the underlying condition is not specific to any single cloud provider. Impact: Intermittent packet loss may occur on FireNet-protected S2C traffic in large-scale environments with many SmartGroups and prefixes. This has been observed primarily on Azure Transit Gateways, but may also occur on other cloud providers at sufficient scale. Workaround: No workaround is currently available. A fix is planned for a future maintenance release.
AVX-81444	Description: On a spoke gateway with Transparent Inspection enabled through an AWS Transit Gateway, and a Distributed Cloud Firewall (DCF) policy that protects both east-west and egress traffic, a Controller reboot can cause the gateway to lose track of which traffic should bypass source NAT (SNAT). As a result, east-west traffic between spoke resources can be incorrectly source-NATed, and egress traffic can stop routing through the gateway as expected. Impact: East-west traffic between spoke resources can be affected by unexpected source NAT (SNAT) after a Controller reboot, so the destination host sees the gateway’s interface IP as the traffic source instead of the original client IP. Egress traffic from affected clients can stop routing through the spoke gateway as expected after a Controller reboot. Workaround: If you suspect you are affected by this issue, contact Aviatrix Support for assistance.
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-81892	On gateways enforcing Distributed Cloud Firewall (DCF) policies that include SmartGroups with FQDN selectors, an internal policy-update path can deadlock in rare cases, causing the gateway data-plane process to stop forwarding traffic while remaining alive. The deadlock is more likely when the FQDN selector resolves to a set of addresses that rotate frequently (short DNS TTL), because each resolution change triggers a policy reload that races with an internal hit-counter update. Impact: Affected gateways stop forwarding traffic when the deadlock occurs, even though the gateway process itself does not exit and is not marked unhealthy by existing watchdogs. WebGroup policies (SNI-based) are not affected. Gateways carrying no DCF policies, or DCF policies that do not use FQDN-selector SmartGroups, are not affected. Recovery requires manually restarting the affected gateway. Workaround: Where equivalent coverage is available via a cloud provider external service feed (for example, the AzureDevOps service feed for traffic to Azure DevOps endpoints), remove the redundant FQDN-selector SmartGroup from the affected policy rule and rely on the service feed, which updates on a much slower cadence. If the deadlock occurs, restart the affected gateway to restore traffic. Contact Aviatrix Support for assistance identifying exposed gateways and reviewing DCF policy configurations.
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 for assistance.