Missing NSX DFW Flows in VCF Operations for Networks for Load Balancer Virtual IPs (VIPs)

Products

• VCF Operations for Networks

Issue/Introduction

• Network flows originating from an intermediate Load Balancer Virtual IP (VIP), such as F5 or AVI, are not visible in the VCF Operations for Networks UI.

• You may observe that a different or fallback Firewall Rule ID is occasionally displayed instead of the expected rule (toggling behavior).

• Packet captures (nfcapd) on the  VCF Operations for Networks collector confirm that raw IPFIX telemetry for the expected rule is successfully arriving from the source ESXi host, but the flows are not populated in the  VCF Operations for Networks platform.

 

Environment

VCF Operations for Networks 

VMware NSX

Cause

This behavior is working as designed. It is caused by the VCF Operations for Networks flow processor's strict IP spoofing validation engine (IpfixRawFlowValidator.dropIfWrongReportingPoint4()).

• Strict VIF Mapping: For the platform to accept a flow, the reported IP address must strictly match the registered Virtual Interface (VIF) or vNIC mapped in NSX.

• Guest OS VIP Limitation: Floating VIPs used by Load Balancers are intermediate virtual constructs configured inside the guest operating system. They do not have a dedicated, real vNIC ID exposed to the hypervisor. NSX only registers the physical vNIC IPs of the pool members.

• Validation Failure: Because the source VIP cannot be explicitly matched to a physical VIF in NSX, the  VCF Operations for Networks validation engine drops the flow originating from the source host to prevent potential IP spoofing (WRONG_REPORTING_POINT).

Resolution

To resolve this issue and make the flows visible, you must modify the NSX Distributed Firewall (DFW) policy configuration so that the flow is validated against the destination host's VIF.

• Update the NSX DFW policy scope (Applied To field) for the affected rule to ensure it is enforced and reported by the destination ESXi host rather than the source.

• By applying the rule to the destination, the flow is reported by the destination host. Because the destination VM owns the destination IP and has a valid VIF-to-IP mapping, the telemetry will successfully pass the strict validation checks and populate in the UI.