> ## 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. # 8.0.10 Release Notes > Release Date: 11 August 2025 Release Notes Last Updated: 25 September 2025 **Release Date:** 11 August 2025\ **Release Notes Last Updated:** 22 June 2026 ## Corrected Issues in Aviatrix Release 8.0.10 | Issue ID | Description | | - | - | | AVX-60731 | Fixed an issue where BGP gateways could crash when receiving route updates containing AS-SET information in the AS-PATH attribute. The system now rejects AS-SET and AS\_CONFED\_SET using default configuration, improving BGP stability and aligning with industry standards. | | AVX-63016 | Fixed an issue where OpenVPN gateways in split tunnel mode did not propagate newly added Additional CIDRs to clients. The problem occurred because the OpenVPN service was not automatically restarted after CIDR updates, requiring manual restarts. The fix ensures that route and DNS configuration changes now properly trigger service restarts, so Additional CIDRs and DNS settings are pushed to clients without manual intervention. | | AVX-63522 | Fixed an issue where GCP gateways with FireNet or BGPoLAN enabled were incorrectly configured with subnet-based netmasks instead of the required /32 prefix. This caused routing failures and connectivity issues with firewall appliances. | | AVX-63608 | Fixed an issue where gateway resize operations could fail with a KeyError: 'src' during validation. This occurred when resizing gateways, including attempts to resize to the same instance size for recovery. The fix improves peer data handling to ensure resize operations complete successfully. | | AVX-64741 | Fixed an issue where transit peering status was shown as UNKNOWN in the Controller even though tunnels were established. The problem was caused by Edge gateways sending invalid peer values ("\"), which blocked route exchange. The fix adds proper validation of peer IP values so that transit status is reported correctly and routes are exchanged as expected. | | AVX-64774 | Fixed an issue where backup restoration failed on GCP controllers when restoring from earlier versions (such as 7.2.5090) to 8.0.0 and later. The issue was caused by a Google Cloud Storage API error during the upload phase. The fix includes a library update and improved error handling to ensure successful restoration. | | AVX-65050 | Fixed an issue where DCF policies failed to apply to Azure gateways due to Cloud Asset Inventory (CAI) not resolving Azure subnets correctly. This was caused by missing Azure VNET GUID metadata during upgrades, resulting in Smart Group resolution failures and incorrect policy rule enforcement. The fix improves Azure metadata handling and ensures consistent DCF policy application. | | AVX-65213 | Fixed an issue where system diagnostics could fail with an AttributeError during Controller operations. The error occurred when collecting CloudXD process data that unexpectedly returned None. The fix adds proper null checks to ensure the diagnostic collection completes successfully. | | AVX-65565 | Fixed an issue where Distributed Cloud Firewall (DCF) eBPF programs were not fully cleaned up from gateway interfaces when DCF features were disabled. The cleanup logic has been improved to ensure all interfaces are properly cleared, preventing residual eBPF programs from remaining after disabling Site-to-Cloud DCF or other DCF features. | | AVX-65698 | Fixed a memory leak in the DCF Traffic Server (TS\_MAIN process) that could cause gateway reboots during high-volume threat IP traffic processing. The issue occurred when multiple DCF rules with ThreatIQ external groups were triggered by continuous probing to inactive threat IPs. Memory usage now stabilizes under sustained load. | | AVX-66162 | Fixed an issue where DNAT and SNAT configuration updates failed on gateways with policy-based Site2Cloud tunnels. The NAT validation logic has been corrected to properly resolve interfaces, ensuring DNAT and SNAT rules can now be created, modified, or deleted through the Controller UI without errors. | | AVX-66961 | 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. | | AVX-67128 | Fixed an issue where user-uploaded SSL certificates were not automatically restored during Controller migration to version 8.0.0. This caused FQDN-based secure access to the Controller UI to fail post-migration. The fix ensures that existing certificates are now retained and restored during the migration process. | | AVX-68308 | Fixed an issue in UserConnect 7.2 where gateway resize operations could fail with a KeyError: 'src' exception. This occurred in deployments upgraded from version 6.6 with non-HPE peering configurations and prevented users from resizing gateways once they entered a config\_fail state. | ## Known Issues in Aviatrix Release 8.0.10 | Issue ID | Description | | - | - | | AVX-58696 | TCP MSS clamping is not supported on Standalone Gateways in Release 7.1 and later. | | AVX-59298 | In Aviatrix Controller 8.0 versions, when deploying Edge Spoke or Edge Transit Gateways in Megaport Virtual Edge (MVE), less than 5 VNICs can result in the gateway failing to initialize. This issue occurs because the cloud-init expects 5 interfaces.

