Windows Firewall Blocking an App You Trust

27 Aug 2026

You install an application, launch it and immediately discover that part of it does not work.

The program opens normally, but it cannot connect to another computer. A multiplayer game cannot host a session. A backup application cannot see a network device. A video-conferencing tool cannot receive calls. A printer utility cannot discover the printer sitting a few metres away.

Windows Firewall may be blocking the connection.

That does not necessarily mean the application is unsafe. Windows Firewall is designed to prevent unauthorised network traffic, and it may block a legitimate program when no suitable rule exists, when the wrong network profile is selected or when someone previously dismissed the firewall permission prompt.

The solution is not to switch the firewall off. The safer approach is to verify the application and create the narrowest exception it genuinely needs.

What Windows Firewall Actually Does

Microsoft Defender Firewall controls network traffic entering and leaving the computer.

For most Windows devices, unsolicited inbound connections are blocked unless an application or administrator has created an appropriate rule. Outbound traffic is normally allowed unless a specific rule blocks it.

This means an application may work perfectly when connecting to an online service but fail when another device attempts to connect back to it.

Common examples include:

File-sharing applications
Remote-support tools
Media servers
Network backup software
Multiplayer games
Development servers
Database applications
Printer discovery tools
Voice and video software
Specialist business applications

Signs the Firewall May Be Responsible

Firewall interference can produce several different symptoms:

The application opens but reports that it is offline
Other devices cannot connect to the application
A service works locally but not across the network
Printer or device discovery fails
A game can join sessions but cannot host one
Remote access works on one network but not another
An application works after the firewall is temporarily disabled
The problem began after reinstalling or updating the application
Windows previously displayed a permission prompt that was cancelled

These symptoms do not prove that Windows Firewall is the cause. Router settings, antivirus software, incorrect credentials, network isolation and application configuration can produce similar behaviour.

Do Not Turn the Firewall Off Permanently

Disabling Windows Firewall may make the application work, but it also removes an important layer of network protection.

Microsoft recommends allowing the required application through the firewall rather than switching the firewall off. Turning the firewall off can leave the computer more exposed to unauthorised network access.

A brief, controlled test may help confirm the cause, but the firewall should be turned back on immediately afterwards.

On a business computer, do not disable security controls without authorisation.

First, Make Sure You Trust the Application

Before creating an exception, verify exactly what you are allowing.

Check:

The application’s name
The software publisher
Where it was downloaded from
The executable file path
Its digital signature
Whether the software is still supported
Whether the requested network access makes sense

Be cautious if the executable is running from:

Downloads

Temp

AppData\Local\Temp

Legitimate applications sometimes use these locations during installation, but permanently installed software would usually run from locations such as:

C:\Program Files

C:\Program Files (x86)

or a clearly identified application folder.

Do not allow an application simply because its name resembles a Windows component. Malware often uses convincing filenames.

Check the Digital Signature

To inspect the program:

Open Task Manager.
Find the application.
Right-click it and select Open file location.
Right-click the executable.
Select Properties.
Open the Digital Signatures tab, if present.

Check that the signer matches the expected developer.

A valid signature does not guarantee that software is safe, but an unexpected or missing signature should prompt additional investigation.

You can also scan the file with Microsoft Defender or your organisation’s approved security software.

Check Which Firewall Is Active

Windows Security can show whether Microsoft Defender Firewall or another security product is managing the firewall.

Open:

Windows Security > Firewall & network protection

If a third-party security suite is listed as the active provider, changing Windows Firewall rules may not resolve the issue. The rule may need to be created inside that product instead. Windows Security displays the firewall providers protecting the computer.

Avoid running multiple firewall products with overlapping controls unless they are specifically designed to work together.

Check the Current Network Profile

Windows uses different firewall profiles depending on the network:

Domain
Private
Public

A Private network is normally a trusted home or business network. A Public network is treated more cautiously because other devices may be untrusted.

