A firewall protects your computer and network by controlling incoming and outgoing connections. It checks network traffic against a set of rules and blocks connections that do not meet those rules. Although this protection is important, an incorrect firewall rule can sometimes prevent a legitimate application or network port from working as expected.
In general, you can check whether a firewall is blocking a program or port on Windows 11 and Windows 10 without immediately disabling your security protection. You can review firewall rules, test port connectivity, and examine Windows Firewall logs to identify possible problems.
In this guide, you’ll learn how to check firewall settings, test a specific port, and use Command Prompt and PowerShell.
How to Check If a Firewall Is Blocking a Port or Program
To check if a firewall is blocking a port or program on Windows 11 or Windows 10, follow these steps:
- Open Windows Security > Firewall & network protection.
- Open Allow an app through firewall and review its permissions.
- To test a TCP port, open PowerShell and run Test-NetConnection hostname -Port portnumber, replacing the placeholders with the correct values.
- Open Windows Defender Firewall with Advanced Security and inspect inbound and outbound rules.
- Enable Windows Firewall logging and review the firewall log file.
- Verify that the application is running, the correct port is listening, and the network is allowing the connection.
Step 1: Check Your Windows Firewall Settings
Start by checking whether Microsoft Defender Firewall is enabled and which network profile is active. Windows typically uses different firewall profiles for domain, private, and public networks. A rule that allows an application on a private network might not allow it on a public network.
Press Windows + S, type Windows Security, and open the application. Select Firewall & network protection to see your available network profiles and their firewall status.
Follow this navigation path: Windows Security > Firewall & network protection > Active network profile.
Select the profile marked as active to review its settings. If the firewall is enabled, that does not automatically mean it is blocking your application. It simply means the firewall is filtering traffic according to its rules.
If you use third-party security software, such as another firewall product, check its settings too. Some security suites manage network traffic independently of Microsoft Defender Firewall.
Avoid turning off your firewall just to see whether an application works. Instead, review the relevant application permissions and network rules first.
Step 2: Check Whether the Program Is Allowed Through the Firewall
If a particular application cannot connect to the internet, check whether Windows Firewall allows it to communicate on your current network.
Open Windows Security and navigate to Firewall & network protection > Allow an app through firewall. Select Change settings if the list is locked and you have permission to make changes.
Find the application in the list and review its checkboxes under the available network profiles. A checkmark under Private allows the application under the private profile, while a checkmark under Public allows it under the public profile.
For example, a trusted application might be allowed on your home network but blocked on a public Wi-Fi network. That difference could explain why it works at home but fails elsewhere.
If the application is missing, use Allow another app to add the correct executable, provided you trust the program and have verified its location. Choose the appropriate network profile instead of automatically allowing access everywhere.
The navigation path is Windows Security > Firewall & network protection > Allow an app through firewall.
Keep in mind that this list does not show every possible firewall restriction. A separate inbound or outbound rule, third-party firewall, router setting, or network policy could still block the connection.
Step 3: Test Whether a Specific Port Is Reachable
If you suspect that a particular port is blocked, use PowerShell to test whether a remote computer or server accepts a TCP connection on that port.
Press Windows + X and open Terminal or PowerShell. You generally do not need administrator privileges to run this connection test.
Enter the following command, replacing the hostname and port number with the actual server and port you want to test.
Test-NetConnection example.com -Port 443
The navigation path is Start > Terminal > PowerShell > Test-NetConnection.
Look for the TcpTestSucceeded result. If it displays True, the TCP connection to that destination and port succeeded. If it displays False, the connection failed.
However, a failed test does not prove that Windows Firewall is responsible. The destination server may be offline, the port may not be listening, a router may be blocking the traffic, or another network firewall may be interfering.
For a local application, you can also check whether the expected port is listening on your PC. Open Command Prompt and run:
netstat -ano | findstr :8080
Replace 8080 with the port number used by your application. Look for a LISTENING entry, which indicates that a process is listening on that port. If no matching listening entry appears, the application might not be running correctly or might be configured to use a different port.
Step 4: Review Inbound and Outbound Firewall Rules
Windows Firewall uses rules to determine which network connections are permitted or blocked. Inbound rules control incoming connections to your computer, while outbound rules control connections initiated by applications on your computer.
To inspect these rules, press Windows + R, type wf.msc, and press Enter. This opens Windows Defender Firewall with Advanced Security.
Select Inbound Rules in the left panel to review incoming connection rules. Select Outbound Rules to inspect rules governing outgoing connections.
Follow this path: Windows + R > wf.msc > Inbound Rules or Outbound Rules.
Look for rules associated with the affected application, executable file, protocol, or port number. Check whether the rule is enabled, whether its action is set to Allow or Block, and which profiles it applies to.
For example, a web server running on your computer may need an inbound rule for TCP port 8080. If an applicable blocking rule prevents incoming connections, devices on your network might not be able to reach that server.
Do not assume that every disabled rule is a problem or that every enabled block rule applies to your connection. Rule scope, profiles, addresses, and other settings determine whether a rule affects the traffic you’re testing.
If your computer is managed by an employer or school, some firewall rules may be controlled by an administrator. Avoid changing organizational security policies without permission.
Step 5: Enable Windows Firewall Logging
If you cannot identify the problem by reviewing the rules, firewall logging can help you determine whether Windows Firewall is recording dropped packets.
Open the Advanced Security console by pressing Windows + R, entering wf.msc, and pressing Enter. Right-click Windows Defender Firewall with Advanced Security on Local Computer and select Properties.
Choose the relevant profile, such as Domain, Private, or Public, and select Customize in the Logging section. Enable logging for dropped packets and apply the changes. You can also enable logging for successful connections if you need additional diagnostic information.
The navigation path is wf.msc > Windows Defender Firewall Properties > Active Profile > Logging > Customize.
The default log file is commonly located at:
%systemroot%\system32\LogFiles\Firewall\pfirewall.log
Open File Explorer, enter that path in the address bar, and open the log file with Notepad. Look for entries marked DROP around the time you attempted the failed connection. Review the protocol, source address, destination address, and port information to see whether an entry matches your test.
A matching dropped-packet entry can provide evidence that the Windows firewall discarded traffic. However, the log might not identify the exact rule responsible, and the absence of a matching entry does not rule out other firewall or network restrictions.
After troubleshooting, you can turn off extra logging if you no longer need it.
Step 6: Check the Application and Local Port
Sometimes a connection fails because the application is not listening on the expected port, rather than because the firewall is blocking it.
Open Command Prompt and run:
netstat -ano | findstr :8080
Replace 8080 with your application’s port. If you see a listening entry, note the PID, which is the process ID shown in the last column.
You can then open Task Manager with Ctrl + Shift + Esc, select the Details tab, and find the matching PID. This helps you identify the process using the port.
Follow this path: Command Prompt > netstat -ano > Task Manager > Details.
If no process is listening on the expected port, check the application’s configuration and logs. Make sure the service is running and is configured to listen on the correct network interface.
If the application listens only on 127.0.0.1, it accepts connections from the local computer rather than other devices on your network.
A firewall rule alone cannot make a service accessible if the application is not listening on the appropriate interface.
FAQs
1. How do I know if Windows Firewall is blocking a port?
Test a remote TCP connection with PowerShell using Test-NetConnection hostname -Port portnumber. If the test fails, inspect firewall rules and logs. A failed test alone does not establish that Windows Firewall is the cause.
2. How do I check whether a program is blocked by Windows Firewall?
Open Windows Security > Firewall & network protection > Allow an app through firewall. Find the application and check its permissions for the active network profile. Also review the Advanced Security console for additional rules.
3. How do I check whether a port is open on my computer?
Run netstat -ano | findstr :8080 in Command Prompt, replacing 8080 with the required port. A matching LISTENING entry indicates that a process is listening on that port, but it does not guarantee that remote devices can reach it.
4. Does a failed port test always mean the firewall is blocking it?
No. The server may be offline, the service may not be listening, the port may be incorrect, or another firewall or network device may be blocking traffic. Check the service and network path before changing firewall rules.
5. Can I check blocked ports without administrator access?
You can run basic PowerShell connection tests and use netstat without administrator access in many situations. However, changing firewall rules and configuring detailed firewall logging generally requires administrator privileges.
6. Should I turn off Windows Firewall to test a connection?
It is better to inspect the relevant rule and logs first. Disabling the firewall can expose your computer to unwanted traffic and may not solve the underlying issue. If you need additional testing, use a controlled, authorized diagnostic method and restore your normal protection immediately.
Final Words
Checking whether a firewall is blocking a port or program is easier when you work through the problem systematically. Start by reviewing application permissions, test the required TCP port with PowerShell, inspect inbound and outbound rules, and examine firewall logs for dropped connections.
Remember that a failed connection does not automatically mean the firewall is responsible. The application, destination server, router, or another network security device could also be causing the problem.
Once you identify the actual cause, make a targeted firewall adjustment and repeat the connection test.