UFW vs Provider Firewall on a VPS: Which Layer Should Block Traffic?
UFW and a provider firewall are not competitors — they filter at different layers. UFW is a host-level front end for netfilter inside your VPS, while a provider firewall drops packets at the network edge before they ever reach your operating system. Use both: the edge firewall for hard lockdown, UFW for readable, app-aware rules.
On this page
What UFW is
UFW (Uncomplicated Firewall) is a rule-writing wrapper around Linux netfilter: nftables on modern distros, iptables on older ones. It runs as a userspace tool plus a systemd service inside your VM and writes kernel packet-filter rules.
- Sees everything in the guest: interfaces, ports, source IPs, and per-app rule sets.
- Logs locally: blocked packets land in
/var/log/ufw.logor the kernel log, which is gold for debugging why a connection fails. - Configurable per service: you can open 443 only for specific source ranges, rate-limit SSH, and tag rules with comments.
- Easy to break: a bad rule or a crashed service can leave ports exposed, or lock you out entirely.
UFW is the layer that knows what your machine is doing. It is not the layer that knows whether the machine is compromised.
The plan behind Hosting Notes
Same 4 GB VPS and LiteSpeed stack we benchmark in these guides.
What a provider firewall is
A provider firewall is a rule set applied at the platform's network edge, outside the guest OS. That means a virtual switch, SDN layer, or hypervisor filter. Traffic is evaluated before the packet is delivered to your VM's virtual NIC.
- Blocks before the OS sees it: a port closed here never generates a kernel log line inside the VM, because the packet never arrived.
- Survives OS-level mistakes: if you fat-finger an iptables flush or a process binds to 0.0.0.0, the edge rule still holds.
- No process visibility: it filters by port, protocol, and IP, not by which daemon is listening.
- Logging varies by provider: some expose rule hit counters or flow logs. Others give you almost nothing.
Treat it as a blast door. It is coarse, but it is the one rule set an attacker with root inside the guest cannot edit.
Side-by-side comparison
| Aspect | UFW (host) | Provider firewall (edge) |
|---|---|---|
| Where rules run | Inside the VM, netfilter | Platform network layer |
| Blocks a packet before the OS? | No | Yes |
| Process-aware rules | Yes, via app profiles | No |
| Survives root compromise | No | Yes |
| Local log detail | High | Usually low or aggregated |
| Risk of self-lockout | Real | Lower, dashboard-managed |
The Docker gotcha that breaks UFW
Docker inserts its own chains into netfilter and publishes container ports through them. Those rules are evaluated before UFW's, so a container started with -p 5432:5432 can be reachable from the internet even when ufw status says the port is denied. This is the most common reason people expose a database they thought was firewalled.
Two fixes work. Bind published ports to loopback (-p 127.0.0.1:5432:5432) and reach them through a reverse proxy, or set iptables: false in Docker's daemon config and manage rules yourself. Either way, an edge firewall rules out the whole class of mistake: a closed port at the network layer cannot be reopened by a container manifest.
A sane setup order
- Create the edge rule set first. Allow SSH (ideally restricted to your IP), HTTP and HTTPS. Deny everything else inbound.
- Confirm you can still connect. The edge layer is your safety net for the next step.
- Enable UFW inside the VM with explicit allows, then
ufw default deny incomingandufw default allow outgoing. - Add rate limiting on SSH:
ufw limit 22/tcp. - Verify from outside with a port scan, not from the box itself.
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw limit 22/tcp
sudo ufw allow 80,443/tcp
sudo ufw enable
sudo ufw status verboseNote
Always run sudo ufw allow 22/tcp before sudo ufw enable on a remote box. Better: keep a second SSH session open in another terminal while you change rules, so a lockout costs you nothing.
If your VPS provider already gives you an edge firewall with per-rule control, UFW is your second layer, not your first. Entry KVM plans on a Hostinger VPS include full root access, so you configure both layers yourself. That is exactly what you want for anything running stateful services or a database.
Set the edge rules once. Keep UFW readable and commented. Log both. When something breaks, the logs tell you which layer dropped the packet.
Frequently asked questions
Do I need UFW if my VPS provider already has a firewall?
Yes, if you want granular control. The provider firewall filters by port, protocol, and IP at the network edge. UFW adds rate limiting, per-application profiles, source-restricted rules, and detailed local logging that tells you exactly which rule dropped a packet.
Which firewall blocks traffic first?
The provider firewall does. Packets are evaluated at the platform network layer before they reach your VM's virtual NIC, so a denied port never appears in your UFW or kernel logs at all.
Why does UFW show a port as blocked but it is still reachable?
Almost always Docker. Docker writes its own netfilter chains that are evaluated ahead of UFW's rules, so published container ports bypass UFW entries. Bind ports to 127.0.0.1 or disable Docker's iptables management to fix it.
Can a provider firewall replace a host firewall entirely?
No. It cannot distinguish which process is listening, cannot rate-limit per connection the way UFW can, and gives you limited logging. It is a hard outer boundary, not a substitute for host-level policy.
What is the minimum safe firewall setup for a new VPS?
Allow SSH from your IP only, allow ports 80 and 443, deny the rest inbound, permit outbound, and enable rate limiting on SSH. Verify with an external port scan before you deploy anything.
Ready to get started? Check out Hostinger's plans.