Allow a Port in Windows Server 2019 Firewall

To allow port in firewall on Windows Server 2019, add a narrowly scoped inbound rule for the service’s TCP or UDP port. You can do it with PowerShell or the graphical console, then confirm the application is reachable from another computer in about ten minutes.

Prerequisites

• A VPS running Windows Server 2019 with the application or service already installed.
• An active RDP session and a local administrator account, or an account permitted to open an elevated PowerShell window.
• The exact local port, transport protocol, and network profile required by the application. TCP and UDP are separate rules.
• The server’s public IP address or DNS name, plus a second computer from which you can test the connection.
• If you need a Windows environment for this guide, see VPSLake Windows RDP hosting.

Step 1: Confirm the service and port

The firewall only filters traffic; it cannot make a stopped service listen, so check the application before changing the firewall.

Open Windows PowerShell as an administrator. Replace 8443 with the port your application uses:

$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

For TCP, a row with State set to Listen means a process has bound the port. For UDP, the endpoint command should return a row; UDP does not have a TCP-style listening state.

Example TCP output:

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

No result usually means the application is stopped, bound to another port, or listening only on a different address. Fix that service-side issue before testing the firewall.

Step 2: Check the active firewall profile

Windows applies a rule only when its profile matches the network category, so identify the active category before creating the exception.

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

On an internet-facing VPS, the active category is commonly Public. The firewall should be enabled and the default inbound action should normally be Block:

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

Use the category shown for the server’s connected interface in the next step. Do not disable Windows Defender Firewall to make a connection test pass; that removes protection for every service.

Step 3: Add a specific inbound rule with PowerShell

PowerShell creates an auditable rule with a predictable name, which makes later verification and removal safer.

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

$Port = 8443
$Protocol = "TCP"
$RuleName = "Allow TCP 8443 - Application"
$Profile = "Public"
New-NetFirewallRule -DisplayName $RuleName -Direction Inbound -Protocol $Protocol -LocalPort $Port -Action Allow -Profile $Profile -RemoteAddress Any | Select-Object DisplayName,Enabled,Direction,Action,Profile

Expected output includes 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". If only a known office, monitoring host, or application server should connect, replace Any with its IP address or CIDR range, such as 203.0.113.25 or 203.0.113.0/24. A restricted source scope is safer for administration and internal services.

The Microsoft New-NetFirewallRule reference documents additional filters for programs, services, interfaces, and remote addresses.

Step 4: Add the rule through the firewall console

The GUI wizard is useful when you want to review the protocol, profiles, and connection scope before saving the rule.

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

1. Select Inbound Rules in the left pane, then select New Rule… in the Actions pane.
2. Choose Port, select TCP or UDP, and enter the local port. A single port, comma-separated ports, or a range such as 8000-8010 is accepted.
3. Select Allow the connection. Do not choose Allow the connection if it is secure unless you have separately configured IPsec.
4. On Profile, select only the category identified in Step 2. Selecting every profile broadens the rule when the server changes networks.
5. On Scope, restrict Remote IP address when the service does not need to accept connections from the entire internet.
6. Enter a descriptive name such as Allow TCP 8443 - Application, add the service owner or purpose in the description, and select Finish.

The rule should appear enabled under Inbound Rules. Windows Server 2019 can also receive firewall policy from Active Directory; if a domain policy controls this server, make the change in the managed policy rather than relying only on a local rule. See Microsoft’s Windows Firewall configuration guide for policy and console details.

Verify the firewall rule and remote connection

First inspect the saved rule and its port filter on the server. Use the same display name you created above:

$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

You should see Enabled : True, Direction : Inbound, Action : Allow, the intended profile, and LocalPort : 8443.

From a different computer—not from the server itself—replace SERVER_IP with the public address or DNS name:

Test-NetConnection -ComputerName SERVER_IP -Port 8443

The key result is:

ComputerName     : SERVER_IP
RemotePort       : 8443
TcpTestSucceeded : True

If the application speaks HTTP, you can also test it from a browser or with curl.exe. A successful TCP test proves the path and firewall rule work; the application still needs to return a valid protocol response.

Troubleshooting

TcpTestSucceeded : False

The application may not be listening, the rule may use the wrong protocol or profile, or an upstream provider firewall may be blocking the port. Repeat Steps 1 and 2, inspect the exact rule, and check any VPS control-panel or network security-group firewall outside Windows.

The rule exists but the port is still unreachable

Check for a more specific block rule, the server’s active profile, and the remote-address scope. These commands show matching rules and the current profile:

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 scoped to Public but the connection uses Private, edit it under Inbound Rules → rule Properties → Advanced → Profiles, or recreate it for the profile the server actually uses.

PowerShell reports Access is denied

Firewall changes 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.

It works locally but not from the internet

Testing localhost or the server’s own IP can bypass part of the real network path. Confirm the service is bound to the correct interface, test from an outside network, and verify that the VPS provider’s perimeter firewall and any router or load balancer also allow the port.

Hardening

• Allow only the protocol and port the application needs; TCP and UDP require separate rules.
• Limit Remote IP address to trusted sources whenever a public service is not required.
• Prefer a program-specific rule for a single executable, and record the owner and purpose in the rule description.
• Disable a temporary rule during testing or remove it after the service is retired:

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

Confirm the display name before removing anything, especially on a server with several similar rules.

FAQ

Does an inbound firewall rule start a Windows service?

No. The rule only permits matching packets through Windows Defender Firewall. The service must be installed, running, bound to the intended local address, and configured to use the same port and protocol.

Should I allow a port on every firewall profile?

Usually no. Select the profile used by the server’s active network connection, and add other profiles only when you deliberately need the service available after a profile change. Selecting all profiles can expose the service on networks where it was not intended to run.

Do I need an outbound rule for the same port?

Not with the normal Windows Server policy, which permits outbound traffic by default. Create an outbound rule only if your server or domain policy blocks outbound connections and the application needs an exception.

How do I allow several ports safely?

Create separate rules when the ports belong to different services or need different source restrictions. A single rule can contain a comma-separated list or a range, but individual rules make auditing and later removal clearer.