Blocked by Windows Firewall? See what is blocked and allow it

A program can't connect, a port seems closed, a colleague can't reach your share. Before you open anything, find out what is blocked and which rule did it. Then allow exactly that, and nothing more.

1. Is it really the Windows Firewall?

"Blocked by firewall" can also mean the router, another security program, or a firewall at the other end. Two quick checks:

• Is the program listening at all? In PowerShell: Get-NetTCPConnection -State Listen -LocalPort 8080 (Windows 8 / Server 2012 and later), or netstat -ano | findstr :8080 on any version. Nothing listening means no firewall rule will help.
• Which network profile are you on? Get-NetConnectionProfile shows Domain, Private or Public. Many rules are enabled for Private only, so a network that Windows sees as Public blocks them.

2. See what Windows Firewall is blocking

The firewall log (pfirewall.log)

Windows can write every dropped packet to a text file. It is off by default. To switch it on: wf.msc › Windows Defender Firewall Properties › the tab of your profile (Domain, Private, Public) › Logging › Customize › Log dropped packets: Yes. Or, as administrator:

netsh advfirewall set allprofiles logging droppedconnections enable

On Windows 8 / Server 2012 and later also:

Set-NetFirewallProfile -Profile Domain,Private,Public -LogBlocked True

The file is %systemroot%\system32\LogFiles\Firewall\pfirewall.log. Each line has the date, time, action (DROP), protocol, source and destination address and port. Its default size limit is 4 MB, so it rolls over quickly on a busy Server; you can raise the limit on the same Logging page.

What the log does not tell you: which rule dropped the packet, and which program it was meant for.

Security events 5152 and 5157

The Windows Filtering Platform, which the firewall is built on, can write blocked connections to the Security log. Enable the failure auditing as administrator. The GUIDs work in every Windows language; the subcategory names are translated:

auditpol /set /subcategory:{0CCE9226-69AE-11D9-BED3-505054503030} /failure:enable
auditpol /set /subcategory:{0CCE9225-69AE-11D9-BED3-505054503030} /failure:enable

The first is Filtering Platform Connection (event 5157, "The Windows Filtering Platform has blocked a connection"), the second Filtering Platform Packet Drop (event 5152, "The Windows Filtering Platform has blocked a packet"). Event 5157 also names the application. Then look in Event Viewer › Windows Logs › Security:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5157} -MaxEvents 20 | Format-List TimeCreated, Message

The event contains a Filter Run-Time ID, not the rule name. Matching it to a rule means exporting all filters with netsh wfp show filters (a large XML file in the current folder) and searching it for that ID. It works, but it is slow detective work. Leave success auditing off unless you need it: it logs every allowed connection and fills the log fast.

3. Allow an app through Windows Firewall

• The simple way: Windows Security › Firewall & network protection › Allow an app through firewall (or firewall.cpl › Allow an app or feature through Windows Defender Firewall). Click Change settings, tick the app, and tick only the profiles it needs (usually Private, not Public). Allow another app… adds a program that is not listed.
• The precise way: wf.msc › Inbound Rules › New Rule… › Program › the .exe › Allow the connection › profiles › name. Afterwards open the rule's Scope tab and limit Remote IP address to the addresses that really connect.

From the command line (as administrator):

netsh advfirewall firewall add rule name="My app" dir=in action=allow program="C:\Program Files\MyApp\myapp.exe" enable=yes

New-NetFirewallRule -DisplayName "My app" -Direction Inbound -Program "C:\Program Files\MyApp\myapp.exe" -Action Allow -Profile Domain,Private

4. Open a port in Windows Firewall

wf.msc › Inbound Rules › New Rule… › Port › TCP or UDP › the port number › Allow the connection. Or:

netsh advfirewall firewall add rule name="Open TCP 8080" dir=in action=allow protocol=TCP localport=8080

New-NetFirewallRule -DisplayName "Open TCP 8080 (LAN)" -Direction Inbound -Protocol TCP -LocalPort 8080 -RemoteAddress 192.168.1.0/24 -Action Allow

