Applies to: LumaDock VPS (Ubuntu/Debian with UFW or nftables, CentOS/AlmaLinux/RHEL with firewalld)

• Any app/port (SSH, HTTP/HTTPS, databases, game servers, etc.)

How to check which ports are open — and where they’re filtered

On a LumaDock VPS you typically have two layers of network filtering:

  • Cloud firewall (control panel) — sits in front of your VPS. If a port is blocked here, traffic never reaches your OS.
  • OS firewall — inside your VPS (UFW/iptables/nftables or firewalld) that filters packets that do reach the server.

Important: The cloud firewall in the LumaDock control panel is OFF by default for every new deployment. Unless you enable it and add rules, it won’t block your ports.

Quick checklist (copy & run)

  1. Make sure the cloud firewall is OFF (default) or, if enabled, that it allows the port/IP you’re testing.
  2. On the VPS, verify the service is listening: 
    sudo ss -tulpen | grep -E ':22|:80|:443|:3306|:5432|:25565' || sudo ss -tulpen
  3. Check the OS firewall:
    • Ubuntu/Debian (UFW): 
      sudo ufw status verbose
    • RHEL/CentOS/AlmaLinux (firewalld): 
      sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all
    • Raw iptables/nftables (if applicable): 
      sudo iptables -L -n -v
sudo nft list ruleset
  4. From your local machine or another server, scan the target port(s): 
    # Common TCP ports
nmap -Pn -p 22,80,443 YOUR_VPS_IP
  5. If needed, do a quick TCP connect test: 
    # Linux/macOS
nc -vz YOUR_VPS_IP 22
nc -vz YOUR_VPS_IP 443

Open vs Closed vs Filtered

  • Open — a process is listening and a firewall allows it. Scans show open.
  • Closed — no process is listening, but the host/network responds. Scans show closed.
  • Filtered — a firewall dropped the probe (no response). Often indicates cloud firewall or OS firewall blocking.

Step 1 — Confirm cloud firewall state (control panel)

In the LumaDock control panel, check Networking → Firewall for your VPS:

  • Default: Cloud firewall is OFF for new servers. Nothing is blocked here until you enable it.
  • If you enable it, make sure you add inbound rules for the ports you need (e.g., 22, 80, 443, etc.) and restrict by source IPs where possible.

Step 2 — Check services listening inside the VPS

Use ss (or netstat) to confirm your application is listening and on the expected interface (0.0.0.0/:: for all, or a specific IP).

sudo ss -tulpen
# Columns to note:
# Local Address:Port  → which port and interface (0.0.0.0 means all IPv4, [::] means all IPv6)
# Process/PID        → which service is bound (e.g., sshd, nginx, java, docker-proxy)

If you see 127.0.0.1:PORT only, the service is bound to localhost and is not externally reachable until you reconfigure it to listen on the public interface.

Step 3 — Inspect your OS firewall rules

Ubuntu/Debian with UFW

sudo ufw status verbose
# Allow typical ports (examples)
sudo ufw allow 22/tcp
sudo ufw allow 80,443/tcp
sudo ufw allow 25565/tcp      # Minecraft example
sudo ufw reload

RHEL/CentOS/AlmaLinux with firewalld

sudo firewall-cmd --state
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all
# Allow typical services/ports (permanent + immediate)
sudo firewall-cmd --add-service=ssh --permanent
sudo firewall-cmd --add-service=http --permanent
sudo firewall-cmd --add-service=https --permanent
sudo firewall-cmd --add-port=25565/tcp --permanent
sudo firewall-cmd --reload

Raw iptables/nftables (if used directly)

# iptables (legacy view)
sudo iptables -L -n -v

Step 4 — Test from the outside (what the world sees)

Run these from your laptop or another remote server. Replace YOUR_VPS_IP and port list as needed.

# Fast check of common web/ssh ports
nmap -Pn -p 22,80,443 YOUR_VPS_IP

Tip: If you worry about rate limits, slow down aggressive scans: nmap --max-rate 50 -Pn -p 1-1024 YOUR_VPS_IP.

Step 5 — Test locally and from inside the VPS

If outside tests fail, verify basic connectivity from inside the VPS:

# Loopback test (service must be listening)
curl -I http://127.0.0.1:80
nc -vz 127.0.0.1 80

If loopback works but public IP fails, either the service is bound to localhost only or an OS/cloud firewall blocks external access.

