Allow a Port in Windows Server 2016 Firewall

To allow port in firewall on Windows Server 2016, create a narrowly defined inbound rule for the service’s TCP or UDP port. This guide covers the graphical console and PowerShell, then verifies the rule from another computer in about ten minutes.

Prerequisites

• A VPS running Windows Server 2016 with the service or application you want to expose.
• An active RDP session and a local administrator account, or another account that can open an elevated PowerShell window.
• The exact port number and protocol: TCP and UDP are separate rules. The application must also be configured to listen on that port.
• The server’s network profile and the source addresses that should be allowed. Limiting the remote address is safer than exposing a management port to the entire internet.
• A Windows RDP server from VPSLake if you need a Windows Server environment for this task.

Step 1: Identify the port, protocol, and listener

The firewall only filters traffic; it cannot make an application accept connections, so check the service before changing network policy.

Open Windows PowerShell as an administrator and replace 8443 with the port used by your service:

$Port = 8443
Get-NetTCPConnection -LocalPort $Port -State Listen -ErrorAction SilentlyContinue
Get-NetUDPEndpoint -LocalPort $Port -ErrorAction SilentlyContinue

For a TCP service, a result with State set to Listen confirms that a process has opened the port. No result means you must start or reconfigure the application first. Use the UDP command for a UDP service; UDP has no TCP-style listening handshake.

Expected TCP output resembles this:

LocalAddress LocalPort RemoteAddress RemotePort State  OwningProcess
------------ --------- ------------- ---------- ------ -------------
0.0.0.0      8443      0.0.0.0       0          Listen 4120

Step 2: Check the active firewall profile

Windows applies rules according to the current network profile, so confirm the firewall is enabled without turning it off to troubleshoot.

Get-NetConnectionProfile | Select-Object Name,NetworkCategory
Get-NetFirewallProfile | Format-Table Name,Enabled,DefaultInboundAction

You should see a profile such as Public or Private, Enabled set to True, and normally DefaultInboundAction set to Block.

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

The displayed firewall profiles can all be enabled even though a network adapter is currently using only one category. Use the active category when you create the rule.

Step 3: Create the inbound rule with PowerShell

PowerShell makes the rule repeatable and gives it a clear name that you can audit or remove later.

The example below allows TCP port 8443 only on the server’s current network profile. Change the port, protocol, and rule name to match your application.

$Port = 8443
$Protocol = "TCP"
$RuleName = "Allow TCP 8443"
$Profile = Get-NetConnectionProfile | Select-Object -First 1 -ExpandProperty NetworkCategory
if ($Profile -eq "DomainAuthenticated") { $Profile = "Domain" }
New-NetFirewallRule -DisplayName $RuleName -Direction Inbound -Protocol $Protocol -LocalPort $Port -Action Allow -Profile $Profile

A successful command returns a rule object with Enabled : True, Direction : Inbound, Action : Allow, and the selected profile. For UDP, set $Protocol = "UDP" and confirm the application has a UDP endpoint before testing.

Microsoft’s New-NetFirewallRule documentation lists the available filters if you later need to restrict the rule to a program, address range, or service.

Step 4: Create the same rule in the firewall console

The graphical wizard is useful when you want to review every profile and scope setting 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. Select Port, choose TCP or UDP, and enter the local port. Use one port, a comma-separated list, or a range such as 8000-8010.
3. Select Allow the connection. Keep the rule limited to the required traffic; do not choose Allow the connection if it is secure unless you have configured IPsec.
4. Select only the profile that matches the result from Step 2. Do not select every profile merely because it is convenient.
5. Give the rule a specific name such as Allow TCP 8443, add a description with the application and owner, and select Finish.

The new entry should appear enabled in Inbound Rules. If a domain policy manages the server, the policy can override or replace local rules; make the change in the appropriate Group Policy when necessary. Microsoft explains the console workflow in its Windows Firewall rule configuration guide.

Verify the firewall rule and remote access

First confirm that Windows has the expected rule and port filter:

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

Expected output includes:

DisplayName : Allow TCP 8443
Enabled     : True
Direction   : Inbound
Action      : Allow
Profile     : Public
Protocol    : TCP
LocalPort   : 8443

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

Test-NetConnection -ComputerName SERVER_IP -Port 8443

The important result is TcpTestSucceeded : True. Run this test from outside the server; testing localhost only proves that the local machine can reach itself. For UDP, use the application’s client or protocol-specific test because Test-NetConnection checks TCP.

Troubleshooting

TcpTestSucceeded : False after adding the rule

The service may not be listening, the rule may use the wrong protocol or profile, or an upstream provider firewall may be blocking the port. Repeat Step 1, inspect the rule’s port filter, and check any VPS control-panel or network security-group rules outside Windows.

The rule does not appear in the PowerShell query

Get-NetFirewallRule -DisplayName requires an exact display name. List likely matches and check for a duplicate or different name:

Get-NetFirewallRule | Where-Object DisplayName -like "*8443*" | Format-Table DisplayName,Enabled,Direction,Action,Profile

Use the exact returned name in later commands, or create one clearly named rule and remove an obsolete duplicate.

It works on Private but not Public networks

The rule is probably scoped to the wrong profile. Check Get-NetConnectionProfile, then edit the rule in Inbound Rules → Properties → Advanced → Profiles, or apply the active profile with:

Set-NetFirewallRule -DisplayName "Allow TCP 8443" -Profile Public

Change Public only when it matches the server’s current network category. If you need the service available after profile changes, deliberately select the required profiles and understand the wider exposure.

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 user cannot create local firewall rules without administrator rights or delegated permissions.

Hardening

• Limit Remote IP address in the rule properties when only a known office, monitoring host, or application tier needs access.
• Prefer a program-specific rule when the port belongs to one executable, rather than allowing every program to receive that traffic.
• Record the reason and owner in the rule description, then remove temporary rules after the migration or test is complete.
• Keep Windows Firewall enabled on every profile and manage provider-level firewall rules separately from the guest operating system.

FAQ

Does opening a firewall port start the application?

No. The firewall rule only permits matching packets to reach Windows. The application must be installed, running, bound to the correct local address, and configured to use the same TCP or UDP port.

Should I choose TCP or UDP?

Choose the protocol specified by the application’s documentation. TCP and UDP are different transport protocols, so allowing TCP 8443 does not allow UDP 8443; create separate rules only when the service genuinely uses both.

Do I need an outbound rule too?

Usually not for a default Windows Server configuration, because outbound traffic is normally allowed unless a blocking rule or policy exists. Add an outbound allow rule only when your server has a restrictive outbound policy and the application requires it.

How do I close the port later?

Disable the rule first if you may need it again, or remove it when it is no longer required:

Remove-NetFirewallRule -DisplayName "Allow TCP 8443"

Confirm the display name before removal so you do not delete a different application’s rule.