On a LifeinCloud VPS, traffic can be filtered at two layers: the cloud firewall (in front of your VPS) and the OS firewall inside your server. This guide shows you how to test ports, read scan results, and pinpoint where filtering happens.
Default: The LifeinCloud cloud firewall is OFF by default. All ports are open unless you enable it and add rules.
Contents
- Quick checklist
- Open vs Closed vs Filtered
- Step 1 — Confirm cloud firewall state
- Step 2 — Check services listening inside the VPS
- Step 3 — Inspect OS firewall rules
- Step 4 — Test from the outside
- Step 5 — Test locally/inside the VPS
- How to read results
- Common examples
- Notes on UDP testing
- Troubleshooting matrix
- Security best practices
- Appendix: handy commands
Understand the Two Filtering Layers
- Cloud firewall (control panel) — sits in front of your VPS. If a port is blocked here, the traffic never reaches your OS.
- OS firewall — inside your VPS (
ufw
/iptables
/nftables
orfirewalld
) and filters packets that do reach the server.
Quick Checklist (Copy & Run)
- Confirm the cloud firewall is OFF (default) or, if enabled, that it allows the port/IP you’re testing.
- On the VPS, verify the service is listening:
sudo ss -tulpen | grep -E ':22|:80|:443|:3306|:5432|:25565' || sudo ss -tulpen
- 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
- From your local machine or another server, scan target ports:
nmap -Pn -p 22,80,443 YOUR_VPS_IP
- Quick TCP connect tests:
nc -vz YOUR_VPS_IP 22 nc -vz YOUR_VPS_IP 443
Open vs Closed vs Filtered
- Open — a process is listening and firewalls allow 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
- Default: Cloud firewall is OFF for new VPS. Nothing is blocked unless you enable it.
- If enabled, add inbound rules for the ports you need (e.g., 22, 80, 443) and restrict by source IP 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 = all IPv4, [::] = all IPv6) # Process/PID → which service is bound (e.g., sshd, nginx, java, docker-proxy)
Note: If you only see 127.0.0.1:PORT
, the service is bound to localhost and is not externally reachable until you bind it to 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 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 (used directly)
# iptables (legacy view) sudo iptables -L -n -v # nftables (modern) sudo nft list ruleset
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 # Slow down aggressive scans if needed 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 a firewall blocks external access.
How to Read Results & Pinpoint the Layer
- Service is listening + Outside shows “filtered” → likely cloud firewall (if enabled) or OS firewall dropping packets.
- Service is listening + Outside shows “closed” → packets reach the host, but nothing accepts them (wrong port/app or not bound to the right IP).
- Service not listening → start/fix the app; firewall changes won’t help if no process is bound.
- Local loopback works, public IP fails → app bound only to 127.0.0.1 or a firewall blocks external access.
Common Examples
SSH (22/tcp)
# Inside VPS sudo ss -tulpen | grep ':22' # UFW sudo ufw allow 22/tcp # firewalld sudo firewall-cmd --add-service=ssh --permanent && sudo firewall-cmd --reload
Web (80, 443/tcp)
# Inside VPS sudo ss -tulpen | egrep ':80|:443' # UFW sudo ufw allow 80,443/tcp # firewalld 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' # Config: set listen_addresses='*' and allow your client IP in pg_hba.conf # UFW sudo ufw allow 5432/tcp # firewalld sudo firewall-cmd --add-port=5432/tcp --permanent && sudo firewall-cmd --reload
MySQL/MariaDB (3306/tcp)
# Inside VPS sudo ss -tulpen | grep ':3306' # UFW sudo ufw allow 3306/tcp # firewalld sudo firewall-cmd --add-port=3306/tcp --permanent && sudo firewall-cmd --reload
Minecraft Java (25565/tcp)
# Inside VPS sudo ss -tulpen | grep ':25565' # UFW sudo ufw allow 25565/tcp # firewalld 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) | Allow the port in cloud firewall (if enabled) and OS firewall; retest. |
Outside shows closed | No listener on that port | Check ss -tulpen ; start/fix the service; verify it listens on the correct IP. |
Works on 127.0.0.1 but not on public IP | Service bound to localhost only or firewall blocks external access | Bind to 0.0.0.0 / :: or to the server’s public IP; allow the port in firewalls. |
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) | Configured only one IP family | Bind to both families and mirror firewall rules; test with -6 /-4 . |
Security Best Practices
- Even though the cloud firewall is OFF by default, consider enabling it and allowlisting only needed ports/IPs.
- Mirror rules: if you enable the cloud firewall, keep matching allows in your OS firewall for clarity and defense in depth.
- Avoid exposing databases publicly; prefer private networking, SSH tunnels, or VPN.
- Use strong auth (SSH keys, panel MFA), 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'
nmap
or nc
. Reading open / closed / filtered correctly tells you whether the block is at the cloud layer, the OS layer, or simply that no service is listening.