Your VPS comes with a managed firewall

Every VPSDime Linux VPS sits behind a small, managed firewall that we run at our network edge. You do not have to install anything or set it up. It is on by default, it has no effect on the standard services people run on a VPS (SSH, websites, mail, DNS, game servers, VPN, etc.), and it gives you a simple interface in your client area to control who can reach the handful of services that it does guard.

This article explains what it is for, what it covers, and how to use it.

Why it exists

Most of the VPSs we see compromised were not broken into through SSH or a web app. They were taken over because an application port was accidentally exposed to the entire internet: a database with a default password, a Redis instance without auth, a Docker API reachable on tcp/2375, an admin panel bound to 0.0.0.0. These are the favourite entry points for scanners and bots, and the damage is usually silent until the VPS starts being used for spam, mining or as a pivot.

The managed firewall closes those doors at the network level, before the traffic even reaches your VPS, so a misconfiguration cannot turn into a compromise overnight.

What it blocks, what it doesn't

The firewall only touches a short, deliberate list of ports that correspond to high-risk application services. Everything else is untouched, including SSH (port 22), HTTP/HTTPS (80/443), any custom application port, game server, VPN tunnel and so on.

The current list:

If your workload doesn't use any of these, you don't have to do anything; the firewall is already doing the right thing for you. If it does, read on.

Opening access when you need it

The firewall section on your VPS management page gives you two controls. Pick whichever fits the situation:

• Per-Application Whitelist. Attach a list of allowed sources to a specific application. For example, list your office IPs under PostgreSQL to let your team connect to the database while keeping everyone else out. Each app has its own list; sources you don't add stay blocked for that app.
• Global Whitelist. A single list of trusted sources that bypass every per-app block on that VPS. Handy when the same IP (your laptop, a bastion, a monitoring server) needs to reach several of the protected services and you would rather not repeat it in every per-app list.

One small quality-of-life detail: your other VPSDime VPSs can already reach this one without restriction. We whitelist inter-VPS traffic automatically, so you don't need to list your own IP addresses here.

Each list accepts up to 64 entries, one per line, in any of the following formats:

Single IPv4:   203.0.113.5
IPv4 subnet:   203.0.113.0/24       (up to /16)
Single IPv6:   2001:db8::1
IPv6 subnet:   2001:db8::/64        (up to /48)

Catch-all entries (0.0.0.0/0, ::/0) are not allowed. Saves apply instantly; you do not need to reboot or reconnect anything.

Turning the firewall off, and back on

Some customers would rather manage all network filtering on the VPS itself. That is supported. On the same page you will find Turn off firewall protection and Turn on firewall protection buttons. Turning it off removes our blocks for that VPS: every port in the list above becomes directly reachable from the public internet, and from then on whatever you have configured inside the VPS (iptables/nftables/ufw/firewalld, bind addresses, authentication) is the only thing between those services and the world. Your whitelists are not deleted; they stay put and become active again the moment you turn the firewall back on.

Our recommendation is to keep it on unless you have a concrete reason not to.

Troubleshooting

If a client cannot reach a service that ought to be open:

1. Make sure the service is actually listening. From inside the VPS: ss -tulnp | grep :<port> (or netstat -anp | grep :<port> on older systems). You want a LISTEN line on a public interface; a service bound to 127.0.0.1 will never be reachable from outside, whitelist or not.
2. Check for local firewalls on the VPS (iptables/nftables/ufw/firewalld) that might also be dropping the traffic.
3. If the port is in the managed list above, make sure the source IP is on either the Per-Application Whitelist for that app or the Global Whitelist.

A few habits that make this work

• Prefer 127.0.0.1 bindings for services that only the local VPS needs. Nothing outside can reach them regardless of firewall state.
• Use strong, unique credentials for anything that has to be reachable.
• Treat our firewall as a safety net. A well-configured VPS with the firewall on gets you two independent layers of protection, which is the point.