Published: 02.10.2026
A server can be protected in two places: the cloud firewall in front of it in the network, and the host firewall that runs on the server itself. Private networks let your servers talk to each other over internal addresses that cannot be reached from the internet. Each VPS includes one free IPv6 address and a free firewall, and firewalls and private networks are set up in the client area. This article explains how the layers fit together and which ports to open.
Two layers of filtering
The cloud firewall filters traffic before it reaches the server. The host firewall, such as UFW or nftables, filters traffic on the server itself. A packet has to pass both layers. That means a rule in either one can block a connection, so when a service is unreachable, check both places. Using both gives you a second line of defence if one layer is misconfigured.
Minimal open ports
A safe starting point is to open only what you need and keep everything else closed. For a typical website, that usually means:
- SSH for administration, limited to your own addresses when that is practical.
- HTTP and HTTPS for visitors of the website.
- Mail ports, only if the server itself sends or receives mail.
- Monitoring or backup ports, only for the addresses that need them.
Database ports should never be open to the internet. The application connects to the database from the same server or over a private network.
Private networks between servers
A private network connects servers over internal addresses that cannot be reached from outside. Place the database on a private network and let only the application server reach it. This keeps database traffic off the public interface and reduces the number of places that must be protected. Each server gets its own address on the private network. Your application configuration uses that internal address, while visitors continue to reach the public one.
Writing rules in the cloud firewall
Rules in the cloud firewall are applied before traffic reaches the server, which is useful for blocking unwanted connections early. Keep the list short, name each rule clearly and review it when your services change. Remove rules for services you no longer run. After every change, test from outside to confirm the result.
Host firewall basics
Keep the host firewall enabled on the server with the same minimal list. Allow SSH before you enable it, and check the status after each change. Use the firewall tool of your distribution and apply the same principle: deny by default, allow only what you need. Keep the two sets of rules consistent, so that a service which works in one layer does not fail silently in the other.
Test from outside
From a computer outside your network, check which ports answer. A port scanner that you trust, or simply trying to connect to each expected service, shows the result. Only the ports you intend to open should respond. Keep the test result in your notes, and repeat the test after each change to the firewall or to the services.
Frequently asked questions
Is a cloud firewall enough without a host firewall? It is a strong first layer, but a host firewall still helps if a cloud rule changes or a service is exposed by mistake. Use both.
Can I reach a server on a private network from home? Not directly. Connect through the SSH access you have restricted, or through a secure tunnel that you set up yourself.
Does the free IPv6 address need firewall rules? Yes. The server accepts IPv6 traffic, so make sure your host firewall rules cover IPv6 as well.
