> ## 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.

# 7.2.5090 Release Notes

> Release Date: 19 May 2025

Release Date: 19 May 2025

Release Notes Last Updated: 5 October 2026

## Corrected Issues in Aviatrix Release 7.2.5090

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

  <tbody>
    <tr><td>AVX-61310</td><td>In an Aviatrix multi-transit design with Transit Peering, where one of the Transit Gateways has BGP S2C enabled and learns a default route (0.0.0.0/0), an issue occurs following a controller upgrade where incorrect metrics are applied to PeerS2c routes.</td></tr>
    <tr><td>AVX-61702</td><td>Resolved an issue where Azure gateway image upgrades failed when customer-provided public IPs were used. The Controller was expecting a specific naming convention (av-ip-\[gateway-name]) and could not locate custom-named IPs, resulting in upgrade errors. The upgrade logic has been fixed to support any naming convention for public IPs.</td></tr>
    <tr><td>AVX-61803</td><td>Fixed an issue where the Controller did not correctly tag resources created through CFT and Lambda. It now tags all associated resources, including Lambda functions, Lambda roles, Launch Templates, Auto Scaling Groups, and SNS topics.</td></tr>
    <tr><td>AVX-61981</td><td>When using RFC6598 Shared Address Space (100.64.0.0/10) in VPC/VNet CIDRs, traffic from these addresses to the public internet may have been incorrectly matched by the Public Internet security group. This could result in 100.64.0.0/10 being mistakenly classified as internet traffic. The 100.64.0.0/10 is commonly used for Kubernetes deployments. The Public Internet security group CIDR ranges have been updated to correctly exclude the shared address space. This enhancement improves the Kubernetes experience.</td></tr>
    <tr><td>AVX-62067</td><td>The following issue has been fixed in this release.<br /><br />**Note:**<br /><br />This fix also requires an image upgrade of the Transit gateway. Aviatrix Transit Gateways with large number of tunnels and running for a long time could encounter an issue where in the IPSec process becomes unresponsive leading to all IPsec tunnels going into a DOWN state. The cause of this is an internal counter reaching its maximum value and overflowing. To recover, the transit gateway needs to be rebooted. While it is not possible to specify the exact number of tunnels and length of time it would take for the internal counter to overflow, the few customers who encountered this issue had greater than 800 ipsec tunnels on the transit gateway and took three to four months to encounter this issue. The number of ipsec tunnels on the gateway can be seen from Copilot UI under **Diagnostics > Cloud Routes > Gateway Routes**.</td></tr>
    <tr><td>AVX-62269</td><td>Fixed an issue where GRPC traffic could be dropped when routed through Distributed Cloud Firewall (DCF) web filters using SNI-based web groups. The fix improves support for HTTP/2-based traffic in scenarios where only H2 is present in the ALPN list, resolving a limitation in the Traffic Server tunneling logic.</td></tr>
    <tr><td>AVX-62619</td><td>Fixed an issue where Aviatrix Gateways could experience memory buildup and restarts during prolonged Layer 7 (L7) traffic. The system now properly clears outdated web filter data to prevent excessive memory usage.</td></tr>
  </tbody>
</table>