Open:

Settings > Network & internet

Select the active Wi-Fi or Ethernet connection and check the network profile.

Do not change a genuinely public network to Private simply to make an application work. Instead, configure the application’s rule so it applies only where needed.

For example, a printer-discovery tool may reasonably require access on a Private office network but should not accept connections while the laptop is connected to airport Wi-Fi.

Allow the App Through Windows Firewall

For most trusted applications, the standard allowed-apps list is the simplest fix.

Open:

Windows Security > Firewall & network protection

Select:

Allow an app through firewall

Then:

Select Change settings.
Approve the administrator prompt.
Find the application in the list.
Select the required network profile.
Select OK.

Microsoft advises that adding an application to the allowed list is generally safer than opening a port manually because the required access is associated with the program rather than leaving a port continuously available.

Private or Public: Which Box Should You Select?

You may see separate checkboxes for Private and Public networks.

Private

Select this when the application only needs to communicate on trusted networks, such as:

Your office
Your home
A controlled private LAN
A trusted testing environment

This is normally the safer choice for:

Network printers
Local file sharing
Media servers
Development tools
Device-discovery utilities

Public

Select this only when the application genuinely needs inbound access while connected to public networks.

Allowing an application on Public networks increases exposure because the computer may accept related traffic in hotels, cafés, airports and other shared locations.

For many applications, Private only is sufficient.

The App Is Not in the List

If the application is missing:

Select Allow another app.
Choose Browse.
Locate the correct executable file.
Select Add.
Choose the required network profile.
Select OK.

Make sure you select the executable that actually handles the network traffic.

Some applications contain several executables, such as:

The main interface
A background service
An updater
A server component
A launcher
A helper process

Allowing the visible application may not help if a separate service performs the network communication.

Check the software developer’s documentation for the correct executable and required ports.

A Previous “Allow Access” Prompt Was Cancelled

The first time an application attempts to receive network traffic, Windows may display a prompt asking whether to allow access.

If the prompt was cancelled or declined, Windows may create blocking rules for that program. Microsoft notes that dismissing or rejecting the prompt can result in TCP and UDP block rules being created.

Adding the application to the allowed-apps list may correct the problem.

If it does not, open the advanced firewall console and look for an explicit blocking rule.

Check Advanced Firewall Rules

Press:

Windows + R

Enter:

wf.msc

This opens Windows Defender Firewall with Advanced Security.

Review:

Inbound Rules

and:

Outbound Rules

Look for rules matching:

The application name
The executable path
The publisher
The service name
The relevant port

Check the rule’s:

Enabled status
Action
Direction
Program path
Protocol
Local and remote ports
Network profile
Local and remote addresses

An enabled Block rule can override the behaviour you expected from an allow rule, depending on how the policies have been configured.

Do not delete unfamiliar rules immediately. Disable the suspected rule temporarily, test the application and document any change.

Inbound Versus Outbound Rules

Understanding the direction matters.

Inbound rule

Controls traffic arriving at the computer.

An inbound exception may be needed when:

Another computer connects to the application
The PC hosts a game or server
A network scanner sends data to the PC
A remote-support tool receives a connection
A local device discovers or communicates with a service

Outbound rule

Controls traffic leaving the computer.

Windows normally allows outbound traffic unless a blocking rule or organisation policy says otherwise.

If an application cannot reach an internet service, inspect outbound rules, third-party security products, proxy settings and organisational policies.

Creating a Program Rule Manually

When the standard allowed-app interface is insufficient, create a specific rule.

In wf.msc:

Select Inbound Rules or Outbound Rules.
Select New Rule.
Choose Program.
Select This program path.
Browse to the application executable.
Choose Allow the connection.
Select the appropriate profiles.
Give the rule a clear name.
Add a useful description where possible.

For example:

Allow Contoso Backup Service – Private Network Only

Clear rule names make future troubleshooting much easier.

