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

# Controller Release Notes 7.2.5012

> Release Date: 23 January 2025

Release Date: 23 January 2025

Release Notes Last Updated: 5 October 2026

## Corrected Issues in Aviatrix Release 7.2.5012

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

  <tbody>
    <tr><td>AVX-59843</td><td>If you have BGP sessions over IPsec and the BGP peer IPs are non-APIPA (169.254.x.x) IP addresses, the sessions might not be able to be established or reestablished after experiencing tunnel flapping. The BGP peer subnet route is installed by the kernel and this route is synced to a special route table which is used by BGP to send BGP packets to a peer. There is a failure to sync this route, therefore BGP packets can not reach remote BGP peer.</td></tr>
  </tbody>
</table>

## Known Issues in Aviatrix Release 7.2.5012

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

  <tbody>
    <tr><td>AVX-63016</td><td><br />In Aviatrix Controller, newly added **Additional CIDRs** in OpenVPN split tunnel mode are not pushed to OpenVPN clients. This occurs because the OpenVPN service does not automatically restart after CIDR updates.<br /><br />**Impact:**<br /><br />\_ Additional CIDRs configured in **OpenVPN > Edit Config > Modify Split Tunnel > Additional CIDRs** are not propagated to clients<br />\_ VPN clients do not receive updated routes<br />\* Administrators must restart the OpenVPN service manually on affected gateways<br /><br />**Workaround 1:**<br /><br />Stop and restart the gateway instance from the CSP console.<br /><br />**Workaround 2:**<br /><br />Request Support to restart the OVPN service on the gateway.<br /><br />**Note:**<br /><br />Both workarounds are traffic-impacting and must be performed during a scheduled maintenance window.<br /><br />**Resolution:**<br /><br />Fixed in versions 8.0.10 and 8.1.0. The OpenVPN service now automatically restarts when Additional CIDRs are updated, ensuring routes are pushed to clients.</td></tr>
    <tr><td>AVX-64136</td><td>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.<br /><br />**Workaround:**<br /><br />\_ Add both the original and newly added CIDRs to the **Customized Spoke Advertised VPC CIDRs** field in the Controller.<br /><br />**Impact:**<ul><li>\_ Controller fails to recognize new OCI CIDRs</li><li>\_ Gateway creation fails in new CIDR ranges</li><li>\_ Manual intervention required to refresh CIDR information</li></ul></td></tr>
    <tr><td>AVX-64447</td><td><br />Site2Cloud High Availability (HA) tunnels may not behave correctly when toggling between Active/Active and Active/Standby modes.<br /><br />**Problem 1:**<br /><br />When disabling Active/Active HA, the HA Gateway (HAGW) may retain metric 100 routes pointing to tunnel interfaces in the Gateway Route table, even though they should be removed.<br /><br />**Problem 2:**<br /><br />When enabling Active/Active HA from Active/Standby, the HA Gateway tunnel may not be properly enabled. This can result in missing routes despite the UI showing Active/Active status.<br /><br />**Impact:**<ul><li>\_ Inconsistent route table management during HA mode transitions</li><li>\_ Potential routing gaps or misconfigurations</li><li>\* Affects both Terraform and UI-based deployments</li></ul>**Workaround:**<br /><br />If you encounter this issue, contact [Aviatrix Support](https://support.aviatrix.com) for assistance.</td></tr>
    <tr><td>AVX-64741</td><td><br />After an image upgrade on a Transit Gateway that is attached to an edge gateway, while the transit peering connections may establish successfully, the status may not reach the controller due to an IP address parsing exception. This may impact route propagation.<br /><br />**Symptoms:**<ul><li>Transit peering status displays as **UNKNOWN** in the controller</li><li>S2C tunnel status displays **UNKNOWN** in the controller</li><li>Route exchange between impacted tunnels is blocked</li><li>Peering appears established at the gateway level but not reflected in controller status</li></ul><br /><br /><br /><br /><br /><br />**Impact:**<ul><li>Impacts route propagation between peered transit gateways or S2C</li><li>Network connectivity issues between peered networks</li><li>Inaccurate status reporting in controller</li></ul><br /><br /><br /><br />**Workaround:**<br /><br />Contact Aviatrix Support if you need to perform an image upgrade of a Transit Gateway (attached to an edge gateway) to software version 7.2.5090.<br /><br />**Resolution Status:**<br /><br />Fixed in version 8.0.10 and 8.1.</td></tr>
    <tr><td>AVX-64868</td><td>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.<br /><br />**Workaround:**<br /><br />\_ Use diagnostic logs to verify actual VRRP state<br /><br />**Impact:**<ul><li>\_ Controller UI may show incorrect VRRP status such as both peers reporting `Primary` or `Initializing`</li><li>\* No impact on actual VRRP traffic handling or failover behavior.</li></ul></td></tr>
    <tr><td>AVX-65016</td><td><br />In some environments, the Firewall state may not recover from **Unaccessible** after the first vendor integration failure. This issue has been observed when integrating with third-party firewall vendors, leaving the gateway firewall state stuck even after the environment stabilizes.<br /><br />**Impact:**<br /><br />\_ Firewall integration appears stuck in **Unaccessible** state<br />\_ Recovery does not occur automatically after initial failure<br />\* May require manual intervention to restore proper firewall state reporting<br /><br />**Workaround:**<br /><br />Contact Aviatrix Support for manual correction.</td></tr>
    <tr><td>AVX-65213</td><td>In earlier versions, system diagnostics could fail with an AttributeError (`'NoneType' object has no attribute 'role'`) during migration or health check operations. The issue occurred when CloudXD process data returned None during the system info collection.<br /><br />**Workaround:**<ul><li>\_ Retry the diagnostic operation</li><li>\_ Restart the Controller if needed</li></ul>**Impact:**<ul><li>\_ Diagnostic collection may fail or produce incomplete results</li><li>\_ Affects troubleshooting and migration reliability</li><li>\* May block support visibility during critical operations</li></ul>**Resolution:**<br /><br />Fixed in 8.0.10 and 8.1.0. Diagnostic logic now handles null values safely.</td></tr>
    <tr><td>AVX-71135</td><td>When upgrading to Controller 8.1, the database migration may fail if VPC tunnel records contain string values in the **timestamp** field instead of numeric values.<br /><br />During migration, the process attempts to convert these non-numeric timestamp strings to floating-point values, which results in a conversion error and causes the upgrade to fail.<br /><br />**Impact:**<br /><br />The upgrade to Controller 8.1 cannot complete and the system remains on the previous version.<br /><br />**Workaround:**<br /><br />Contact [Aviatrix Support](https://support.aviatrix.com/) for assistance.</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.