Allow a Port in Windows Server 2025 Firewall

To allow port in firewall on Windows Server 2025, create a focused inbound rule for the service’s protocol and port, then test it from another device. The PowerShell method takes about ten minutes, and the same settings are available in the graphical firewall console.

Prerequisites

• A VPS running Windows Server 2025 with the application or service installed and configured to use a known TCP or UDP port.
• An RDP session with a local administrator account, or another account that can open PowerShell as administrator.
• The port number, transport protocol, active Windows network profile, and the remote IP addresses that should be allowed.
• The server’s public IP address or DNS name and a separate computer for an external connection test.
• If you need a Windows environment for this procedure, see VPSLake Windows RDP hosting.

Step 1: Confirm that the application is listening

The firewall can permit packets, but it cannot start a stopped service or correct an application bound to the wrong address.

Open Windows PowerShell with Run as administrator. Replace 8443 with the port used by your application:

$Port = 8443
Get-NetTCPConnection -LocalPort $Port -State Listen -ErrorAction SilentlyContinue | Format-Table LocalAddress,LocalPort,OwningProcess,State
Get-NetUDPEndpoint -LocalPort $Port -ErrorAction SilentlyContinue | Format-Table LocalAddress,LocalPort,OwningProcess

A TCP service should return a row whose state is Listen. A UDP service should return an endpoint; UDP has no TCP-style listening state.

LocalAddress LocalPort OwningProcess State
------------ --------- ------------- -----
0.0.0.0           8443          4120 Listen

If both commands return nothing, start the service or change its configuration before editing the firewall. A listener on 127.0.0.1 is also not reachable from other machines until the application is configured to bind to the required server interface.

Step 2: Identify the active firewall profile

Windows evaluates a rule against the profile used by the connected network adapter, so matching the profile prevents a rule that works only on the wrong network category.

Get-NetConnectionProfile | Format-Table InterfaceAlias,Name,NetworkCategory,IPv4Connectivity
Get-NetFirewallProfile | Format-Table Name,Enabled,DefaultInboundAction,DefaultOutboundAction

For an internet-facing VPS, the connected adapter is often Public, but use the value returned on your server. The firewall should be enabled and inbound traffic should normally default to Block:

Name    Enabled DefaultInboundAction DefaultOutboundAction
----    ------- -------------------- ---------------------
Domain     True                 Block                  Allow
Private    True                 Block                  Allow
Public     True                 Block                  Allow

If NetworkCategory is DomainAuthenticated, use Domain as the rule’s profile in the next step. Do not turn off Windows Defender Firewall as a workaround; that removes filtering for every service on the server.

Step 3: Create the inbound rule in PowerShell

PowerShell gives the exception a repeatable name and lets you review or remove it later without guessing which rule was changed.

The following example allows TCP port 8443 on the Public profile. Change $Port, $Protocol, $Profile, and $RuleName to match your service and the result from Step 2:

$Port = 8443
$Protocol = "TCP"
$Profile = "Public"
$RuleName = "Allow TCP 8443 - Application"

New-NetFirewallRule -DisplayName $RuleName -Direction Inbound -Protocol $Protocol -LocalPort $Port -Action Allow -Profile $Profile -RemoteAddress Any -Description "Inbound access for the application on $Protocol port $Port"

The command should return an enabled inbound allow rule:

DisplayName                  Enabled Direction Action Profile
-----------                  ------- --------- ------ -------
Allow TCP 8443 - Application True    Inbound   Allow  Public

For a UDP service, set $Protocol = "UDP"; allowing TCP does not allow UDP on the same port. If the service is for an office, monitoring host, or private application tier, replace Any with the approved IP address or CIDR range, such as 203.0.113.25 or 203.0.113.0/24.

Microsoft’s New-NetFirewallRule documentation lists the available filters, including program, service, interface, and remote-address restrictions.

Step 4: Add the same exception in the graphical console

The firewall console is useful when you want to review the rule’s profile and connection scope before saving it.

Open Server Manager → Tools → Windows Defender Firewall with Advanced Security. Alternatively, press Windows key + R, enter wf.msc, and select OK.