Microsoft’s advanced firewall console supports rules scoped to a program, ports, protocols, network profiles and IP addresses.

Limit the Rule Wherever Possible

Avoid creating a broad rule when a narrow one will work.

A safer rule might be restricted by:

Program path
Protocol
Local port
Remote port
Private profile only
Specific local IP addresses
Specific remote IP addresses
A particular Windows service

For example, if a backup application should only communicate with a server at 192.168.1.20, the rule may be limited to that remote address rather than allowing access from every device.

This follows the principle of least privilege: allow only what the application genuinely requires.

Should You Open a Port?

Some software documentation instructs you to open a specific TCP or UDP port.

Only do this when:

The application genuinely requires it
The port and protocol are confirmed by the developer
A program-specific rule is not suitable
The scope can be restricted appropriately

Microsoft considers opening a port riskier than allowing a specific application because the port can remain available regardless of whether the intended application is running.

When creating a port rule, confirm:

TCP or UDP
Local or remote port
Inbound or outbound direction
Required network profiles
Whether specific IP addresses can be used
Whether the rule is still needed after testing

Do not open large ranges of ports merely to “make it work.”

TCP and UDP Are Not Interchangeable

An application may use:

TCP
UDP
Both protocols

Creating a TCP rule does not automatically permit UDP traffic on the same numbered port.

If the developer specifies both, create separate rules unless the management interface explicitly supports the required combination.

Avoid guessing the protocol. Use the vendor’s documentation or examine the actual connection attempt.

The Rule Exists, but the App Is Still Blocked

A firewall rule may look correct but still fail because:

It applies to the wrong executable
The program was updated and moved location
The rule applies to the wrong network profile
A separate Block rule exists
The application uses a Windows service
The required port has changed
A third-party firewall is active
Group Policy or Intune is overriding local rules
The network itself blocks the traffic
The application is listening only on localhost
The destination server is unavailable

Check the application’s executable path carefully. Some software updates install a new version in a different folder, leaving the old firewall rule pointing at a file that is no longer used.

Check Whether the Application Is Listening

A firewall exception cannot help if the application is not actually accepting connections.

Open Terminal and run:

netstat -ano

Look for the expected local port and a state such as:

LISTENING

The final column shows the process ID.

Match that process ID in Task Manager’s Details tab.

PowerShell can also display listening TCP connections:

Get-NetTCPConnection -State Listen

If the expected application or port is absent, the issue may be within the application configuration rather than the firewall.

Test the Port from PowerShell

To test whether the computer can reach a remote service:

Test-NetConnection servername -Port 443

Replace servername and 443 with the correct destination and port.

The result can help distinguish between:

Name-resolution problems
Routing failures
Closed remote ports
Firewall interference
A service that is not running

A successful TCP test does not prove that the whole application protocol works, but it confirms that the basic connection can be established.

Check for “Block All Incoming Connections”

Within the active network profile in Windows Security, there is an option to block all incoming connections, including applications already on the allowed list.

When enabled, this setting overrides normal allowed-app exceptions and can cause trusted applications to stop accepting inbound connections.

This setting may be appropriate on an untrusted network but can cause confusion when troubleshooting.

Do not disable it without considering why it was enabled.

Business Devices May Be Centrally Managed

On company computers, firewall settings may be delivered through:

Microsoft Intune
Group Policy
Microsoft Defender for Endpoint
Another endpoint-security platform
A third-party managed firewall

Local changes may be unavailable, disappear after a policy refresh or have no effect because local rule merging has been disabled.

Microsoft documents that administrators can prevent locally created firewall rules from being combined with centrally managed policy.

Do not attempt to bypass organisational controls. Ask the IT administrator to create an approved rule.

Provide them with:

Application name and version
Publisher
Executable path
Required ports
TCP or UDP
Inbound or outbound direction
Required network profiles
Relevant server addresses
The exact error message
The time the failure occurred

