On a By-Hoster VPS there is no network firewall in front of your machine: filtering happens entirely inside Windows. Whatever you allow in Windows Defender Firewall becomes reachable from the Internet, and whatever you deny is blocked. That is simple, and it comes without a safety net: an over-broad rule exposes a service to the whole world.
What is the golden rule before touching the firewall?
Never delete or disable the rule that allows Remote Desktop (port 3389) until you have another way in. If you cut RDP off, the only remaining door is the rescue console in the client area. Know where it is before touching the firewall.
How do I open an inbound port on my Windows VPS?
In Windows Defender Firewall with Advanced Security (wf.msc), create a new inbound rule of the Port type and allow the connection.
- Open the Start menu and launch Windows Defender Firewall with Advanced Security (
wf.msc). - In the left column, select Inbound Rules.
- On the right, click New Rule….
- Choose Port, then Next.
- Select TCP or UDP depending on your application, enter the port number (for example
443) and confirm. - Choose Allow the connection.
- Tick the relevant profiles. On a server the active profile is usually Public: leave it ticked.
- Give the rule a meaningful name such as
HTTPS - public website, and finish.
A rule without a clear name is unreadable six months later. Describe the service, not the port.
How do I restrict a port to my own IP addresses?
In the rule properties, Scope tab, Remote IP address section: choose These IP addresses and add your own.
Opening an administration port to the whole Internet is the surest way to collect thousands of attempts a day. For a database, an admin panel or any service not meant for the public:
- Open the properties of the rule you created.
- Go to the Scope tab, Remote IP address section.
- Choose These IP addresses and add your public address or your office range.
- Confirm.
If your connection has no fixed address, this restriction will need updating when it changes: a small nuisance, largely repaid by the drop in noise.
How do I check that a port really answers?
Check what is listening with Get-NetTCPConnection, the rule with Get-NetFirewallRule, then access from the outside with Test-NetConnection.
Three checks, in this order, separate a firewall problem from an application problem.
On the server, in PowerShell, confirm something is listening:
Get-NetTCPConnection -State Listen | Select-Object LocalAddress, LocalPortIf your port is absent, the application is not running and the firewall is not to blame.
Still on the server, list your active rules:
Get-NetFirewallRule -Enabled True -Direction Inbound | Select-Object DisplayName, ActionFrom your own machine, test access from outside:
Test-NetConnection -ComputerName IP_ADDRESS -Port 443A TcpTestSucceeded : True confirms the port is reachable end to end.
What are the most common firewall mistakes?
Five classics: opening an outbound port instead of an inbound one, mixing up TCP and UDP, forgetting the network profile, turning the firewall off "just to test", and exposing an unpatched application.
- Opening an outbound port instead of an inbound one. Outbound traffic is allowed by default; inbound rules are what make a service reachable.
- Mixing up TCP and UDP. A service listening on UDP will never answer a TCP rule.
- Forgetting the network profile. A rule applied only to the Domain profile has no effect on a standalone server.
- Turning the firewall off "just to test". If the test succeeds you have left a bare machine on the Internet, and it is easily forgotten. Add a temporary rule, test, then delete it.
- Publishing an unpatched application. The firewall does not protect you from a flaw in the service you have just exposed.
What should I do once the ports are open?
Write down what you opened and why. Delete rules that are no longer needed: a forgotten rule is a forgotten door. The Graphs tab in the client area helps you spot unusual traffic after opening a port.