How to Open a Port on Windows Server 2012

To open a port on Windows Server 2012, create an inbound Windows Firewall rule for the service’s exact protocol and port. You can finish the change in about ten minutes, then prove it works from another computer without weakening the rest of the server’s firewall.

Prerequisites

• A VPS running Windows Server 2012, not Windows Server 2012 R2, with the application installed and configured to use a known port.
• An RDP session with a local administrator account, or another account that can open an elevated Windows PowerShell window.
• The port number and protocol required by the application. TCP and UDP are different rules, even when they use the same number.
• The server’s public IP address or DNS name and a separate computer or network for the remote test.
• If you need a Windows server for this procedure, see VPSLake Windows RDP hosting.

Step 1: Confirm the application is listening

Windows Firewall only filters packets; it does not start an application or make a service listen on a port.

Open Windows PowerShell, right-click it, select Run as administrator, and replace 8443 with your application’s port:

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

A TCP service should return a row with State set to Listen. A UDP service should return an endpoint; UDP does not report a TCP-style listening state.

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

No output usually means the service is stopped, configured for another port, or bound only to 127.0.0.1. Fix the application first. A firewall exception cannot make a loopback-only service reachable from the internet.

Step 2: Identify the active firewall profile

Windows applies firewall rules by network profile, so check the connected adapter before assigning a profile to the new rule.

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

On a VPS, the active network is commonly Public, but use the value shown by 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 the network category is DomainAuthenticated, use Domain as the rule profile. Do not disable Windows Firewall to troubleshoot a failed connection; that exposes every other service whose access is not otherwise restricted.

Step 3: Create the inbound rule with PowerShell

The NetSecurity cmdlet creates a named rule that you can inspect, narrow, disable, or remove later.

The block below detects the active profile, converts DomainAuthenticated to the firewall profile name Domain, and allows TCP port 8443. Change the port and rule name to match the application:

$Port = 8443
$Protocol = 'TCP'
$RuleName = 'Allow TCP 8443 - Application'
$Profile = Get-NetConnectionProfile | Select-Object -First 1 -ExpandProperty NetworkCategory
if ($Profile -eq 'DomainAuthenticated') { $Profile = 'Domain' }

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

The result should describe an enabled inbound allow rule. For UDP, change $Protocol to 'UDP' and make sure the application actually uses UDP. If only known clients need access, replace Any with a trusted address or range such as 203.0.113.25 or 203.0.113.0/24.

Microsoft’s New-NetFirewallRule reference documents the filters available in this cmdlet.

Step 4: Add the rule in the graphical console

The GUI is useful when you want to review the protocol, profile, and remote address scope before saving the exception.

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

1. Select Inbound Rules, then select New Rule… in the Actions pane.
2. Choose Port, select TCP or UDP, and enter the value in Specific local ports.
3. Select Allow the connection. Do not select Allow the connection if it is secure unless you have deliberately configured IPsec.
4. Select the active profile from Step 2. Select additional profiles only when the service must remain reachable after a deliberate network-category change.
5. On Scope, limit Remote IP address when the application is intended for an office, monitoring host, or private application tier rather than the whole internet.
6. Give the rule a precise name such as Allow TCP 8443 - Application, add its purpose and owner in the description, and select Finish.

The rule should appear enabled under Inbound Rules. If a domain policy manages the server, a local rule may be overridden; make the change in the controlling Group Policy when required. Microsoft’s Windows Server 2012 inbound port-rule procedure) explains the same wizard choices.

Verify the open port

First confirm that Windows saved the expected rule and that a local listener still exists:

$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
Get-NetTCPConnection -LocalPort 8443 -State Listen | Format-Table LocalAddress,LocalPort,State,OwningProcess

You should see Enabled : True, Direction : Inbound, Action : Allow, the expected profile, Protocol : TCP, LocalPort : 8443, and a listener:

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

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

Test-NetConnection -ComputerName SERVER_IP -Port 8443

The important result is:

ComputerName     : SERVER_IP
RemotePort       : 8443
TcpTestSucceeded : True

Run this check from outside the server. A successful localhost test proves only that the local machine can reach itself; it does not test DNS, routing, a provider firewall, or the public interface. For UDP, use the application’s client or another UDP-specific test because Test-NetConnection checks TCP.

Troubleshooting

TcpTestSucceeded : False

The service may not be listening, the rule may use the wrong protocol or profile, or an upstream firewall may drop the connection before it reaches Windows. Repeat Steps 1 and 2, inspect the rule’s port filter, and check any VPS control-panel or provider-level firewall outside the operating system.

The port works locally but not from the internet

The application may be bound to 127.0.0.1, the DNS record may point to another address, or an external NAT or security rule may be missing. Check LocalAddress, test the public IP directly, and confirm the provider is forwarding the requested port to this VPS.

The rule exists but traffic is still blocked

Check that the rule’s profile matches Get-NetConnectionProfile and that its remote-address scope includes the client. A more specific block rule or domain Group Policy can also take precedence; inspect the effective policy in Windows Firewall with Advanced Security.

PowerShell returns “Access is denied”

The firewall cmdlets require elevation. Close the window, search for PowerShell, select Run as administrator, and run the commands again with a local administrator account or delegated permissions.

Hardening

• Open only the protocol the application requires. A TCP rule does not permit UDP on the same port.
• Limit Remote IP address for databases, admin panels, dashboards, and internal APIs that do not need public access.
• Keep the rule description specific enough for another administrator to identify the application, owner, and purpose.
• Windows Server 2012 reached the end of regular support on October 10, 2023. Plan a move to a supported Windows Server release or use the vendor’s current Extended Security Updates guidance before exposing new services publicly.
• Remove a temporary rule after testing:

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

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

FAQ

Does opening a port start the Windows service?

No. The firewall rule only permits matching packets through Windows. The application must be installed, running, bound to a reachable address, and configured for the same protocol and port.

Should I open TCP, UDP, or both?

Use the protocol specified by the application’s documentation. TCP and UDP are separate transport protocols, so create a second rule only when the service genuinely requires both.

Why does the firewall rule work on one network profile but not another?

Each rule is assigned to Domain, Private, Public, or a combination of profiles. If the connected adapter changes category, the rule may stop applying; check Get-NetConnectionProfile and update the rule deliberately instead of enabling every profile by default.

Can I test a UDP port with Test-NetConnection?

No. Test-NetConnection -Port performs a TCP test. Use the application’s normal UDP client or a protocol-aware diagnostic tool, and verify the UDP endpoint with Get-NetUDPEndpoint on the server.