Check the Firewall Log

Advanced troubleshooting may require firewall logging.

In wf.msc:

Right-click Windows Defender Firewall with Advanced Security.
Select Properties.
Open the relevant profile tab.
Under Logging, select Customize.
Enable logging for dropped packets where appropriate.
Note the log file location.
Reproduce the problem.
Review the log.

The default log is commonly stored under:

C:\Windows\System32\LogFiles\Firewall

Firewall logs can be difficult to interpret because they record network addresses, ports, protocols and actions rather than friendly application names.

Disable unnecessary verbose logging after the investigation to avoid excessive log growth.

Antivirus Exclusions Are Not Firewall Exceptions

Adding an antivirus exclusion is not the same as allowing an application through the firewall.

These controls solve different problems:

Firewall rule: permits or blocks network traffic
Antivirus exclusion: prevents selected files or processes from being scanned
Controlled folder access exception: allows an application to modify protected folders
Smart App Control or reputation warning: evaluates whether an application should run

Do not add antivirus exclusions to fix a network problem. That weakens malware scanning without correcting the firewall rule.

The Router May Be Blocking the App

Windows Firewall only controls traffic at the computer.

For connections coming from the internet, the router may also require:

Port forwarding
NAT configuration
VPN access
A static local address
An approved external firewall rule

Do not expose services directly to the internet unless this is genuinely necessary and properly secured.

Remote Desktop, databases, file shares and administrative interfaces should generally be protected by a VPN or another controlled access method rather than broad internet-facing port forwarding.

Test Without Creating a Permanent Security Gap

A controlled troubleshooting test might involve temporarily disabling the firewall for the active profile, reproducing the problem and immediately re-enabling it.

This should only be done:

For a very short period
On a trusted network
With other users informed where relevant
After saving work
With the application and test already prepared

If the problem remains while the firewall is disabled, the firewall is probably not the cause.

Do not leave the firewall disabled after testing.

Remove Rules You No Longer Need

Firewall rules often accumulate after applications are uninstalled or replaced.

Periodically review exceptions and remove or disable rules for:

Uninstalled applications
Old program versions
Temporary testing tools
Previous server addresses
One-off support sessions
Obsolete development environments

Microsoft recommends removing allowed applications and closing ports that are no longer required.

Document business-critical rules before changing them.

Resetting the Firewall

Windows provides an option to restore firewall settings to their defaults.

This can remove damaged or conflicting custom rules, but it also deletes legitimate exceptions created for:

Business applications
Printers
Remote support
File sharing
Development tools
Backup systems
Specialist devices

Do not reset the firewall as an early troubleshooting step.

Before resetting:

Export or document important rules.
Confirm that the device is not centrally managed.
Record required application ports.
Plan how approved rules will be recreated.
Ensure remote access will not be lost.

A remote administrator can disconnect themselves by deleting the rule supporting their own connection.

A Safe Troubleshooting Order

When Windows Firewall appears to be blocking a trusted application, use this sequence:

Confirm the application is legitimate and fully updated.
Check which firewall product is active.
Confirm the current network profile.
Add the application through the standard allowed-apps interface.
Allow it on Private networks only unless Public access is genuinely required.
Confirm the correct executable path.
Check for explicit Block rules.
Review inbound and outbound rules in wf.msc.
Confirm the application is listening on the expected port.
Test connectivity with Test-NetConnection.
Check for centrally managed policies.
Create a narrowly scoped program or port rule where required.
Remove temporary or obsolete rules after testing.

Need Help Creating a Safe Firewall Exception?

A firewall rule that is too restrictive can stop legitimate business software from working. A rule that is too broad can expose the computer or network unnecessarily.

Hamilton Group can identify the traffic an application requires, review existing firewall policies and create a tightly controlled exception without switching off essential protection.

Call 0330 043 0069 or visit hgmssp.com to speak with one of our IT experts.

Previous Next