1. Select Inbound Rules, then choose New Rule… in the Actions pane.
2. Select Port, choose TCP or UDP, and enter the local port. Use a single port unless the same application genuinely needs a list or range.
3. Select Allow the connection. Leave Allow the connection if it is secure for environments where IPsec has been configured deliberately.
4. On Profile, select the active profile from Step 2. Select additional profiles only if the service must remain reachable after the network category changes.
5. On Scope, limit Remote IP address when the service is not intended for the whole internet.
6. Enter a name such as Allow TCP 8443 - Application, add the purpose and owner in Description, and select Finish.

The rule should now appear as enabled under Inbound Rules. If Group Policy manages the server’s firewall, a domain administrator may need to make the change in the controlling policy instead of relying on a local rule. Microsoft’s Windows Firewall configuration guide covers the policy and console model.

Verify the firewall rule and remote access

First confirm that Windows saved the intended rule and port filter:

$RuleName = "Allow TCP 8443 - Application"
Get-NetFirewallRule -DisplayName $RuleName | Format-List DisplayName,Enabled,Direction,Action,Profile
Get-NetFirewallRule -DisplayName $RuleName | Get-NetFirewallPortFilter | Format-List Protocol,LocalPort

Look for Enabled : True, Direction : Inbound, Action : Allow, the expected profile, Protocol : TCP, and LocalPort : 8443.

From a different computer, test the public address. Replace SERVER_IP with the server’s IP address or DNS name:

Test-NetConnection -ComputerName SERVER_IP -Port 8443

The important result is:

ComputerName     : SERVER_IP
RemotePort       : 8443
TcpTestSucceeded : True

This test proves that a TCP connection can cross the network path and reach the port. For UDP, use the application’s client or a protocol-specific probe because Test-NetConnection checks TCP, not UDP. Testing localhost on the server does not prove that an outside client can connect.

Troubleshooting

TcpTestSucceeded : False

The service may not be listening, the rule may use the wrong protocol or profile, or a provider-level firewall may block the port before traffic reaches Windows. Recheck Step 1, inspect the rule’s port filter, and review any VPS control-panel or upstream security-group rules.

The rule exists, but Windows still blocks the connection

Look for a profile mismatch, a remote-address restriction, or a more specific block rule. These commands show the active category and enabled inbound rules that mention the example port:

Get-NetConnectionProfile | Format-Table InterfaceAlias,NetworkCategory
Get-NetFirewallRule -Direction Inbound -Enabled True | Where-Object DisplayName -like "*8443*" | Format-Table DisplayName,Profile,Action

If the rule is Public but the adapter is Private, edit Inbound Rules → rule Properties → Advanced → Profiles, or recreate the rule with the active profile.

PowerShell returns Access is denied

The firewall cmdlets require elevation. Close the current window, search for PowerShell, select Run as administrator, and run the command again. A standard RDP account cannot create local firewall rules without administrator rights or delegated permissions.

The port works on the server but not from the internet

A local test can bypass the real route and external filtering. Confirm that the application listens on the server’s reachable address, test from another network, and check the provider’s perimeter firewall, NAT, load balancer, or security group.

Hardening

• Allow only the protocol and port the application requires; TCP and UDP need separate rules.
• Restrict Remote IP address to trusted sources for administration, databases, dashboards, and internal APIs.
• Keep a descriptive rule name and description so another administrator can identify its owner and purpose.
• Disable a temporary exception during testing or remove it when the service is retired:

Remove-NetFirewallRule -DisplayName "Allow TCP 8443 - Application"

Confirm the display name before removing a rule on a production server.

FAQ

Does opening a port start the Windows service?

No. A firewall rule only controls whether matching packets may pass. The service must be installed, running, bound to the correct local address, and configured for the same protocol and port.

Should I select Domain, Private, and Public profiles?

Usually not. Select the profile used by the server’s connected adapter and add others only when the application must remain reachable after a deliberate profile change. Selecting all three can expose the service on a network where it was not intended to run.

Do I need an outbound rule for the same port?

Normally no: Windows Server commonly allows outbound traffic by default. Create an outbound rule only when a restrictive local policy or Group Policy blocks outbound connections needed by the application.

How can I allow several ports?

You can enter a comma-separated list or range when the ports share the same protocol, profile, and security scope. Separate rules are easier to audit when different services need different source restrictions.