DFW status mismatch between NSX Manager and ESXi hosts in Federation

Products

• VMware vDefend Firewall

Issue/Introduction

In a Federation environment, disabling the Distributed Firewall (DFW) service from the Global Manager (GM) is expected to propagate the disabled state across all ESXi hosts within all associated Local Manager (LM) sites.

However, in certain scenarios, an inconsistency may be observed wherein ESXi hosts in one or more LM sites continue to report the DFW status as enabled, even though the configuration is shown as disabled in both the Global Manager and Local Manager user interfaces.

Symptoms

• Disabling the DFW service from the Global Manager UI, may not be reflected on some Local Manager sites.
  (Security → Distributed Firewall → Settings → General Firewall Settings)

         

• On affected Local Manager sites:
  • The NSX UI shows DFW status as disabled.
  • ESXi hosts continue to report DFW as enabled.

• Running the following command on the ESXi host, shows that the Distributed Firewall is still enabled.
  " nsxcli -c get firewall status "

       

• This indicates a mismatch between the NSX Manager configuration and the actual host state.
• DFW rules configured at the Global Manager level are successfully propagated to Local Managers and ESXi hosts, confirming that policy synchronization is functioning as expected.
• Log observations: Enable/disable operations generate successful log entries in:
  • • nsx-audit-write.log
    • nsxapi.log
• Corfu dump analysis: InternalDfwFirewallConfiguration table contains multiple entries for DFW configuration, indicating inconsistency.
• Following nsxapi.log warning also mentions the same

./nsx_manager/var/log/proton/nsxapi.1.log.gz:2025-10->29T20:25:00.179Z  WARN providerTaskExecutor-1-104 DfwFirewallConfigurationUtils 77545 POLICY [nsx@6876 comp="nsx->manager" level="WARNING" subcomp="manager"] Found no or more than one records in internal table >'InternalDfwFirewallConfiguration', expected exactly one. Proceed to fetch from policy intent

Environment

Deployment Type : Federation
NSX Version : 4.2.3.3 or earlier version
VMware vDefend Firewall

Cause

The issue is caused by a stale or orphaned record in one of the Corfu database tables. This inconsistency is typically introduced during upgrades from earlier NSX versions.

Resolution

A permanent fix for this issue will be available in NSX 4.2.4 / 9.1.0 or later releases. 

Workaround:

The issue can be addressed by deleting the stale records. Please open a case with Broadcom Support vDefend firewall team to implement the workaround.

PR 3610675