Understanding DFW packet logging

Products

VMware vDefend Firewall

Issue/Introduction

DFW packet logging can be enabled on NSX for each DFW rule found under Security>Distributed Firewall. This article explains when and where dfwpktlog entries are created on ESXi hosts.

Environment

VMware NSX 4.x
vDefend Firewall
ESXi 8.x

Resolution

NSX DFW is a stateful firewall, by default, which means that it tracks the "state" of a connection, and is enforced at the vNIC level (the dvfilter). IN and OUT log entries are created on the ESXi hosts under /var/run/log/dfwpktlogs for those DFW rules whereby logging is enabled.

The default policy settings for its rules are Stateful and TCP Strict (shown below) which means that DFW doesn't treat every packet as a brand-new event but it does recognize the relationship between a request and a reply via a state connection table. This table applies to TCP, as well as stateless protocols, such as UDP and ICMP. In the case of TCP, NSX logs the session start (the first packet) and the session end (last packet) - it does not log every single middle packet or even the TCP handshake exchange. In summary, logging follows the first packet of a session that matches the rule's criteria (including its direction). All subsequent packets in that session are "silent" due to stateful inspection.

Below are some scenarios that showcase how rules and VM location can influence logging on a particular host.

Example

VM-A: 192.168.72.10 (on Host-A)
VM-B: 192.168.72.17 (also on Host-A)
VM-C: 192.168.71.11 (on Host-C)
Physical machine (or non-NSX segment/DVPG VM): 10.38.171.20
VM-A and VM-B belong to the same group: "group"

Scenario #1: VM-A pings VM-B; VMs are on the same host

2026-03-03T00:02:11.678Z No(13) FIREWALL-PKTLOG[1069031]: 8b4a1980 INET match PASS 25577 OUT 84 ICMP 192.168.72.10->192.168.72.17
2026-03-03T00:02:11.678Z No(13) FIREWALL-PKTLOG[1069031]: 14b4051d INET match PASS 25577 IN 84 ICMP 192.168.72.10->192.168.72.17

Logic: The source of the flow first matches Rule 25577. Because the DFW is enforced at the vNIC level (the dvfilter), the host treats each VM as its own isolated island with its own firewall instanceWhen both the source and destination are on the same host, the packet essentially hits the firewall twice -once as it leaves the sender and again as it arrives at the receiver. As a result, the two log entries show the IP flow in the same direction.

Scenario #2: Physical machine (north-south flow) pings VM-A

2026-03-03T00:06:32.226Z No(13) FIREWALL-PKTLOG[1069031]: 8b4a1980 INET match PASS 25576 IN 60 ICMP 10.38.171.20->192.168.72.10

Logic: The inbound flow matches rule 25576 first and logs the IN entry as such; return traffic (ICMP reply) is not logged because of the stateful nature of the DFW.

Scenario #3: VM-A pings VM-C; VMs are on different hosts

Host-A:

2026-03-03T00:19:19.148Z No(13) FIREWALL-PKTLOG[1069031]: 8b4a1980 INET match PASS 25578 OUT 84 ICMP 192.168.72.10->192.168.71.11

Host-C:

2026-03-03T00:19:19.151Z No(13) FIREWALL-PKTLOG[1051842]: b256c2cb INET match PASS 25578 IN 84 ICMP 192.168.72.10->192.168.71.11

Logic: The only rule that matches the criteria is Rule 25578. Since two hosts are involved, each one logs the initial packet it sees but as either IN or OUT. Host-A logs the outbound flow, per VM-A; Host-C receives this same flow, inbound to VM-C.

Scenario #4: VM-A pings a non-VM destination and the DFW policy is NOT stateful:

2026-03-03T02:00:43.858Z No(13) FIREWALL-PKTLOG[1069031]: 8b4a1980 INET match PASS 25580 OUT 84 ICMP 192.168.72.10->10.37.1.20
2026-03-03T02:00:43.862Z No(13) FIREWALL-PKTLOG[1069031]: 8b4a1980 INET match PASS 25580 IN 84 ICMP 10.37.1.20->192.168.72.10

Logic: Since the policy is not stateful, there is no Connection Table Entry so rule 25580 gets logged for both the initial outbound and inbound (return) packet

Scenario #5: Same as Scenario 4 but without groups

2026-03-03T02:09:55.222Z No(13) FIREWALL-PKTLOG[1069031]: 8b4a1980 INET match PASS 25580 OUT 84 ICMP 192.168.72.10->10.37.1.20
2026-03-03T02:09:55.225Z No(13) FIREWALL-PKTLOG[1069031]: 8b4a1980 INET match PASS 25581 IN 84 ICMP 10.37.1.20->192.168.72.10

Logic: This time, the rules are written in such a way that the outbound flow can only match rule 25580 and the return traffic can only match the next rule below it. This would not happen if the policy were stateful.

Scenario #6: VM-A pings VM-C. First rule evaluates only in the OUT direction while rule below it does the same in the IN direction.

Normally, such a rule is not needed since the statefulness of the policy means that the same rule will be used for matching flows in both directions. While not practical nor recommended, this example showcases how the direction of the evaluation you can influence logging

Host-A:

