| 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, and 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 regions that do not support Lambda Function URLs. |
| 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: 1. If your Controller software version is 7.2.5012 or older, upgrade both the Controller and Gateways to the latest 7.2 build. 2. Delete the proxy configuration from Controller UI > Settings > Advanced > Proxy. 3. Back up the Controller from Controller UI > Settings > Maintenance > Backup & Restore > Backup. 4. Shut down the old Controller. 5. Launch the new 8.0 Controller and transfer the EIP. 6. Once the 8.0 Controller is up, restore the Controller using the backup config from Controller UI > Settings > Maintenance > Backup & Restore > Restore. 7. Add back the proxy configuration from Controller UI > Settings > Advanced > Proxy. 8. Software upgrade the Gateways from version 7.2 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 below to upgrade the Aviatrix Controller and Gateways: 1. If the Controller is running version 7.2.5012 or earlier, upgrade to the latest 7.2 build first. 2. Delete the proxy configuration in the Controller UI. 3. Back up the Controller from Settings > Maintenance > Backup & Restore > Backup in the CoPilot UI. 4. Shut down the old Controller. 5. Launch a new Controller with version 8.0 and reassign the EIP. 6. Restore the backup in the new Controller. 7. Reconfigure the proxy settings. 8. Upgrade the Gateways from version 7.2 to 8.0. A maintenance window is recommended for this manual upgrade, as it involves Controller downtime and multiple steps. |
| 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, and 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 newly generated CA certificate and add it to the trust bundles on client systems to restore trust and resume decrypted connections. |
| 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, and 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, and 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 with body {"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, or 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. |
| AVX-63175 | In Aviatrix Controller version 8.0, Edge Gateway version numbers may be incorrectly updated in the Controller UI after the gateway comes back online from a down state. This occurs even when no new software installation has taken place. Instead of preserving the actual version running on the Edge Gateway, the Controller may incorrectly overwrite it with its own version. This can lead to confusion during troubleshooting, upgrade planning, or compliance checks. Affected Environments: All Edge Gateway platforms, including Equinix Network Edge, AEP appliances, and other supported Edge deployments. The issue occurs whenever an Edge Gateway transitions from a “down” to “up” state for any reason other than initial installation (for example, reboot, network disruption, or manual restart). Workaround: Maintain a separate record of installed Gateway versions outside the Controller. Use the Edge Gateway’s local console or logs to verify the current version when planning upgrades or diagnosing issues. Note: This issue only affects Edge Gateways. Cloud provider (CSP) Gateways in AWS, Azure, GCP, or OCI are not affected. |
| AVX-63224 | In Controller release 8.0, gateway software upgrades take longer to complete compared to earlier versions. On average, the upgrade rate drops from approximately 14 gateways per minute in version 7.2 to approximately 11 gateways per minute in 8.0, which is an increase of about 20% in execution time. Affected Scenarios: Upgrading from version 7.2.x to 8.0.x, upgrading between 8.0.x versions. Impact: Only the upgrade duration is affected. Gateway functionality remains unaffected after a successful upgrade. Recommendations: Allocate approximately 20% more time for gateway upgrades. For large environments (for example, 1,000+ gateways), plan for 90–120 minutes of upgrade time. Schedule upgrades during maintenance windows to accommodate the longer duration. |
| AVX-63334 | Aviatrix Edge Gateways deployed on Equinix Network Edge and certain VMware environments may experience issues with root disk resizing during initial setup. The root filesystem might not expand to utilize the full allocated disk space. This can prevent essential cloud-init modules from executing properly. Affected Versions: Aviatrix Controller 7.1.4191 with Edge Gateway image avx-gateway-avx-g3-202407091338. All Edge deployments on Equinix Network Edge and specific VMware configurations. Workaround: Customers running Aviatrix Edge Gateways on Equinix Edge or VMware environments with version 7.1.4191 should contact Aviatrix Support for assistance. |
| AVX-63816 | In versions prior to 8.0.0, the Public Internet SmartGroup includes the RFC6598 Shared Address Space (100.64.0.0/10). Starting in version 8.0.0, this range is excluded from new installations to improve Layer 7 (L7) traffic inspection and policy enforcement. However, during upgrades to 8.0.0, the existing configuration is retained, and the 100.64.0.0/10 range is not automatically removed. Impact: Traffic from 100.64.0.0/10 (commonly used by Kubernetes) may bypass L7 inspection. Firewall traffic statistics may be incomplete. Distributed Cloud Firewall (DCF) policy enforcement may not behave as expected. Workaround: Clone the existing Public Internet SmartGroup. Remove 100.64.0.0/10 from the cloned group. Update your policies to use the custom SmartGroup. Recommendation: After upgrading to version 8.0.0, review your SmartGroup configuration if your deployment uses the 100.64.0.0/10 range in DCF rules. |
| AVX-63846 | In the CoPilot UI, Groups > SmartGroups and Groups > ExternalGroups with multiple filters may not appear as originally configured after being saved. This issue occurs when creating groups with multiple sets of any resource type. While policy enforcement is correct, the UI may display missing or merged filter sets, leading to ambiguity and confusion during review or editing. Affected Scenario: Creating or editing SmartGroups or ExternalGroups with multiple filters applied. Workaround: There is no workaround at this time. If possible, avoid using multiple filter sets in a single group until the issue is resolved. |
| AVX-63883 | In Aviatrix Controller version 8.0.0, you may encounter a problem when creating or modifying Distributed Cloud Firewall (DCF) rules using either the CoPilot UI or Terraform. In the CoPilot UI, the ruleset may not display correctly and the “Commit” button may be non-functional. When using Terraform, an error may occur indicating that the DCF policy API is unavailable. This issue prevents you from applying new or updated DCF rules, impacting network security policy management. Affected Scenario: Creating or modifying DCF rules using the CoPilot UI or Terraform. DCF-enabled environments where no rules are currently visible or editable. Workaround: Contact Aviatrix Support. They can run a script to restore the missing policy list without requiring a full upgrade. |
| AVX-64015 | Jumbo Frame support cannot be enabled on BGPoLAN (BGP over LAN) connections for AWS HPE gateways. Attempts to enable this feature may result in an error indicating that Jumbo Frames are not supported. This affects environments where high-throughput performance is critical, such as large-scale or latency-sensitive deployments. Affected Scenario: BGPoLAN connections on AWS HPE gateways. Use cases that rely on Jumbo Frame support for performance optimization. Limitation: In version 8.0.0, Jumbo Frame support can only be enabled when creating a new BGPoLAN connection on AWS HPE gateways. Editing an existing connection to enable Jumbo Frames is not supported. Workaround: None. To enable Jumbo Frame support, delete the existing connection and recreate it with the setting enabled. |
| AVX-64136 | In OCI environments, new CIDRs added to a VCN via the OCI console may not be reflected in the Controller after the initial spoke-transit attachment. As a result, users cannot create gateways in the newly added CIDRs, and the CIDR will not appear in the subnet selection dropdown. Impact: Controller fails to recognize new OCI CIDRs. Gateway creation fails in new CIDR ranges. Manual intervention required to refresh CIDR information. Workaround: Add both the original and newly added CIDRs to the Customized Spoke Advertised VPC CIDRs field in the Controller. |
| AVX-64196 | IPSec diagnostics in the Controller UI do not display logs for non-Equinix Edge Gateways (such as AEP or self-managed Edge Gateways). When accessing the diagnostics page for these gateways, the IPSec log section may appear empty, even if IPSec tunnels are operating correctly. This issue affects visibility into tunnel-level logs and may complicate troubleshooting efforts. Affected Scenario: Viewing IPSec diagnostic logs in the Controller UI for AEP or self-managed Edge Gateways. IPSec tunnels are active, but logs are not shown. Workaround: Use tunnel status and statistics to verify IPSec operation. Note: This is a UI diagnostic issue only. IPSec tunnel functionality is not impacted. |
| AVX-64213 | When deploying Edge Gateways using images g3-202504251522 and g3-202504251525, the root disk may be incorrectly sized after the VM boots and the ZTP (Zero Touch Provisioning) process runs. Even if the VM is created with a 64GB disk, the root filesystem may be limited to only 12GB. This may lead to insufficient storage for certain workloads or during upgrades. Affected Scenario: Edge Gateway deployments using image versions g3-202504251522 or g3-202504251525. Environments requiring full disk capacity for normal operations or upgrades. Workaround: Manual resizing of the root partition and filesystem is required. Please contact Aviatrix Support for assistance, as this step cannot be performed independently. |
| AVX-64339 | AWS t3.small and t3.medium instances used for Egress Spoke Gateways have limited connection tracking capacity, which can affect performance in high-connection environments. Impact: t3.medium supports around 25,000 concurrent connections. IDS-enabled DCF rules can reduce this to about 2,000. When limits are exceeded, traffic may drop and SSH access to the gateway may fail. Workaround: Use larger instance types such as c5.xlarge or c6in.large for applications requiring high concurrent connections. Avoid or remove IDS-enabled DCF rules if high connection capacity is needed. Monitor conntrack usage using platform tools or gateway diagnostics. Resolution: This is a documented platform limitation. No product fix is required. Refer to Aviatrix Best Practices for gateway sizing guidance. |
| AVX-64483 | Creating a Secondary or HA Transit/Spoke Edge Gateway on a Dell appliance currently fails due to a backend issue. Workaround: Aviatrix is actively working on a fix for this issue, which is expected to be included in a future release. In the meantime, if you need to create a Secondary or HA Transit/Spoke Edge Gateway on a Dell appliance, please contact Aviatrix Support for assistance. |
| AVX-64502 | On Azure gateways with High Performance Encryption (HPE) enabled, an underlay network issue may cause the eth0 interface to drop, bringing the interface flap. When this occurs, the DHCP-assigned primary IP address may be released while the static IP remains, resulting in one of the static IPs being promoted as the primary address. This can impact gateway operations. Impact: The gateway and its associated tunnels may go down, resulting in traffic disruption. Workaround: Stop and start the affected gateway from the cloud service provider console. |
| AVX-64767 | Customers using the Site-to-Cloud (S2C) mapped NAT feature at scale may encounter a performance regression and higher than normal packet drops after upgrading their gateways to version 7.1.4208, 7.2.5090 or 8.0.0. Contact Aviatrix Support before proceeding with the upgrade. |
| AVX-64794 | When Distributed Cloud Firewall (DCF) is enabled, policy-based Site-to-Cloud (S2C) traffic may be misclassified due to how the traffic flows through the gateway. This can lead to unintended blocking or incorrect policy enforcement. Impact: Policy-based S2C traffic may be incorrectly evaluated against VPC or internet DCF rules. Unexpected traffic drops or policy mismatches. Inconsistent DCF behavior between policy-based and route-based S2C configurations. Workaround: Consider using route-based S2C VPNs, where plaintext traffic traverses a dedicated tunnel interface and is classified correctly by DCF. Temporarily disable DCF on gateways handling policy-based S2C connections if misclassification impacts production traffic. |
| AVX-64868 | 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. Impact: Controller UI may show incorrect VRRP status such as both peers reporting Primary or Initializing. No impact on actual VRRP traffic handling or failover behavior. Workaround: Use diagnostic logs to verify actual VRRP state. |
| AVX-65252 | The current API allows creating a WebGroup that includes both Domains and URLs entries. This mixed configuration is not supported and causes the configuration push to fail in a way that may not be immediately obvious. As a result, updates may stop applying correctly. Affected Scenario: Creating WebGroups that include both Domain and URL filters in the same group. Workaround: Do not create WebGroups that combine both Domain and URL filters. Separate them into distinct WebGroups. Recommendations: Review existing smart groups to ensure Domain and URL filters are not mixed. |
| AVX-65386 | A known issue prevents successful upgrades to Controller version 8.0.0 if the configuration contains Distributed Cloud Firewall (DCF) policies with duplicate names. Affected Scenario: Upgrading from Aviatrix Controller version 7.2.5090 to 8.0.0 with duplicate DCF policy names. Environments using Distributed Cloud Firewall (DCF) policies. Workaround: Before upgrading to version 8.0.0: Check your DCF policies for duplicate names. Ensure all policy names are unique. Rename any duplicates before starting the upgrade. Recommendations: Always perform a dry-run upgrade if possible. Back up your Controller configuration before upgrading. Review DCF policy names for uniqueness as part of your pre-upgrade checklist. Contact Aviatrix Support if you encounter this issue. |
| AVX-66190 | When using Threat Intelligence (ThreatIQ) external groups in Distributed Cloud Firewall (DCF), gateways may log field threat_severity not found errors if unsupported selectors (such as threat_severity) are used. These configurations are currently accepted by the Controller without validation, but the unsupported selectors are ignored during policy enforcement, and repeated error messages are logged. Impact: DCF policies continue to function as expected, but administrators may be unaware that some threat selectors are not being applied. The repeated log entries may also affect log analysis and monitoring. Workaround: Remove unsupported selectors (e.g., threat_severity) from threat group configurations. Use only supported fields when defining ThreatIQ external groups. Monitor DCF gateway logs for error messages to identify invalid selectors. Resolution: Future enhancements will add validation during configuration and UI notifications when unsupported selectors are used. |
| AVX-66324 | 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. Affected Scenario: DCF Layer 7 rules configured between Smart Groups based on resource tags (for example, Kubernetes pods and VMs). Both VPCs use RFC1918 IP addresses. Gateways are deployed in High Availability (HA) mode. Impact: Only affects notifications. Traffic enforcement continues to function as expected. Workaround: Monitor traffic flow manually. Use Smart Groups with static IPs or CIDRs if alerting is critical. |
| AVX-66630 | Uploading SSL certificates from some providers (such as GoDaddy) could fail if the PEM file included a Unicode Byte Order Mark (BOM). The certificate might appear to upload successfully but would not take effect, and could cause the Controller’s application server to crash with a “missing private key” error. Impact: SSL certificate installation may silently fail. In some cases, the Controller application server could crash. Affects wildcard and other SSL certificates from providers like GoDaddy. Workaround: Open the certificate file in a text editor that supports encoding and remove the BOM before uploading. Use certificates saved in standard UTF-8 format without BOM. |
| AVX-68726 | On Azure Controllers with Controller Security Group Management enabled, gateway deployments may fail when multiple gateways or HA gateways are created. 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. Impact: Gateway deployments may fail in Azure. Security group rules may not be updated correctly. Controller Security Group Management may be disabled unexpectedly. Workaround: Disable Controller Security Group Management and manage Azure network security group rules manually, or contact Aviatrix Support for assistance. |
| AVX-70123 | When upgrading from Controller 8.0.x to 8.1.x, the upgrade may fail to complete due to incorrect database schema type definitions. As a result, the controller remains on version 8.0.x and the upgrade process does not finish successfully. Impact: Controller upgrade from 8.0.x to 8.1.x fails. Workaround: Contact Aviatrix Support for a manual fix to complete the upgrade. |
| AVX-70253 | FireNet deployment with bootstrap enabled may fail in Google Cloud due to changes in how GCP credentials are handled. 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. Impact: FireNet deployment with bootstrap fails in the Google Cloud environment. Affected Scenario: FireNet deployments with bootstrap enabled in Google Cloud. Workaround: Do not use bootstrap when deploying FireNet in Google Cloud. Alternatively, perform the bootstrap process directly from the GCP cloud. |
| AVX-71087 | When upgrading to Controller versions 8.0 or 8.1 |
