Configure Windows Firewall on a Windows VPS

In short

Windows Firewall is the first control layer between your Windows VPS and unwanted network traffic. On a production server, leave the firewall enabled, review exposed inbound rules, allow only the ports your workload needs, and remove test rules after validation. This guide shows how to check firewall profiles, inspect RDP rules, create a safe test inbound rule, and clean it up on a Raff Windows Server VPS.

Quick verdict

Default rule: block inbound traffic unless you have a clear reason to allow it.

Why Windows Firewall matters on a VPS

A Windows VPS is reachable over the network. That makes firewall configuration part of the server’s security baseline.

Windows Firewall is a host-based firewall included with Windows. It controls inbound and outbound traffic on the machine itself. Microsoft documents Windows Firewall as enabled by default and designed to help filter network traffic by profile, rule, application, port, and other conditions.

For SMB workloads, firewall mistakes usually happen in one of two ways:

1. Too many inbound ports are opened “just in case.”
2. Important rules are changed without checking what already exists.

Both are avoidable.

A good Windows VPS firewall setup follows this rule:

Open only what the workload needs, keep RDP controlled, document every custom rule, and remove test rules after testing.

What we tested on Raff

We tested this walkthrough on a Raff Windows VPS running Windows Server 2025 Datacenter Evaluation.

Test environment:

On this VM, we verified:

• Windows Server version and hardware details
• Firewall profile status
• Existing RDP firewall rules
• Creation of a temporary inbound TCP rule
• Cleanup/removal of the temporary test rule

We did not expose a production application port in this test. The custom rule used TCP 54321 only as a temporary demonstration rule.

Step 1 - Check Windows Firewall profiles

Start by checking the firewall profiles.

Run PowerShell as Administrator:

powershellGet-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction

You should see the main profiles:

• Domain
• Private
• Public

In our Raff test, all three profiles were enabled.

If the Enabled column shows True, the firewall profile is active.

If DefaultInboundAction or DefaultOutboundAction shows NotConfigured, that means no explicit local default action is set in that policy view. Do not treat that as the firewall being disabled. Check the Enabled column first.

Step 2 - Review existing RDP firewall rules

Remote Desktop is the most important firewall rule group on many Windows VPS deployments.

Run:

powershellGet-NetFirewallRule -DisplayGroup "Remote Desktop" |
Select-Object DisplayName, Enabled, Direction, Action, Profile |
Format-Table -AutoSize

Review:

For production servers, RDP deserves special care. If possible, restrict RDP access to known IP addresses, a VPN, or a trusted administrative network. Do not leave broad public RDP exposure unless you have a deliberate operational reason and additional controls.

Step 3 - Create a safe temporary test rule

For this guide, we created a harmless demonstration rule for TCP port 54321.

This shows the syntax for creating a firewall rule without exposing a real production service like SQL Server or IIS.

Run:

powershellNew-NetFirewallRule -DisplayName "Raff Test Inbound Rule TCP 54321" -Direction Inbound -Protocol TCP -LocalPort 54321 -Action Allow -Profile Any

Then verify the rule:

powershellGet-NetFirewallRule -DisplayName "Raff Test Inbound Rule TCP 54321" |
Select-Object DisplayName, Enabled, Direction, Action, Profile

This command creates an inbound allow rule.

Important: opening a firewall port does not automatically mean an application is listening on that port. A service still needs to bind to the port before traffic can reach an application. The firewall rule only controls whether Windows allows the traffic through.

Step 4 - Remove the temporary test rule

Do not leave test rules behind.

Remove the rule:

powershellRemove-NetFirewallRule -DisplayName "Raff Test Inbound Rule TCP 54321"

Then verify cleanup:

powershellif (Get-NetFirewallRule -DisplayName "Raff Test Inbound Rule TCP 54321" -ErrorAction SilentlyContinue) {
    Write-Output "Test firewall rule still exists"
} else {
    Write-Output "Test firewall rule removed"
}

A clean firewall is easier to audit. Temporary rules should not survive the test session.

Step 5 - Use narrower rules for real workloads

For production, avoid broad rules when a narrower one works.

A broad rule looks like this:

powershellNew-NetFirewallRule -DisplayName "Allow App Port" -Direction Inbound -Protocol TCP -LocalPort 8080 -Action Allow -Profile Any

A better rule restricts the source IP:

powershellNew-NetFirewallRule `
  -DisplayName "Allow App Port 8080 from Office IP" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 8080 `
  -RemoteAddress 203.0.113.10 `
  -Action Allow `
  -Profile Any

Use source restrictions for admin ports, database ports, internal APIs, and management tools whenever possible.

Common ports and what to do with them

