IDFW Rule Does Not Allow Traffic on Destination VM

Products

• VMware vDefend Firewall
• VMware vDefend Firewall with Advanced Threat Prevention

Issue/Introduction

An IDFW rule was created to allow traffic between two VMs. The DFW packet logs show the IDFW rule correctly allowed traffic from the source VM. However, at the destination VM, the same packet did not match the IDFW rule and instead hit a different rule, resulting in the traffic being dropped.

 

This issue can be identified from /var/run/log/dfwpktlogs.log on the source and destination ESXi hosts:

*In this example, the IDFW rule ID is 1234 and the default drop rule is 2.

 

The packet matches the IDFW rule at the source VM in the OUT direction:

2025-09-12T15:15:50.026Z No(13) FIREWALL-PKTLOG[2102532]: 2fbd#### INET match PASS 1234 OUT 52 TCP 172.16.xx.xx/52144->172.16.xx.xx/52490 S S-1-5-21-######-######-#####

 

The same packet then hits the default drop rule at the destination VM in the IN direction:

2025-09-12T15:15:50.026Z No(13) FIREWALL-PKTLOG[2102532]: 73e9#### INET match DROP 2 IN 52 TCP 172.16.xx.xx/52144->172.16.xx.xx/52490 S


Environment

VMware NSX - All Versions

Cause

• This is expected behavior.
• Per NSX IDFW documentation

“IDFW processes the user identity at the source only in firewall rules. Only traffic originating at the source where the user identity is processed will be subject to IDFW rules.”

• Because IDFW applies only at the source, the destination VM does not process identity-based rules for incoming traffic.

Resolution

Create a separate non-IDFW rule to allow the traffic at the destination VM.

• You can specify the IN direction on this rule.

• Alternatively, scope the rule (using the Applied To field) only to the destination VM so that it applies only there.

This ensures the return traffic is still governed by the IDFW rule at the source, while the destination side has a standard rule to allow the session.