How to Create a Secure Inbound Firewall Rule in Windows 11 and 10

Before you open an inbound port​

Inbound rules allow other devices to initiate a connection to your PC. Windows blocks unsolicited inbound traffic by default, and an allow rule is an exception to that protection. Keep the exception as narrow as possible:

• Prefer a rule that combines one program with one TCP or UDP local port.
• Apply it only to the profile where the service is needed: Private for a trusted home or work network, Domain for a managed domain network, or Public only when there is a clear operational requirement and remote addresses are tightly restricted.
• Restrict remote IP addresses whenever you know the devices that need access.
• Use the application vendor’s documentation to confirm the protocol and listening port. Do not guess common port numbers.
• Sign in with an account that has administrator rights.

To see the currently assigned network category, open Windows PowerShell and run:

Get-NetConnectionProfile

Check the NetworkCategory value:

• Private is normally appropriate for a network you trust.
• Public is intended for untrusted networks, such as hotel, airport, or café Wi-Fi.
• DomainAuthenticated corresponds to the Domain firewall profile.

Warning: Do not create an unrestricted allow rule for Any program, Any protocol, All ports, and Any IP address unless you fully understand the exposure. That combination makes the PC broadly reachable on the active network profile.

Click to expand...

If the computer belongs to an organization, firewall settings may be controlled by Group Policy or device management. A locally created rule can be overridden or ignored if your organization has disabled local firewall-rule merging. Contact the IT administrator rather than weakening other security settings to work around that policy.

Create a precise inbound rule with Windows Defender Firewall with Advanced Security​

The same advanced firewall console and rule wizard are available in Windows 10 and Windows 11.

Before starting, write down:

• The full path to the executable file, if you are allowing an application.
• Whether the service uses TCP or UDP.
• The local port or port range on this PC.
• The remote device’s IP address, or the subnet that needs access.
• The profile on which the service should be reachable.

For this example, substitute your own values:

• Program: C:\Program Files\ExampleApp\ExampleServer.exe
• Protocol: TCP
• Local port: 8443
• Allowed remote device: 192.168.50.25
• Profile: Private
• Press Start, type:
  wf.msc
  Then select Run as administrator if prompted. This opens Windows Defender Firewall with Advanced Security.
• In the left pane, select Inbound Rules.
• In the right Actions pane, select New Rule….
• On the Rule Type page, select Custom, then select Next.
  The simpler Program and Port choices are useful for broad rules, but Custom displays the pages needed to combine a program, port, scope, and profile into one rule.
• On the Program page, choose one of the following:
• To allow one application only, select This program path, select Browse…, and choose the application’s .exe file.
• To permit traffic to a port regardless of which program uses it, select All programs.

For most local services, use This program path. Select Next.

• On the Protocol and Ports page:
• For Protocol type, select TCP or UDP as required by the application.
• Under Local port, select Specific Ports and enter the listening port. You can enter a single port such as 8443, several comma-separated ports, or a range such as 5000-5010.
• Leave Remote port set to All Ports unless the application’s documentation specifically requires a remote-port restriction.

For an inbound rule, the local port is normally the important value because it is the port on your PC that receives the connection. Select Next.

• On the Scope page, limit which computers may reach the service.
• Under Which local IP addresses does this rule apply to?, leave Any IP address unless this PC has multiple network adapters and the application must accept traffic only through one specific local address.
• Under Which remote IP addresses does this rule apply to?, select These IP addresses.
• Select Add…, then enter one of the following:
• A single device address, such as 192.168.50.25
• A subnet, such as 192.168.50.0/24
• An IPv4 address range, when necessary

Select OK, then select Next.

Use an IP address or network range, not a device name. If the permitted device receives its address through DHCP, reserve its address in the router or update the rule when the address changes.

• On the Action page, select Allow the connection, then select Next.
  Do not select Allow the connection if it is secure unless you have already deployed the necessary connection-security and IPsec configuration. That option is not a substitute for a conventional port rule.
• On the Profile page, select only the profiles where the application must accept inbound traffic.
• Select Private for a trusted local network.
• Select Domain when the service is intended only for a domain-managed environment.
• Avoid selecting Public unless required. If it is required, retain a restrictive remote-IP scope.

A rule activates only while one of its selected profiles is active. Select Next.

• On the Name page, give the rule a specific, searchable name. For example:
  ExampleServer TCP 8443 - Private - 192.168.50.25
  Add a description that records the application, reason, owner, and expected removal date if this is a temporary exception.
• Select Finish.

The new rule appears in Inbound Rules and is enabled by default. No restart is normally required for a firewall rule to take effect. If the application was already running, retest the connection rather than restarting Windows unnecessarily.

Confirm that the rule matches what you intended​

Creating a rule does not prove that the service is listening or reachable. Verify both the rule configuration and a real connection.