Keep it tight: a port opened to any address on a computer that is reachable from the internet is open to the whole internet. -RemoteAddress (or Scope in wf.msc) limits who may connect, and -Profile limits on which networks. If the port is meant to be reached from the internet, the router must forward it too.

5. Block a program in Windows Firewall

Windows allows outbound connections by default, so blocking a program needs an outbound block rule:

netsh advfirewall firewall add rule name="Block myapp out" dir=out action=block program="C:\Program Files\MyApp\myapp.exe" enable=yes

New-NetFirewallRule -DisplayName "Block myapp out" -Direction Outbound -Program "C:\Program Files\MyApp\myapp.exe" -Action Block

A block rule wins over an allow rule for the same traffic. Two limits to know: a rule matches one exact path, so a program that updates itself into a new folder escapes it; and the opposite approach, blocking all outbound traffic and allowing programs one by one, is possible (Outbound connections: Block in the profile properties) but breaks things quickly if you have to find every program by hand.

6. Find the rule that blocks it

To list the block rules that are switched on:

Get-NetFirewallRule -Enabled True -Action Block | Format-Table DisplayName, Direction, Profile

Rules can also come from a Group Policy; those are shown in wf.msc but can only be changed in the policy. And if no rule matches at all, the profile's default decides: inbound is blocked unless a rule allows it.

7. Doing this by hand means…

• Switching on logs first, then reading text files and Security events after something already went wrong.
• No rule name in the firewall log, and only a filter ID in event 5157: finding the rule that blocked something is detective work.
• Rules to maintain: program paths change with updates, ports opened for a test stay open, and nobody remembers why a rule is there.
• Nobody watching at night: scanners and password guessers keep trying, and Windows raises no alert.

8. With Coinetic: installed in minutes, then it runs by itself

Coinetic works through the Windows Firewall that is already there and shows you what it does.

• See every connection live, with the rule that decided it. Each log line is one connection attempt, allowed or blocked; blocked lines always name the rule. (For allowed traffic Windows does not report which allow rule matched, so those lines say (allowed).)
• One click from a blocked line to a rule. Right-click › Make a rule matching this packet or Edit the matching rule: the rule editor opens already filled in with program, ports and addresses.
• Programs ask once before they connect out. Switch a profile to block outbound and decide per program: allow, LAN only, only this address, block, or allow for 1 hour, 8 hours or until restart.
• Scanners and password guessers are banned automatically, also at night: the Coinetic Protection service runs in the background, also when nobody is logged on.
• A security scan finds weak spots, such as ports open to the internet, and fixes what it can with one click.
• Nothing hidden: Coinetic's rules are normal Windows Firewall rules whose names start with Coinetic, from Windows 7 / Server 2008 R2 on, in any Windows language.
• Your AI security analyst (Pro + AI): right-click any line, ban, port or connection and choose Ask AI, e.g. “Why was this program blocked, and is it safe to allow it?”. It looks up this computer's Coinetic data itself and answers in plain words, with what to do on this machine.

More guides: all Coinetic guides.

Frequently asked

Where is the Windows Firewall log?

%systemroot%\system32\LogFiles\Firewall\pfirewall.log, usually C:\Windows\System32\LogFiles\Firewall\pfirewall.log. It stays empty until you switch on Log dropped packets (or Log successful connections) for the profile.

Why does my rule not work?

The usual reasons: the rule is for the wrong profile (Private, but the network is Public), the wrong program path, a block rule for the same traffic, or a Group Policy that ignores local rules. Also check that the program is actually listening.

Is it safe to turn off Windows Firewall to test?

Only for a minute, and not on a computer that is reachable from the internet. Better: leave it on and read the log or event 5157, which tell you what was blocked.

How do I see which program was blocked?

pfirewall.log has only addresses and ports. Security event 5157 names the application; Coinetic's live log shows the program, the address and the rule on one line.