Overview
Every VPS is exposed to the public internet the moment it’s provisioned. Without a firewall, any port your server happens to be listening on is reachable by anyone. That includes SSH, database ports, admin panels — all of it. A VPS firewall is your first line of defence, controlling exactly which traffic is allowed in and out.
Linux gives you two main tools for this: iptables, the low-level kernel firewall, and UFW (Uncomplicated Firewall), a frontend that makes iptables far more manageable. Most users on Ubuntu or Debian should start with UFW. If you’re on CentOS/AlmaLinux/Rocky Linux, you’ll likely be working with firewalld or raw iptables. This guide covers both UFW and iptables so you can apply whichever fits your setup.
If you’re running a VPS SSD Hosting plan from Host & Tech, your server comes without a preconfigured firewall by default on unmanaged plans — so this setup is on you. Don’t skip it.
Prerequisites
- Root or sudo access to your Linux VPS
- SSH access confirmed and working before you start
- OS: Ubuntu 20.04/22.04/24.04, Debian 11/12, CentOS 7/8, AlmaLinux 8/9, or Rocky Linux 8/9
- Basic comfort with a terminal and text editor (
nanois fine) - Your current IP address handy — you’ll need it to whitelist SSH access
Option A: Configure a Firewall Using UFW (Ubuntu/Debian)
UFW ships with Ubuntu and most Debian-based systems. It’s the right tool for most VPS users who don’t need fine-grained packet filtering.
Step 1: Check UFW Status and Install If Needed
sudo ufw status
sudo apt install ufw -y # only if not already installedIf UFW shows Status: inactive, that’s expected — you haven’t enabled it yet.
Step 2: Set Default Policies
Before enabling UFW, set the defaults. This tells UFW to deny all incoming traffic and allow all outgoing traffic unless you explicitly say otherwise.
sudo ufw default deny incoming
sudo ufw default allow outgoing⚠ Warning: Do NOT run sudo ufw enable yet. If you haven’t allowed SSH, you’ll lock yourself out immediately. Complete the next step first.
Step 3: Allow SSH
If you’re on the standard port 22:
sudo ufw allow 22/tcpIf you’ve already moved SSH to a custom port (e.g. 2222), use that instead:
sudo ufw allow 2222/tcp📝 Note: You can restrict SSH to your specific IP for tighter security: sudo ufw allow from 203.0.113.45 to any port 22. Replace 203.0.113.45 with your actual IP. If your ISP gives you a dynamic IP, be careful — you can lock yourself out after a reconnect.
Step 4: Allow Any Other Required Services
Add rules for whatever your server actually runs. Common examples:
# Web server
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
# Mail server
sudo ufw allow 25/tcp
sudo ufw allow 587/tcp
sudo ufw allow 993/tcp
# MySQL (only if remote connections needed — ideally leave this closed)
sudo ufw allow from 203.0.113.50 to any port 3306I’d recommend keeping port 3306 (MySQL) and 5432 (PostgreSQL) closed to the public entirely. If your app runs on the same server, it connects via localhost and doesn’t need a public firewall rule.
Step 5: Enable UFW
sudo ufw enableYou’ll see a confirmation prompt. Type y and press Enter. UFW is now active and will persist across reboots.
Step 6: Verify Your Rules
sudo ufw status verboseThis shows every rule currently active, including direction and protocol. Check that SSH is listed before closing your terminal session.
Option B: Configure a Firewall Using iptables
iptables gives you more control but requires more care. If you’re on CentOS 7 or managing a server where UFW isn’t available, here’s a working baseline ruleset.
Step 1: View Current Rules
sudo iptables -L -v -nStep 2: Flush Existing Rules (Clean Slate)
⚠ Warning: This wipes all existing iptables rules immediately. Only run this if you’re starting fresh and have console access as a backup in case SSH drops.
sudo iptables -F
sudo iptables -X
sudo iptables -ZStep 3: Set Default Policies and Core Rules
# Allow established sessions to continue
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Allow loopback interface
sudo iptables -A INPUT -i lo -j ACCEPT
# Allow SSH
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Allow HTTP and HTTPS
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Drop everything else
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPTThe ESTABLISHED,RELATED rule at the top is one beginners often miss. Without it, your server can initiate connections but can’t receive the responses — which breaks things like apt update and outbound API calls.
Step 4: Save Rules So They Persist After Reboot
iptables rules are lost on reboot unless you save them. On Debian/Ubuntu:
sudo apt install iptables-persistent -y
sudo netfilter-persistent saveOn CentOS/AlmaLinux/Rocky Linux:
sudo service iptables save📝 Note: On CentOS 7+, firewalld is the default and conflicts with direct iptables management. Either use firewalld exclusively or disable it first with sudo systemctl disable --now firewalld before working with iptables directly.
Common Issues & Troubleshooting
Locked Out of SSH After Enabling UFW
You enabled UFW before adding an SSH rule. Your existing session may still be alive, but any new SSH connection will be refused. If you’re still connected, run sudo ufw allow 22/tcp immediately. If you’re fully locked out, use your VPS provider’s out-of-band console (at Host & Tech this is available in the client portal under “VPS Console”) to regain access and fix the rules without needing SSH.
UFW Rules Exist But Traffic Is Still Blocked
UFW sits on top of iptables. If another tool — like Docker, fail2ban, or a control panel like cPanel/WHM — has injected its own iptables rules, those can override or conflict with UFW. Run sudo iptables -L -v -n and look for DROP or REJECT rules appearing before your ACCEPT rules in the INPUT chain. Docker in particular inserts its own rules aggressively and can punch holes in your firewall you didn’t intend.
iptables Rules Lost After Reboot
You forgot to save them. iptables rules live in memory by default. Install iptables-persistent on Debian/Ubuntu systems and run sudo netfilter-persistent save. On Red Hat-based systems, sudo service iptables save writes rules to /etc/sysconfig/iptables.
Port Is Allowed in UFW But App Still Can’t Connect
The firewall isn’t always the issue. Check whether your application is actually listening on that port with sudo ss -tlnp | grep LISTEN. If the port doesn’t appear, the app isn’t running or is bound to 127.0.0.1 only (which means it’s intentionally refusing external connections). A firewall rule won’t fix a binding issue.
UFW Showing “ERROR: Could not load logging rules”
This usually appears on OpenVZ-based VPS containers where kernel modules for logging aren’t available. It’s mostly cosmetic — UFW’s filtering rules still apply. If you’re seeing this and need proper logging, you may need a KVM-based VPS, which has full kernel access. Host & Tech VPS plans use KVM virtualisation, so this error is typically absent on our infrastructure.
FAQ
Frequently Asked Questions
Should I use UFW or iptables on my VPS?
UFW is the better choice for most people. It’s easier to manage, less likely to result in a misconfiguration that locks you out, and perfectly capable for the vast majority of VPS use cases. Use iptables directly only if you need custom packet filtering, NAT rules, or are working in an environment where UFW isn’t available.
Does enabling a firewall affect my VPS performance?
In practice, no — not in any way you’d notice. Firewall rule evaluation happens at the kernel level and the overhead is negligible for typical VPS workloads. The only time firewall rules affect performance is with very high packet-per-second traffic on extremely busy servers, which is a dedicated server concern, not a standard VPS one.
How do I open a port in UFW?
Run sudo ufw allow PORT/tcp, replacing PORT with the port number you need. For example, sudo ufw allow 8080/tcp opens port 8080 for TCP traffic. Run sudo ufw status afterwards to confirm the rule is active. You don’t need to restart UFW — rules take effect immediately.
Is a VPS-level firewall enough, or do I need something else?
A host-based firewall like UFW or iptables is essential, but it’s one layer. For a more complete setup, also consider a network-level firewall (some VPS providers offer this as a separate product), disabling unused services, keeping software updated, and using fail2ban to block brute-force SSH attempts. Security is layered, not a single switch.
Will my firewall rules survive a VPS reboot?
With UFW, yes — rules persist automatically once UFW is enabled. With raw iptables, you need to explicitly save your rules using netfilter-persistent save on Debian/Ubuntu or service iptables save on CentOS/AlmaLinux, otherwise they’re wiped on reboot. This is one of the most common mistakes when setting up iptables manually.