## Known Issues in Aviatrix Release 7.2.5090

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

  <tbody>
    <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. - 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.</li></ul></td></tr>
    <tr><td>AVX-62712</td><td>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.<br /><br />**Affected Scenario:**<ul><li>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.</li></ul>**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com) to manually clear the cached CIDR information.</td></tr>
    <tr><td>AVX-63334</td><td>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 the full allocated disk space. This can prevent essential cloud-init modules from executing properly.<br /><br />**Affected Versions:**<ul><li>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</li></ul>**Workaround:**<br /><br />Customers running Aviatrix Edge Gateways on Equinix Edge or VMware environments with version 7.1.4191 should contact Aviatrix Support for assistance.</td></tr>
    <tr><td>AVX-63846</td><td>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.<br /><br />**Affected Scenario:**<ul><li>Creating or editing SmartGroups or ExternalGroups with multiple filters applied</li></ul>**Workaround:**<br /><br />There is no workaround at this time. If possible, avoid using multiple filter sets in a single group until the issue is resolved.</td></tr>
    <tr><td>AVX-64015</td><td>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.<br /><br />**Affected Scenario:**<ul><li>BGPoLAN connections on AWS HPE gateways - Use cases that rely on Jumbo Frame support for performance optimization</li></ul>**Limitation:**<br /><br />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.<br /><br />**Workaround:**<br /><br />None. To enable Jumbo Frame support, delete the existing connection and recreate it with the setting enabled.</td></tr>
    <tr><td>AVX-64196</td><td>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.<br /><br />**Affected Scenario:**<ul><li>Viewing IPSec diagnostic logs in the Controller UI for AEP or self-managed Edge Gateways - IPSec tunnels are active, but logs are not shown</li></ul>**Workaround:**<br /><br />Use tunnel status and statistics to verify IPSec operation.<br /><br />**Note:**<br /><br />This is a UI diagnostic issue only. IPSec tunnel functionality is not impacted.</td></tr>
    <tr><td>AVX-64213</td><td>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.<br /><br />**Affected Scenario:**<ul><li>Edge Gateway deployments using image versions `g3-202504251522` or `g3-202504251525` - Environments requiring full disk capacity for normal operations or upgrades</li></ul>**Workaround:**<br /><br />Manual resizing of the root partition and filesystem is required. Contact [Aviatrix Support](https://support.aviatrix.com) for assistance, as this step cannot be performed independently.</td></tr>
    <tr><td>AVX-64397</td><td>Auto-migration between Aviatrix Controller builds within version 7.2.5090 fails on both AWS and Azure platforms. During the migration process, the new Controller is unable to connect to the old Controller, and the operation times out. As a result, the migration does not complete successfully. This issue is specific to Controller-to-Controller migrations within the same 7.2.5090 release family and does not affect upgrades to newer versions.<br /><br />**Affected Scenario:**<ul><li>Auto-migration from one 7.2.5090 Controller build to another - Aviatrix Controllers deployed on AWS or Azure</li></ul>**Workaround:**<br /><br />Use manual backup and restore instead of auto-migration: - Launch a new Controller with the target 7.2.5090 build. - Create a backup from the existing Controller. - Restore the backup on the new Controller. - Transition operations to the new Controller.<br /><br />**Note:**<br /><br />This issue does not impact migrations from version 7.2.5090 to version 8.0 or later. Aviatrix encourages you to upgrade directly to version 8.0 or newer, where auto-migration works as expected.</td></tr>
    <tr><td>AVX-64767</td><td>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](https://support.aviatrix.com) before proceeding with the upgrade.<br /><br />**Workaround:**<br /><br />None.</td></tr>
    <tr><td>AVX-65554</td><td>DNAT (Destination NAT) configuration updates may fail on gateways that have policy-based Site2Cloud tunnels. When attempting to add, modify, or delete DNAT rules in the Controller UI, the operation can fail with an error.<br /><br />**Impact:**<ul><li>DNAT configuration updates cannot be performed through the Controller UI - May block the ability to update NAT rules on production gateways - Manual intervention is required to apply urgent changes</li></ul>**Workaround:**<br /><br />No direct workaround is available. Customers can contact [Aviatrix Support](https://support.aviatrix.com) for assistance with manual configuration updates.</td></tr>
    <tr><td>AVX-66162</td><td>DNAT and SNAT (Destination/Source NAT) configuration updates may fail on gateways that have policy-based Site2Cloud tunnels. When attempting to add, modify, or delete DNAT and SNAT rules in the Controller UI, the operation can fail with an error.<br /><br />**Impact:**<br /><br />\_ DNAT and SNAT configuration updates cannot be performed through the Controller UI \_ May block the ability to update NAT rules on production gateways \* Manual intervention is required to apply urgent changes<br /><br />**Workaround:**<br /><br />No direct workaround is available. Customers can contact [Aviatrix Support](https://support.aviatrix.com) for assistance with manual configuration updates.</td></tr>
    <tr><td>AVX-71122</td><td>In some environments, after the Identity Provider (IdP) rotates its SAML signing certificate, the Aviatrix Controller may fail to fetch and update the new certificate from the configured metadata URL. As a result, the Controller continues to use a stale certificate, which causes signature verification errors during SAML authentication.<br /><br />**Impact:**<ul><li>SAML single sign-on (SSO) authentication fails.</li><li>Users may experience repeated login failures or timeouts and are unable to access the Controller dashboard using SAML.</li></ul>**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) to manually update the SAML certificate on the Controller.</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.