• In Inbound Rules, locate the rule by its name.
• Double-click the rule and review these tabs:
• General: confirm that Enabled is selected and the action is Allow the connection.
• Programs and Services: confirm the correct executable is listed, if you made a program-specific rule.
• Protocols and Ports: confirm TCP or UDP and the local port.
• Scope: confirm the approved remote addresses are listed and no broad address was added accidentally.
• Advanced: confirm only the intended Domain, Private, or Public profiles are selected.
• Ensure the target application or service is running and configured to listen on the same port used in the rule. The firewall cannot compensate for an incorrect app configuration, a stopped service, or an application bound only to localhost.
• From an allowed remote Windows computer, open PowerShell and run this TCP test, replacing the target address and port:
  Test-NetConnection -ComputerName 192.168.50.10 -Port 8443 -InformationLevel Detailed
  Check the TcpTestSucceeded result. A value of True indicates that the remote PC could establish a TCP connection to the target address and port. It does not verify the application’s login, protocol exchange, or permissions.
• If practical, repeat the test from a device whose address is not included in the rule. The connection should fail while the rule is active. This confirms that the IP restriction is working rather than merely proving the port is open.

For UDP, use the application’s own client or a vendor-provided test method. A generic TCP connectivity test does not validate a UDP listener.

Create the same rule with PowerShell​

PowerShell is useful when you need to document the configuration, deploy the same rule repeatedly, or avoid clicking through the wizard. Open Windows PowerShell as Administrator and adjust every placeholder before running this example:

New-NetFirewallRule `
  -DisplayName "ExampleServer TCP 8443 - Private - 192.168.50.25" `
  -Direction Inbound `
  -Action Allow `
  -Program "C:\Program Files\ExampleApp\ExampleServer.exe" `
  -Protocol TCP `
  -LocalPort 8443 `
  -RemoteAddress 192.168.50.25 `
  -Profile Private

The command creates one inbound allow rule that applies to the specified executable, TCP local port, remote address, and Private profile.

To inspect the rule after creation:

Get-NetFirewallRule -DisplayName "ExampleServer TCP 8443 - Private - 192.168.50.25"

Use a distinct display name for every custom rule. Avoid wildcard characters when disabling or removing rules, especially on a PC with several similarly named firewall entries.

Troubleshoot a rule that does not work​

The remote test still fails​

Work through the checks in this order:

• Confirm the service is running. A firewall allow rule does not create a server process or listener.
• Check the protocol. TCP and UDP are different. A TCP rule cannot permit UDP traffic, and vice versa.
• Check the local port. The port in the rule must match the port where the application listens on the target PC.
• Check the active profile. Run Get-NetConnectionProfile on the target PC. If the active category is Public but the rule applies only to Private, the rule is inactive.
• Check the source IP address. The source device may not have the address you expected, particularly when it uses a VPN, multiple adapters, or DHCP.
• Check the app binding. An application that accepts connections only from 127.0.0.1 or ::1 cannot be reached over the network even with a correct firewall rule.
• Check other network controls. A router, access point isolation feature, VPN policy, security suite, endpoint-management policy, or upstream firewall may block the traffic before it reaches Windows.

The rule works at home but not on another network​

The most likely cause is profile selection. The PC might classify the second network as Public. Do not solve this by automatically enabling the rule on Public. First decide whether the application genuinely needs to be reachable there. If it does, restrict the rule to the exact remote IP addresses that require access and test again.

The rule is visible but appears ignored​

On a work or school device, organization policy may control firewall behavior or prevent local firewall rules from being merged into the active policy. Check whether the firewall console indicates managed settings, then provide your administrator with the required program path, protocol, local port, remote addresses, and profiles. They can create the rule through the organization’s supported management system.

A broader rule is still exposing the port​

Firewall rules are evaluated as a policy set, not as a simple top-to-bottom list. If another enabled allow rule broadly permits the same application or port, your narrow rule does not remove that wider exposure. Search Inbound Rules for the application name and port, inspect related entries, and disable only rules you have confirmed are unnecessary.

Warning: Do not disable Windows Defender Firewall globally to diagnose a connectivity problem. Doing so removes protection for all inbound traffic on the affected profiles and makes it difficult to tell which specific rule was required.

Click to expand...

Disable or remove the rule when it is no longer needed​

For a temporary exception, disable the rule first and retest. This preserves its settings if you discover the access is still required.

• Open wf.msc as an administrator and select Inbound Rules.
• Locate your rule by its distinctive name.
• Right-click it and choose Disable Rule.
• Test the application from the remote device. If access is no longer required, right-click the rule again and select Delete.
• Confirm the deletion prompt.

To disable the PowerShell example without deleting it:

Disable-NetFirewallRule -DisplayName "ExampleServer TCP 8443 - Private - 192.168.50.25"

To permanently remove it:

Remove-NetFirewallRule -DisplayName "ExampleServer TCP 8443 - Private - 192.168.50.25"

If you are about to make several firewall changes, export the current firewall policy first from an elevated Command Prompt:

netsh advfirewall export "C:\FirewallBackup.wfw"

Use a protected local folder and retain the backup only as long as needed. It contains the firewall policy for the PC and should be treated as administrative configuration data.