A FIN or RST packet logged against a lower NSX Distributed Firewall rule does not necessarily mean the connection's original allow rule failed. In the stateful TCP case documented by Broadcom KB 343357, the connection may already have left the flow table. Its late non-SYN packet is then evaluated differently from the SYN that created the original flow.
This article covers that specific NSX 3.x/4.x behaviour. No firewall, flow table or logging configuration was changed, and no packets were generated. The example is synthetic.
The rule match and the flow have different lifetimes
The distributed firewall enforces rules for the VM, but stateful processing also records connection state. The KB describes a flow entry created when an initial TCP SYN matches a rule containing TCP services. Subsequent packets such as ACK, RST and FIN/ACK are handled using the flow entry.
When that flow is removed, for example after connection termination or timer expiry, a late packet may have no matching state. In the documented case, the non-SYN packet does not match the expected TCP-service rule as a new connection. It can continue to a lower rule whose service is Any, because that rule can match TCP packets with other flag combinations.
The critical distinction is therefore not just source, destination and port. It is the packet's flags, time and relationship to a still-existing flow. Two log lines with the same endpoint tuple can belong to different stages of the connection lifecycle.
This explanation is scoped to stateful rules. The source explicitly says stateless rules do not create flow-table entries. It is also not evidence that every default-rule hit is normal or that arbitrary firewall policy changes preserve established sessions.
Inspect a complete sequence
Prerequisites are the NSX version, affected VM and host identity, relevant rule definitions and already available packet/flow evidence from the incident. Use approved read access. If diagnostic logging was not enabled at the time, record the gap rather than enabling extensive collection or reproducing traffic as an unreviewed step.
Build one timeline with the initial SYN, the rule that admitted it, evidence of the established flow where available, the end or expiry of that flow, and the disputed packet. Record direction as well as both endpoint addresses and ports. Compare full tuples; a reused client port or a similar server connection can make a superficial match misleading.
Inspect the lower rule's service definition. If it is Any, it matches the particular explanation in KB 343357. A different service or a packet arriving while the flow is demonstrably active needs additional investigation. Do not convert a partial resemblance into a confirmed cause.
The KB names summarize-dvfilter (with grep -A20 filtering) to identify the VM’s DFW filter, then vsipioctl getflows -f to read active flows on its ESXi host. The captured text omits the selection arguments, so these are command names for locating the documented method, not complete executable examples. Confirm the actual VM/filter and installed release through the approved collection procedure.
For the matching late-packet case, KB 343357 calls this “normal behavior” that “doesn’t impact active connections”. That conclusion is limited to its documented stateful-flow sequence; a failed initial SYN or an active application timeout still requires its own evidence.
Worked interpretation
Suppose an existing trace shows a fictional client establishing TCP to a VM on port 8443. Its SYN matches rule 120. Later, the flow ends and is no longer in the retained flow evidence. A delayed FIN/ACK for the same tuple is logged against rule 900, whose service is Any.
That sequence is consistent with the vendor's late-packet explanation. Reordering rule 120 or adding a second allow rule would not recreate the completed flow. Nor does the late FIN/ACK establish that the application transaction failed. Preserve the application's own completion evidence separately.
Now change the example: the initial SYN itself hits rule 900 and the connection never establishes. That is not the same case. Inspect effective rule scope, service matching and other connection-path evidence. Similarly, repeated drops during a proven active flow are not dismissed merely because the source mentions harmless late packets.
Decide whether a rule change is justified
If the only unexpected evidence is late teardown traffic after the flow disappeared, document the lifecycle interpretation and avoid changing enforcement just to make every packet share one rule identifier. If the application genuinely fails, identify the failed exchange and its active-flow state before attributing it to the firewall rule.
A state flush, a stateless replacement rule or a broad Any-service allowance changes behaviour. None is a read-only diagnostic, and none follows from this article. Existing normal behaviour should not be weakened to make a log presentation look simpler.
Acceptance and reversal
The inspection is complete when the packet flags, tuple, rule definitions and sequence either support the documented expired-flow case or expose a specific missing fact. Absence of a flow in a later snapshot alone does not prove when it expired; retain that uncertainty if historical state was not captured.
No configuration rollback is needed for reading existing evidence. Any future policy change requires its own recorded previous rule, traffic-impact review and qualified validation. No enforcement change or application acceptance test was performed here.
Learning notes
- Matching endpoints do not establish matching connection state.
- A late teardown packet can reach a lower Any-service rule after flow removal.
- Diagnose the failed application exchange before changing a firewall rule.