**Workaround:** To ensure the successful deployment of Edge Spoke or Edge Transit Gateways in MVE, configure the MVE with 5 VNICs. | | AVX-59376 | When using Controller High Availability (HA) with Controllers version 8.0 and later, the standby Controller will fail to launch correctly. This is because the HA mechanism relies on a fixed software version specified in the Auto Scaling Group (ASG) launch template, but with Controllers version 8.0 and later now require the version to be passed dynamically through cloud-init during instance creation. This issue occurs only in environments that use: Controller HA for with Controllers version 8.0 and later, AWS Auto Scaling Group (ASG) launch templates, The default CloudFormation HA deployment method.

**Workaround:** Use the new CloudFormation template to enable AWS Controller High Availability. This template supports dynamic version injection and restores compatibility with Controllers version 8.0 and later in supported regions. For versions 7.x and earlier, use the existing CloudFormation script (without the v3 suffix). Note: This solution is not available in AWS Gov Cloud regions. | | AVX-61355 | Azure Standard\_B1ms SNAT-enabled Egress Spoke Gateways may experience significant throughput drops under high connection loads. This limitation is caused by the Azure Standard\_B1ms instance type, which has limited compute and network resources.

**Affected Scenario:** SNAT-enabled Egress Spoke Gateways using Azure Standard\_B1ms under high connection loads.

**Workaround:** Upsize the Spoke Gateway to a larger Azure instance type for workloads that require more than 10K concurrent connections or consistent network throughput. | | AVX-62003 | 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.

**Impact:** Existing gateways may be deleted during image upgrade. Replacement gateway creation fails due to missing subscription. Customers may experience connectivity loss and dangling gateway entries in the Controller. Manual intervention required, leading to support escalations.

**Workaround:** None. To avoid outages, ensure the Controller subscription includes access to the required Azure image before attempting upgrades. | | AVX-62011 | Auto migration will not work from 7.2 to 8.0 when proxy is enabled. You must use a manual backup and restore process to perform the upgrade. Follow the steps below to back up and restore during the upgrade: If your Controller software version is 7.2.5012 or older, upgrade both the Controller and Gateways to the latest 7.2 build. Delete the proxy configuration from Controller UI > Settings > Advanced > Proxy. Back up the Controller from Controller UI > Settings > Maintenance > Backup & Restore > Backup. Shut down the old Controller. Launch the new 8.0 Controller and transfer the EIP. Once the 8.0 Controller is up, restore the Controller using the backup config from Controller UI > Settings > Maintenance > Backup & Restore > Restore. Add back the proxy configuration from Controller UI > Settings > Advanced > Proxy. Software upgrade the Gateways to 8.0. | | AVX-62147 | The Controller auto-migration and Gateway upgrade features do not function properly when the Aviatrix Controller has proxy settings enabled. In such environments, migration may fail, and you must follow a manual backup and restore process instead of using the standard auto-migration workflow. This limitation is due to current backend behavior that does not support migration through proxy-enabled setups.

**Affected Scenario:** Controller and Gateway upgrades using auto-migration in environments where proxy settings are enabled on the Aviatrix Controller

**Check Whether You Are Affected:** In Controller UI: Go to Settings > Advanced > Proxy. In CoPilot UI: Go to Settings > Configuration > Private Mode > Proxy Servers. If proxy configurations are present in either location, your deployment is affected.

