8 min read

Our verdict

Kamatera Cloud VPS

Best for: Kamatera's cloud firewall is straightforward once you know two things: rules do nothing until you press Update Firewall at the bottom of the page, and you should build IP sets before rules rather than retyping addresses. Run it alongside UFW on the host, not instead of it.

Overall score

8.1/ 10

What we liked

Filtering happens before traffic reaches the machine, so a flood never costs you CPU
A locked-out server is still reachable through the console's hypervisor terminal, so a bad rule is recoverable
IP sets let you name a group of addresses once and reference it from every rule
No extra charge — it comes with the server

What to watch

Rules are not saved as you type: miss the Update Firewall button and everything you just entered is discarded silently
The rule editor gives no feedback about which rule matched, so debugging is guesswork compared with reading iptables logs
There is no per-rule logging or hit counter
Changes apply to the server rather than to a reusable policy you can attach to a group of machines

PriceIncluded with every Kamatera server

Start the 30-day trial →Affiliate link — we may earn a commission.

How to configure the Kamatera cloud firewall

Stop traffic at the network edge instead of on the server. IP sets, rule order, the button people miss, and how to test the rules from outside.

By Adam Ferris · Cloud & Infrastructure Writer

8 November 2026

How we pay for this

We buy the hardware and pay for the subscriptions we write about. Claim a deal through our link and we may earn a commission — our readers sometimes get a discount or a freebie out of it too, but it never pushes the price up, and it never changes what the review says.

Kamatera's cloud firewall filters traffic before it reaches your server, which is the difference between a port scan costing you nothing and a port scan costing you CPU. It takes about ten minutes to set up properly, and there is exactly one trap in the interface that catches almost everybody.

The trap first, because it is the reason people think the firewall does not work: nothing you type is saved until you press Update Firewall at the bottom of the page. The button is below the rule list, off-screen on a laptop once you have a few rules. Add three rules, navigate away, and all three are gone with no warning. Check for it every single time.

Why bother, when the server has UFW

Two firewalls at different layers is not redundancy, it is defence in depth, and each one covers a failure in the other.

The edge firewall drops traffic before the machine sees it. A scan or a flood never touches your network stack, so it costs no CPU and generates no log noise. On a 1 GB server, that matters more than it sounds.
The host firewall survives a console mistake. If you fumble an edge rule and briefly open everything, UFW is still standing. The reverse is also true — a bad UFW rule that would otherwise lock you out does not change what the edge is dropping.
Only the host firewall knows about processes. Rules tied to a specific service, or rate limits on a particular daemon, belong on the machine.

The honest limitation of Kamatera's edge firewall compared to the equivalent on larger clouds: there is no per-rule logging and no hit counter, so when something is blocked that should not be, you are reasoning about it rather than reading it. The balancing point is that it is free and it attaches to the server without you having to model a security group, a network ACL and a route table first.

Start with IP sets, not rules

An IP set is a named group of addresses you define once and then reference from any number of rules. Building these first saves retyping and, more usefully, means changing your home IP is one edit rather than six.

In the console, open your server, then the Firewall tab, then IP Sets. Two are worth creating before you write a single rule:

admin — the addresses you administer from. Your office, your home, your VPN exit. Find your current one with curl ifconfig.me. If your home connection has a dynamic address, use a /24 of your ISP's range or put a VPN in front of it rather than widening the rule to the world.
internal — the private addresses of your other Kamatera servers, if you run more than one. This is what lets a web node reach a database without the database being on the public internet at all.

The rules a public server needs

Firewall rules are read in order, first match wins, and the last rule should be a deny-all. Work from most specific to least.

SSH, from the admin set only. TCP 22, source admin, allow. This single rule removes the overwhelming majority of noise a public server attracts — the automated password-guessing traffic simply never arrives.
HTTP and HTTPS, from anywhere. TCP 80 and 443, source any, allow. Port 80 stays open even on an HTTPS-only site because Let's Encrypt's HTTP challenge needs it and a redirect needs somewhere to happen.
Anything application-specific, scoped tightly. A database port goes to the internal set and nowhere else. A monitoring agent's port goes to the monitoring provider's published addresses. If you cannot name who should reach a port, it should not be open.
ICMP echo, from anywhere. Optional, and worth allowing — blocking ping breaks path-MTU discovery and makes diagnosing a network problem considerably harder for the sake of hiding a server that is already answering on 443.
Deny everything else. The final rule. Without it the preceding rules are suggestions.

Then scroll down and press Update Firewall. Yes, again.

The host firewall, in four commands

On Ubuntu, UFW mirrors the shape above:

ufw allow from YOUR.ADMIN.IP to any port 22 proto tcp
ufw allow 80,443/tcp
ufw default deny incoming
ufw enable

Run them in that order. Enabling UFW before the SSH rule exists disconnects you from your own machine — recoverable through the console terminal, but an avoidable ten minutes. Our setup guide covers the rest of the hardening this belongs with.

Testing from somewhere that is not your desk

A firewall tested from an allowed address tells you nothing. You need a view from outside the allow list:

Check what is actually open. From a different network — a phone on mobile data is ideal — run nmap -Pn your.server.ip. You should see 80 and 443 and nothing else. If 22 answers, your admin rule is not scoped the way you think.
Read the failure mode. A connection that is refused means the packet reached the machine and nothing was listening. A connection that times out means a firewall dropped it. That distinction tells you which of the two firewalls to go and look at.
Confirm the site still loads. Obvious, and the step people skip. Check HTTPS from the outside network too, not just the IP.

When it goes wrong

You cannot SSH in any more. Use the console's browser terminal, which connects through the hypervisor rather than the network and works with every port closed. Fix the rule, then test again before closing it.
The rules look right but behave as though they are not there. They were not saved. Reopen the firewall tab and see whether your rules are actually listed — if they are not, you missed the update button.
A service works from inside the machine but not from outside. Check what it is bound to before blaming the firewall: a daemon listening on 127.0.0.1 is unreachable regardless of what you allow. ss -tlnp shows the binding.
Your home IP changed and you locked yourself out. The reason to put a VPN with a static exit in front of administration rather than allow-listing a residential address. Our VPN comparison covers which providers offer a dedicated IP for this.

Once it is set up

Take a snapshot. A server with a tested firewall and hardened SSH is a known-good state worth being able to return to, and it costs $0.05 per GB a month to keep.

If you are building this on the 30-day trial, remember the firewall configuration lives with the server — terminate the machine and it goes with it. Our trial guide covers closing one out cleanly, and the full review has the wider picture on what Kamatera does and does not do for you.