If a workload does not require an inbound port from the internet, do not open it.

Recommended firewall workflow

Use this workflow when changing Windows Firewall on a production VPS:

1. Identify the application and required port.
2. Confirm whether the service is actually listening.
3. Decide who needs access.
4. Create the narrowest possible allow rule.
5. Test from the expected client network.
6. Document the rule name, port, protocol, and reason.
7. Remove temporary or failed test rules.
8. Review custom rules monthly.

For example, if a SQL Server instance only needs access from your office IP, do not open TCP 1433 to the entire internet. Allow the office IP only.

Useful firewall commands

List all enabled inbound allow rules

powershellGet-NetFirewallRule |
Where-Object { $_.Enabled -eq "True" -and $_.Direction -eq "Inbound" -and $_.Action -eq "Allow" } |
Select-Object DisplayName, Profile, Direction, Action |
Format-Table -AutoSize

Find rules by name

powershellGet-NetFirewallRule | Where-Object DisplayName -like "*RDP*"

Disable a rule without deleting it

powershellDisable-NetFirewallRule -DisplayName "Rule Name"

Enable a disabled rule

powershellEnable-NetFirewallRule -DisplayName "Rule Name"

Remove a rule

powershellRemove-NetFirewallRule -DisplayName "Rule Name"

Check whether a port is listening

powershellGet-NetTCPConnection -State Listen | Select-Object LocalAddress, LocalPort, OwningProcess

This helps separate firewall problems from application problems. If no service is listening, opening the firewall is not enough.

Common mistakes

Opening ports before confirming the service needs them

Do not open ports because an installation guide mentioned them. Confirm the service, protocol, and source first.

Exposing SQL Server to the public internet

SQL Server should normally be restricted to trusted IPs, private networking, VPN, or application servers. Public TCP 1433 exposure increases risk.

Leaving temporary test rules behind

Temporary rules become permanent risk when nobody removes them. Use clear names like Raff Test..., then delete them after testing.

Changing RDP rules without a backup access path

If you lock yourself out of RDP, you may need dashboard or console recovery. Be careful when changing RDP rules on a remote VPS.

Assuming the firewall is the only security layer

Firewall rules are important, but they do not replace strong passwords, patching, least privilege, MFA where available, application hardening, and monitoring.

What Raff recommends

For production Windows VPS workloads, Raff recommends:

• Keep Windows Firewall enabled.
• Keep RDP rules under strict control.
• Restrict admin ports to trusted IPs where possible.
• Avoid exposing database and file-sharing ports publicly.
• Use HTTPS for public web workloads.
• Name custom rules clearly.
• Remove temporary rules after testing.
• Review firewall rules after every major software install.

The best firewall rule is the one you do not need to create. Start closed, then open only what the workload requires.

FAQ

Should I disable Windows Firewall on a VPS?

No. Keep it enabled. If something does not connect, fix the specific rule instead of turning the firewall off.

Why does my firewall profile show NotConfigured?

That value means a specific default action is not explicitly configured in that policy view. It does not mean the firewall is disabled. Check the Enabled column for each profile.

Is opening a port enough for an application to work?

No. The application must also be running and listening on that port. Use Get-NetTCPConnection -State Listen to check listening ports.

Should RDP be open to everyone?

Avoid that when possible. Restrict RDP to known IP addresses, VPN, or trusted admin networks if your workflow allows it.

Can I use the GUI instead of PowerShell?

Yes. Windows Defender Firewall with Advanced Security provides a GUI for creating and editing rules. PowerShell is faster for repeatable server administration.

Tested on

Tested on Raff Windows VPS, Windows Server 2025 Datacenter Evaluation, build 26100, 4 vCPU, approximately 8 GB RAM, 2026-05-24. We verified firewall profile status, existing Remote Desktop firewall rules, creation of a temporary inbound TCP rule, and removal of that test rule. Tester: [ENGINEER NAME].

What's next

• Windows Update Strategy on Production Servers - patch Windows Server safely with snapshots and maintenance windows
• Connect to a Raff Windows VPS via RDP - connect to your Windows Server from Windows, macOS, Linux, iOS, and Android
• Raff Windows Server Hub - browse Windows Server guides, compatibility notes, PowerShell commands, and version comparisons
• Raff Windows VPS - deploy a Windows Server VPS for business software, SQL Server, IIS, RDP, or admin workloads

Sources

• Microsoft Learn - Windows Firewall overview
• Microsoft Learn - Manage Windows Firewall with the command line
• Microsoft Learn - Get-NetFirewallProfile
• Microsoft Learn - New-NetFirewallRule
• Microsoft Learn - NetSecurity PowerShell module