**Workaround:** Follow the manual backup and restore steps to upgrade the Aviatrix Controller and Gateways. | | AVX-62230 | When upgrading Aviatrix Gateways from version 7.2.x to 8.0.0 with TLS decryption enabled in Distributed Cloud Firewall (DCF), the Gateway automatically regenerates its TLS decryption certificate authority (CA). Because each Gateway maintains its own unique CA for security, the regenerated CA no longer matches the CA previously trusted by clients. As a result, you may experience the following issues after the upgrade: Failed TLS connections for decrypted traffic, Certificate trust errors in browsers or applications, Traffic disruption for services that rely on TLS inspection.

**Affected Scenario:** Gateways with TLS decryption enabled in DCF being upgraded from 7.2.x to 8.0.0

**Workaround:** If you have imported your own proxy CA and key, you can re-import the same certificate and key after the Gateway upgrade to maintain trust continuity. If you rely on the Aviatrix-generated CA: After the Gateway upgrade, export the new CA certificate from the Gateway and distribute it to clients. | | 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-62506 | 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.

**Workaround:** None

**Recommendations:**
- Schedule gateway upgrades during maintenance windows or low-traffic periods.
- Use HA deployments and upgrade gateways one at a time in HA pairs.
- Monitor logs for "Failed to load policy" messages to confirm when policies are reloaded. | | AVX-62542 | In environments where Distributed Cloud Firewall (DCF) and customized SNAT are used together, DCF rules may fail to match traffic correctly when the same SmartGroups are specified in both the source and destination fields. This is because the system does not account for the translated source address during rule evaluation. As a result, traffic may be unintentionally blocked by the DefaultDenyAll rule, and policies may not apply as expected—particularly in cross-cloud or cross-region scenarios.

**Affected Configurations:**
- Customized SNAT (not Single IP SNAT) configured on gateways
- DCF rules with overlapping SmartGroups in source and destination
- Environments involving SNAT-translated traffic

**Workaround:** In earlier versions, avoid using 0.0.0.0/0 as the destination in SNAT rules. Instead, specify only the required destination CIDRs. | | AVX-62636 | DCF rules pushed to Edge gateways may not account for NAT translations, leading to incorrect rule behavior and potential traffic filtering issues.

**Affected Deployments:**
- Edge gateways with DCF rules applied
- Environments using NAT to manage overlapping IP address spaces
- Traffic flows between cloud resources and Edge sites with DCF enforcement

**Workaround:** Avoid applying DCF rules to Edge gateways in environments with NAT or overlapping IP ranges. Explicitly exclude Edge from DCF deployment by using the following Provider Deployment API:
`
POST /v2.5/api/microseg/deploy-policy
{
"providers": ["AWS", "AZURE", "GCP"] // Include all desired cloud providers EXCEPT "EDGE"
}
` | | AVX-62712 | When recreating a policy-based Site-to-Cloud (S2C) VPN connection after deleting a previous one with the same remote CIDR, the system may incorrectly report a CIDR overlap error, even though the original connection has been removed. This occurs because the system does not fully clean up the remote CIDR information, causing it to believe the CIDR is still in use.

**Affected Scenario:** Recreating a policy-based Site-to-Cloud VPN connection using the same remote CIDR after deletion, in either of the following cases: The deleted connection was a route-based S2C connection on a gateway that still has other S2C connections. The deleted connection was a policy-based S2C connection.

**Workaround:** Contact Aviatrix Support to manually clear the cached CIDR information. | | AVX-62719 | The Distributed Cloud Firewall (DCF) policy writer writes approximately 40KB of data per gateway during each configuration snapshot, regardless of whether there are policy changes. In large deployments, this results in frequent and unnecessary write operations to the controller database.

**Affected Scenario:** DCF enabled across many gateways, Frequent configuration snapshots (triggered automatically or during updates)

**Impact:** Increased system load and database write activity, which may affect controller performance and stability in large-scale environments.

**Workaround:** There is no direct workaround at this time. Users operating at scale should monitor controller resource usage closely. Aviatrix is actively working to reduce unnecessary write operations in a future update. If performance issues are observed, contact Aviatrix Support for evaluation and potential tuning options. | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.