2026-03-04T18:03:13.242Z No(13) FIREWALL-PKTLOG[1069031]: 8b4a1980 INET TERM PASS 25577 OUT ICMP 8 0 192.168.72.10->192.168.71.169 13/13 1092/1092

Host-C:

2026-03-04T18:03:03.516Z No(13) FIREWALL-PKTLOG[1051842]: 7fb5cc95 INET match PASS 25576 IN 84 ICMP 192.168.72.10->192.168.71.169

Logic: Both rules match the same flow, regardless of flow direction. Since each rule can only evaluate in one particular direction, the top gets hit for the outbound flow and the rule below it handles the return traffic. Logging is still spread across both hosts, for reasons explained in previous examples.

Scenario #7: DFW packet logs only show one half of the conversation. VMs are on different hosts.

While inspecting DFW packet logs for a particular flow involving two VMs on different hosts, only inbound (IN) entries are shown; the corresponding OUT flow is missing.

2026-02-26T21:33:11.123Z No(13) FIREWALL-PKTLOG[1051842]: b256c2cb INET match PASS 25577 IN 60 TCP 192.168.72.10/38810->192.168.71.11/80 S

Potential root cause: The logging is normal whenever the source and destination VMs reside on different hosts. The "missing" OUT log entry should be located on the other host.
Other root causes related to log visibility depend on various factors. The table below offers can assist when troubleshooting such incidents:

Scenario	OUT Log	IN Log	Reason
Standard flow	Yes	No	State table handles the return.
Asymmetric route	No	Yes	Due to multiple VM interfaces, DFW only sees one direction of the flow, such as the reply
State timeout	No	Yes	Original "OUT" state is gone; return packet is treated as a new table entry
Different rules hit for each direction	Yes	Yes	The Connection State table does not handle the return because DFW policy is not stateful
Rule direction (IN-OUT)	n/a	n/a	Setting pertains to direction of flow evaluation.

For rule direction, even if a rule is set to IN-OUT, you will not see two logs (one IN and one OUT) for a single external conversation on the same host.

Outbound Packet: Hits the IN-OUT rule. Direction is OUT. Log Generated.
State Created: The firewall "remembers" this connection.
Inbound Packet (Reply): Returns to the VM. Because the firewall is stateful, it sees this packet matches an existing connection state
Bypass: The inbound packet bypasses the rule evaluation entirely.
Result: No IN log is generated for the reply on the source host, even though the rule says IN-OUT.

How many hosts involved in the flow matters:

If both VMs reside on different hosts, you will see the source host log in the OUT direction and the destination host log the IN direction.
If either source or destination is outside of the NSX environment (i.e, north-south traffic), then you will only see IN or OUT on the given host.

For example, if you have a rule allowing VM-A to talk to VM-B with logging enabled and the direction set to IN_OUT, even a single ping will actually generate two separate logs from two different points of view:

Log Source	Perspective	Logged Action
ESXi Host 1	VM-A (Source)	`OUT` - Allowed leaving the VM.
ESXi Host 2	VM-B (Dest)	`IN` - Allowed entering the VM.

EXAMPLES

For all of the scenarios below:

The DFW policy is using Stateful and TCP Strict (default)
Each VM has a single interface
There is no other network asymmetry

Scenario #7a: VM-A and VM-B are on the same host

2026-02-27T22:33:39.223Z No(13) FIREWALL-PKTLOG[1051842]: 8b4a1980 INET match PASS 25577 OUT 60 TCP 192.168.72.10/38810->192.168.71.11/80 S
2026-02-27T22:33:39.223Z No(13) FIREWALL-PKTLOG[1051842]: b256c2cb INET match PASS 25577 IN 60 TCP 192.168.72.10/38810->192.168.71.11/80 S

Logic: The packet essentially hits the firewall twice—once as it leaves the sender and once as it arrives at the receiver. As a result, you will see both IN and the corresponding OUT log entries on that host but in the same direction

Scenario #7b: VM-A and VM-B are on the same host. VM-A attempts an SSH session to VM-B

2026-03-03T23:39:03.904Z No(13) FIREWALL-PKTLOG[1051842]: 8b4a1980 INET match PASS 25577 OUT 60 TCP 192.168.72.10/36310->192.168.71.169/22 S 
2026-03-03T23:39:03.906Z No(13) FIREWALL-PKTLOG[1051842]: 7fb5cc95 INET match PASS 25577 IN 60 TCP 192.168.72.10/36310->192.168.71.169/22 S 
2026-03-03T23:39:23.399Z No(13) FIREWALL-PKTLOG[1051842]: 8b4a1980 INET TERM PASS 25577 OUT TCP RST 192.168.72.10/36310->192.168.71.169/22 4/3 204/196 
2026-03-03T23:39:23.399Z No(13) FIREWALL-PKTLOG[1051842]: 7fb5cc95 INET TERM PASS 25577 IN TCP RST 192.168.72.10/36310->192.168.71.169/22 4/3 204/196

Logic: The first two logs show the initial TCP SYN leaving VM-A and arriving on VM-B. Since both VMs reside on the host, both are logged. As the port was not opened, the TCP timer expired and VM-A decides to reset the connection. Just as with the SYN, the RST gets logged by both VMs.