How to read results & pinpoint the layer

  • Service is listening (Step 2) + Outside scan shows “filtered” → likely blocked by cloud firewall (if enabled) or OS firewall. Check both.
  • Service is listening + Outside scan shows “closed” → packets reach the host, but nothing accepts them → verify the correct port/app; is it bound to the right interface?
  • Service not listening → start/fix the app; firewall changes won’t help if nothing is bound to the port.
  • Local loopback works, public IP fails → app bound only to 127.0.0.1 or OS/cloud firewall blocks external access.

Common examples

SSH (22/tcp)

# Inside VPS
sudo ss -tulpen | grep ':22'
sudo ufw allow 22/tcp        # UFW
sudo firewall-cmd --add-service=ssh --permanent && sudo firewall-cmd --reload  # firewalld

Web (80, 443/tcp)

# Inside VPS
sudo ss -tulpen | egrep ':80|:443'
sudo ufw allow 80,443/tcp
sudo firewall-cmd --add-service=http --permanent
sudo firewall-cmd --add-service=https --permanent
sudo firewall-cmd --reload

PostgreSQL (5432/tcp)

# Inside VPS
sudo ss -tulpen | grep ':5432'
# Ensure listen_addresses = '*' in postgresql.conf and pg_hba.conf allows your client IP
sudo ufw allow 5432/tcp
sudo firewall-cmd --add-port=5432/tcp --permanent && sudo firewall-cmd --reload

MySQL/MariaDB (3306/tcp)

# Inside VPS
sudo ss -tulpen | grep ':3306'
sudo ufw allow 3306/tcp
sudo firewall-cmd --add-port=3306/tcp --permanent && sudo firewall-cmd --reload

Minecraft Java (25565/tcp)

# Inside VPS
sudo ss -tulpen | grep ':25565'
sudo ufw allow 25565/tcp
sudo firewall-cmd --add-port=25565/tcp --permanent && sudo firewall-cmd --reload

Notes on UDP testing

UDP is connectionless and harder to probe. Many scanners will report UDP ports as “open|filtered.”

# UDP scan (slower and less definitive)
nmap -sU -Pn -p 53,123,1194 YOUR_VPS_IP

Troubleshooting matrix

Symptom Most likely cause What to do
Outside shows filtered Firewall dropping packets (cloud or OS) Confirm cloud firewall (if enabled) allows the port; check UFW/firewalld rules and allow the port; retest.
Outside shows closed No listener on that port Check ss -tulpen; start/fix the service; verify it listens on correct IP.
Works on 127.0.0.1 but not on public IP Service bound to localhost only or firewall blocks external access Reconfigure service to bind 0.0.0.0/:: or the server’s public IP; allow the port in OS/cloud firewall.
Still blocked after allowing port Wrong zone (firewalld) or wrong interface Check firewall-cmd --get-active-zones; add rules in the active zone; reload.
IPv6 reachable but IPv4 not (or vice versa) Service/firewall only configured for one IP family Bind to both families and allow both families in firewall; test with -6/-4 flags.

Security best practices

  • Even though the cloud firewall is OFF by default, consider enabling it to allowlist only needed ports/IPs.
  • Mirroring rules: if you enable the cloud firewall, keep matching allows in your OS firewall for clarity and defense in depth.
  • Avoid exposing databases directly to the internet; use private networking, SSH tunnels, or VPN.
  • Use strong auth (SSH keys, MFA in the control panel), keep services updated, and disable unused ports.

Appendix: handy commands

Install tools

# Debian/Ubuntu
sudo apt update && sudo apt install -y nmap netcat-openbsd

List processes using a port

# Replace PORT with the number you’re checking
sudo lsof -iTCP:PORT -sTCP:LISTEN -n -P
sudo ss -lptn | grep ":PORT"

Show only listening sockets (quick view)

sudo ss -tuln | sed -n '1p; /LISTEN/p'

Summary: Verify the cloud firewall state (OFF by default unless you turn it on), confirm your app is listening on the right interface, allow the port in your OS firewall, then scan from outside with nmap or test with nc/Test-NetConnection. Reading open/closed/filtered correctly tells you whether the block is at the cloud layer, OS layer, or simply that no service is listening.

Was this answer helpful? 0 Users Found This Useful (0 Votes)

Most Popular Articles

Firewall configuration

Each VPS is deployed with its firewall active and, by default, only the connection port is opened...
Set RDP Source IP

This guide explains how to add a specific ip via firewall rule to access your vps only from that...