8.1.11 Release Notes

Release Date: 08 October 2025

Corrected Issues in Aviatrix Release 8.1.11

None

Known Issues in Aviatrix Release 8.1.11

Issue Description

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-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-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-64447

Site2Cloud High Availability (HA) tunnels may not behave correctly when toggling between Active/Active and Active/Standby modes.

Problem 1: 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.

Problem 2: 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.

Impact:

  • Inconsistent routes on the gateway while switching the s2c HA Mode.

  • Potential routing gaps on the gateway lead to incorrect traffic distribution.

Workaround:

If you encounter this issue, contact Aviatrix Support for assistance.

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.

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

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

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.

Workaround:

  • Use diagnostic logs to verify actual VRRP state

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.

AVX-65016

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.

Impact:

  • Firewall integration appears stuck in Unaccessible state

  • Recovery does not occur automatically after initial failure

  • May require manual intervention to restore proper firewall state reporting

Workaround:

Contact Aviatrix Support for manual correction.

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.

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

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

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

Workaround:

  • Monitor traffic flow manually

  • Use Smart Groups with static IPs or CIDRs if alerting is critical

Impact: Only affects notifications. Traffic enforcement continues to function as expected.

AVX-66631

Transit gateways with large-scale tunnel deployments (1300+ tunnels) may experience extended traffic loss during image upgrades. Although the image upgrade completes successfully, traffic may remain down for several minutes afterward due to delayed tunnel reconfiguration.

Workaround:

  • Schedule maintenance windows to account for potential traffic loss beyond upgrade completion.

  • Consider staggering upgrades across transit gateways to reduce impact.

  • Monitor tunnel and route service status post-upgrade through the CoPilot UI.

Impact:

  • Traffic loss may persist after image upgrade completes

  • Route service startup is blocked until all tunnels are sequentially reconfigured

  • Configuration push may time out with Context cancelled during Phase 1 Create error

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-67530

When Distributed Cloud Firewall (DCF) rules are configured with external groups as sources or destinations, the traffic count displayed in the Security > Distributed Cloud Firewall > Policies page may be significantly lower than the actual traffic volume shown in the Security > Distributed Cloud Firewall > Monitor page.

Impact:

  • DCF UI traffic counters underreport hits for rules using external groups.

  • Discrepancy can occur for both deny and permit rules.

  • May affect deployments using selective spoke VPCs.

  • Analysis may be misleading if relying solely on DCF UI counters.

Workaround:

  • Use the Security > Distributed Cloud Firewall > Monitor page logs for accurate traffic counts

AVX-68108

When upgrading the Controller from version 8.0.30 to 8.1.10, the UI may display a misleading "Service temporarily unavailable" error message immediately after the upgrade begins. This message can persist for 5–10 minutes but does not indicate upgrade failure. The upgrade continues normally in the background and the Controller becomes accessible again once the upgrade finishes.

Impact:

  • Users may believe the upgrade has failed.

  • Error message persists for 5–10 minutes, especially in larger deployments (50+ gateways).

  • No effect on upgrade success or Controller functionality.

Workaround:

  • Ignore the message during upgrade.

  • Wait 10–15 minutes for the process to complete.

  • Refresh the browser and verify the new Controller version after reconnection.

AVX-68319

In some cases, the Controller UI may not display the kernel version for gateways, even though the correct version is present on the gateway itself. This typically affects environments with a large number of gateways (500+) that have gone through multiple upgrade cycles.

Impact:

  • Gateway functionality is not affected; the issue is limited to the UI display.

  • Administrators may see missing kernel version information in the Controller UI, which could cause confusion during troubleshooting or compliance checks.

Workaround:

  • Perform an image upgrade on the affected gateway to restore the proper kernel version display in the Controller UI.

AVX-68561

In large-scale deployments with 1300+ gateways, enabling Distributed Cloud Firewall Site-to-Cloud (DCF S2C) can cause gateway configurations to become out of sync with the Controller. Even after disabling DCF S2C, the issue may persist and lead to elevated Controller resource usage.

Impact:

  • Gateway configurations may show as out of sync in the Controller UI

  • Controller CPU utilization (conduit process) increases significantly

  • Performance degradation may occur during DCF S2C operations

  • Issue may persist after disabling DCF S2C

Workaround:

  • Monitor Controller CPU usage before enabling DCF S2C in large-scale environments.

  • Consider enabling DCF S2C during scheduled maintenance windows.

  • For deployments with 1300+ gateways, evaluate the necessity of DCF S2C functionality.

AVX-68606

During software upgrades of Edge gateways from 8.1 to 8.1.10, services may restart as part of the upgrade process, which can cause temporary traffic disruption.

Impact:

  • Temporary traffic loss during Edge gateway upgrades

  • Service disruption due to container restarts

  • More noticeable in large-scale deployments

Workaround:

  • None. Users should plan for possible disruption during upgrades.

Recommendations:

  • Schedule upgrades during maintenance windows

  • Notify stakeholders of expected downtime

  • Monitor gateway status during upgrades

AVX-68692

The Controller may fail to automatically restart gateways after a Controller power cycle or restart. This occurs because the auto-restart task scheduler does not resume properly after reboot, preventing the gateway auto-recovery function from working.

Impact:

  • Failed gateways are not automatically restarted after Controller restarts

  • Gateway availability and recovery rely on manual intervention

  • Increases recovery time and operational overhead in large-scale environments

Affected Configuration:

  • Multi-cloud environments (AWS and Azure)

  • Deployments with large numbers of spoke gateways (for example, more than 100 gateways)

  • Controller version 8.1.10

Workaround:

  • Monitor gateway status manually after Controller restarts

  • Restart failed gateways manually using one of the following:

    • Cloud provider console (AWS/Azure portal)

    • Controller GUI gateway management

    • Gateway restart API calls