Gateway Firewall disablement shows mismatch in NSX Manager UI and Edge CLI when NAT is enabled

Products

• VMware vDefend Firewall

Issue/Introduction

In NSX-T environments, disabling the Gateway Firewall (GFW) on a Tier-1/0 gateway through the NSX Manager UI or API may lead to a mismatch when checking the status via the Edge CLI.

• UI/API: Reflects the GFW as disabled.

• CLI (get firewall sync config): Continues to display Firewall enabled: true.

This can cause confusion as the expectation is that the CLI output should align with the UI/API status.

Environment

VMware NSX

vDefend Firewall

Cause

The CLI flag Firewall enabled is not dependent only on the Gateway Firewall status.

It is a shared indicator across multiple datapath features, including:

• Gateway Firewall (stateless or stateful)

• NAT

• Load Balancer (LB) Firewall

If any of these features are enabled or have rules configured, the NSX-CLI reports Firewall enabled: true.

Examples:

• If GFW is disabled but NAT is enabled, CLI will still display Firewall enabled: true.

• If both GFW and NAT are disabled, CLI reflects Firewall enabled: false.

• Re-enabling NAT (with GFW still disabled) causes the CLI to again display Firewall enabled: true.

This behavior is by design and does not indicate that GFW is still active in the datapath. No change to the NSX-CLI is required.

Resolution

The Gateway Firewall disables correctly when configured via the UI or API.

Datapath validation confirms this behavior:

• No traffic inspection occurs when GFW is disabled.

• No logs are written to /var/log/firewallpkt.log.

• New firewall rules are not realized on the Edge Node.

The mismatch is limited to the CLI output due to the shared flag design.

Workarounds / Validation Steps:

1. Use datapath checks (traffic inspection, logs, rule realization) to validate whether GFW is disabled.

2. Do not rely solely on the CLI get firewall sync config command when NAT is enabled.