Route traffic to your server

Your servers sit on a private network behind a shared firewall. Traffic from the internet arrives at a public IP, and the firewall decides both whether to let it through and where to send it.

That means getting a service reachable is usually two separate things, not one:

1. Translation — which private server should this public traffic go to? (NAT or a port forward)
2. Permission — is this traffic allowed at all? (a rule)

Most “my site isn’t loading” tickets are one of the two being present without the other.

Which one do you want?

The Firewall page has a tab for each.

You want	Use	Effect
One public IP to belong to one server, for everything	NAT	All traffic on that public IP goes to that server
Just one service reachable, e.g. web or SSH	Port forwards	Only that port is redirected
To allow or block traffic that already knows where it’s going	Rules	Permits or denies; doesn’t redirect

If you have a public IP dedicated to a single server, NAT is simpler — set it once and every port follows. If several servers share one public IP, you need port forwards, because a given port on that IP can only lead to one of them.

Set up NAT

You need a public IP assigned to you first — see Request a public IP.

1. Go to Firewall and open the NAT tab.
2. Create a mapping from your public IP to the private IP of the server.
3. Save.

The server’s private IP is on its Network tab. If that’s blank, the panel can’t read it because the guest agent isn’t installed.

Set up a port forward

1. Go to Firewall and open the Port forwards tab.
2. Add a forward: the public port traffic arrives on, the private IP of the destination server, and the port on that server.
3. Save.

The two ports don’t have to match. Forwarding public 2222 to private 22 is a common way to give several servers SSH access through one public IP.

Then allow it with a rule

Translation alone doesn’t guarantee the traffic is permitted. On the Rules tab, make sure something allows the traffic you just directed — typically by destination port.

Keep rules as narrow as the service needs:

• A public website needs 80 and 443 from anywhere.
• SSH does not need to be open to the whole internet. Restrict 22 to the addresses you actually connect from. This single change removes most of the noise you’ll otherwise see in firewall activity.
• Databases should almost never be reachable from the internet. Keep them on the private network and reach them from another of your servers.

Caution

If you connect over SSH, don’t narrow the SSH rule to an address you aren’t currently using — you will lose your session and not get back in. Verify from a second connection before removing the old rule, and keep the console as your way back if you do lock yourself out.

Check it end to end

Work outwards from the server. Each step rules out one layer.

1. Is the service running and listening? On the server:

ss -tlnp | grep :443

Nothing listed means the problem is your application, not the network. Also check it isn’t bound to 127.0.0.1 only — that accepts local connections and nothing else.

2. Does the server’s own firewall allow it? A guest firewall (ufw, firewalld, Windows Defender Firewall) sits inside the server and is separate from ours.

ufw status                    # Debian, Ubuntu
firewall-cmd --list-all       # RHEL, Rocky, Oracle Linux

3. Does it work from another of your servers? If a private-network connection succeeds, the service is healthy and the issue is at the edge — the NAT/forward or the rule.

4. From outside:

curl -v https://YOUR_PUBLIC_IP/
nc -vz YOUR_PUBLIC_IP 443

Then read the firewall activity tab. Seeing your attempt blocked means a rule is missing. Seeing nothing at all usually means the traffic never got translated — check NAT or the port forward.

Common causes

A rule exists but nothing is translated. The rule permits traffic that has no destination. Add NAT or a port forward.

Traffic is translated but no rule allows it. You’ll see the attempt blocked in activity. Add a rule.

Two things claim the same public port. A port on one public IP can only lead to one server. Change one of them to a different public port, or use a second public IP.

It works by IP but not by domain. That’s DNS, not the firewall. Check your domain’s A record points at the public IP, and remember records take time to propagate.

It worked and then stopped. Check the server is still running and its disk isn’t full, then look at WAF and intrusion detection — in blocking mode the WAF can drop traffic that your rules permit.