Reading the Windows Firewall Log (pfirewall.log) on Windows 11

The Problem With This Artifact

pfirewall.log is genuinely useful — it is the only built-in Windows source that records connection destinations without installing anything. It is also disabled by default, which means when you actually need it, it usually is not there.

So this article has two halves. Turn it on now, on machines you administer, so the log exists when something goes wrong. And know how to read it when you inherit a machine where someone already did.

Part 1: Enable Logging

Each firewall profile — Domain, Private, Public — logs separately and must be enabled separately. Machines commonly have it on for one profile and off for the one that was actually in use.

Step 1: Turn it on for all three profiles

From an elevated PowerShell prompt:

netsh advfirewall set allprofiles logging droppedconnections enable
netsh advfirewall set allprofiles logging allowedconnections enable
netsh advfirewall set allprofiles logging maxfilesize 32767

maxfilesize is in kilobytes, and 32767 is the maximum — about 32 MB. The default of 4 MB fills in hours on an active machine, and when it fills Windows rotates the current log to pfirewall.log.old and starts fresh, so you get roughly two files' worth of history and no more.

Enabling allowed connections as well as dropped is the part people skip. Dropped connections tell you what the firewall stopped. Allowed connections tell you what it did not — which is where the interesting traffic is, because malware that works is malware the firewall permitted.

Step 2: Confirm it is writing

netsh advfirewall show allprofiles logging

Then check the file exists and is growing:

Get-Item C:\Windows\System32\LogFiles\Firewall\pfirewall.log | Select-Object Length, LastWriteTime

If the file is missing after a few minutes of network activity, the most common cause is the log directory's permissions — the MpsSvc service account needs write access to C:\Windows\System32\LogFiles\Firewall.

Part 2: Read the Format

The log is plain text, space-delimited, with a header block naming the fields:

#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path

A real line looks like:

2026-08-08 14:22:19 ALLOW TCP 192.168.1.42 104.18.32.7 51234 443 0 - 0 0 0 - - - SEND

The fields worth internalising:

• action — ALLOW, DROP, or INFO-EVENTS-LOST (the last means the log could not keep up and you have gaps).
• src-ip / dst-ip — for outbound traffic, dst-ip is where your machine reached.
• dst-port — the service. 443 and 80 are web, 53 is DNS, 3389 is RDP.
• path — SEND for outbound, RECEIVE for inbound. This is the field that makes the log readable; everything else is symmetric.

Times are local, not UTC. This differs from the Windows event log and is the most common mistake when combining the two into one timeline.

Step 3: Find inbound connections that were allowed

Inbound allows on a home machine are the shortest path to something interesting:

Select-String -Path C:\Windows\System32\LogFiles\Firewall\pfirewall.log -Pattern "ALLOW" |
  Where-Object { $_.Line -match "RECEIVE" }

Then look at destination ports. 3389 means RDP — cross-check against RDP session logs. 445 means SMB. Anything high and unfamiliar, accepted repeatedly, is worth identifying.

Step 4: Look for beaconing

Command-and-control traffic tends to be regular in a way human browsing is not. Extract outbound connections to a single destination and look at the intervals:

Select-String -Path C:\Windows\System32\LogFiles\Firewall\pfirewall.log -Pattern "203\.0\.113\.55" |
  ForEach-Object { ($_ -split ' ')[0..1] -join ' ' }

Connections at a near-constant interval — every 60 seconds, every 5 minutes, every hour on the hour — are automated. That is not automatically malicious (update checkers and telemetry do the same), but it separates scheduled activity from a person using a browser, and it gives you a start time.

Step 5: Cross-reference with which process did it

Here is the log's central weakness: pfirewall.log does not record the process. You get an IP and a port, not the executable.

To close that gap:

• SRUM — per-application byte counts in roughly hourly buckets. Match the volume against the firewall log's timing to identify the process.
• Sysmon Event ID 3 — network connection with the full process path. This is the right long-term answer; the firewall log is the fallback when Sysmon was not installed.
• netstat -bano on a live machine, if the connection is still open.

What Not To Conclude

Volume of DROP entries is normal. An internet-connected machine is scanned constantly. Thousands of dropped inbound connections from random addresses is background noise, not an attack in progress.

INFO-EVENTS-LOST means your log has holes. Under heavy traffic the logging subsystem drops records. Absence of an entry during a period containing this marker proves nothing.

No process attribution. Worth repeating, because it is the single most common overreach with this artifact. An outbound connection to a suspicious IP tells you the machine connected. It does not tell you what connected.

Related

• How to tell if a Windows 11 PC was remotely accessed
• SRUM on Windows 11
• Consumer guide: when Windows Firewall blocks an app you need

FAQ

Where is pfirewall.log on Windows 11?

C:\Windows\System32\LogFiles\Firewall\pfirewall.log, with the previous rotation at pfirewall.log.old in the same folder. The path is configurable per profile, so if the file is not there, check the configured location with netsh advfirewall show allprofiles logging.

Why is my firewall log empty or missing?

Logging is disabled by default on all three profiles — that is the usual answer. The other common cause is a permissions problem on the log directory: the firewall service account must be able to write to C:\Windows\System32\LogFiles\Firewall. Enable logging with netsh, generate some traffic, and confirm the file's size is increasing.

Can I tell which program made a connection from this log?

No. The log records addresses, ports and direction, with no process context at all. Use Sysmon Event ID 3 for connections with full process paths, SRUM for per-application volume that you can time-match, or netstat -bano while the connection is still live.

How much history does the log keep?

One file at the configured maximum size plus one rotated .old file. At the 32 MB maximum that is typically days on a normal desktop and hours on a busy one. For anything longer you need to copy the log off on a schedule or forward the events elsewhere — the firewall will not keep it for you.