How to Fix UFW on Linux Server with iptables or nftables Backend

To fix UFW on a Linux server, verify the firewall is active, allow SSH, review rule order, check the backend (iptables or nftables), remove conflicts (firewalld/Docker rules), account for cloud provider firewalls, then reload and test.

Start with: allow SSH, default deny incoming, permit required ports, enable UFW, and log/monitor for drops.

In this guide, you’ll learn how to fix UFW on a Linux server step by step. We’ll cover quick checks, common issues (rules not working, SSH lockouts, Docker bypassing UFW), the iptables vs nftables backend, and a safe rebuild procedure. Whether you’re on Ubuntu, Debian, or a YouStable VPS, these practical fixes will get your firewall working securely.

Quick Fix Checklist (Run These First)

These commands resolve most UFW troubleshooting issues quickly. Use a second SSH session while testing to avoid lockouts.

# 1) See UFW status and backend
ufw --version
ufw status verbose

# 2) Make sure SSH stays open
ufw allow OpenSSH || ufw allow 22/tcp

# 3) Set secure defaults
ufw default deny incoming
ufw default allow outgoing

# 4) Allow required services
ufw allow 80/tcp    # HTTP
ufw allow 443/tcp   # HTTPS

# 5) Enable UFW and logging
ufw enable
ufw logging on

# 6) Reload and verify
ufw reload
ufw status numbered
sudo ss -tulpn | grep -E ':22|:80|:443'   # Confirm services listen

If traffic still isn’t passing, continue with the diagnostics below.

Diagnose Common UFW Issues

1) Locked out of SSH (or can’t connect)?

Always allow SSH before enabling UFW. On many distros, the AppProfile “OpenSSH” maps to port 22/tcp:

ufw allow OpenSSH
# or
ufw allow 22/tcp
ufw reload

If you changed SSH to a custom port (e.g., 2222):

ufw allow 2222/tcp
ufw reload

Still stuck? Your ISP or cloud firewall may block 22; verify provider-side rules (see below).

2) UFW rules are not working due to rule order

UFW is order-sensitive. A broad deny above a specific allow will block traffic. Inspect and re-order rules:

ufw status numbered
# Delete a wrong rule (replace N with the rule number)
ufw delete N

# Insert a rule at the top (position 1)
ufw insert 1 allow 443/tcp
ufw reload

If you prefer a clean slate, jump to the reset section below.

3) UFW inactive or not starting at boot

Make UFW persistent and ensure it loads early during boot:

systemctl enable ufw
systemctl start ufw
ufw enable
systemctl status ufw --no-pager

4) iptables vs nftables backend mismatch

Modern UFW can manage iptables (legacy) or nftables. Check which backend you’re on:

ufw --version
# Look for: "backend: nftables" or "backend: iptables"

If other tools manage the same backend (e.g., firewalld, raw iptables scripts), conflicts occur. Pick one firewall manager and disable the rest:

# If firewalld is present, stop and disable it (use with caution)
systemctl stop firewalld
systemctl disable firewalld

# Flush custom iptables/nftables rules if needed (advanced)
iptables -F; iptables -t nat -F; iptables -t mangle -F
nft flush ruleset
ufw reload

Note: Flushing rules can impact production traffic. Schedule a maintenance window or use a staging server first.

5) Cloud firewall or network ACLs blocking traffic

Many “UFW not working” cases are actually provider-level blocks. Verify:

• AWS Security Groups and NACLs allow your ports/IPs
• Azure NSGs and subnet rules permit inbound
• Google Cloud firewall rules allow traffic
• Your VPS panel firewall (e.g., YouStable Cloud/VPS Firewall) mirrors the same ports

Open both provider firewall and UFW to match your service ports.

6) Docker bypassing UFW

Docker modifies iptables and can expose published ports before UFW rules. Two practical fixes:

• Use the DOCKER-USER chain to enforce policy before Docker rules
• Tighten UFW forwarding and explicitly allow only required bridges/ports

# Enforce a default drop for inbound to containers, then allow what you need
iptables -N DOCKER-USER 2>/dev/null
iptables -C DOCKER-USER -j RETURN 2>/dev/null || iptables -A DOCKER-USER -j RETURN

# Example: allow only HTTPS (443) to containers
# (Replace with specific interface/bridge/ports as needed)
# iptables -I DOCKER-USER -p tcp --dport 443 -j ACCEPT

# With UFW, ensure forwarding is controlled
sed -i 's/^DEFAULT_FORWARD_POLICY=.*/DEFAULT_FORWARD_POLICY="DROP"/' /etc/default/ufw
ufw reload

If you must expose Docker services publicly, prefer reverse proxies (Nginx/Traefik) and allow only those front-end ports via UFW.

7) IPv6 disabled or partially configured

If your server has IPv6 but UFW only filters IPv4, traffic can slip through. Enable IPv6 and reload:

grep -i '^IPV6=' /etc/default/ufw || echo "IPV6=yes" >> /etc/default/ufw
sed -i 's/^IPV6=.*/IPV6=yes/' /etc/default/ufw
ufw disable && ufw enable
ufw status verbose

Confirm your services are listening on IPv6 and that provider-level IPv6 is allowed.

8) “Problem running ufw-init” or missing kernel modules

Ensure firewall tooling is installed and compatible with your kernel:

apt-get update && apt-get install -y ufw iptables nftables
modprobe nf_conntrack
journalctl -u ufw -b --no-pager | tail -n 50

On RHEL/Rocky/Alma, install UFW first or consider using firewalld if UFW is not supported by your stack.

Safe Reset and Rebuild of UFW (Step-by-Step)

If your rules are messy or conflicting, a reset is often the fastest path to a secure, working configuration.

# 1) Reset all UFW rules (interactive)
ufw reset

# 2) Set sane defaults
ufw default deny incoming
ufw default allow outgoing

# 3) Keep SSH open (adjust port if custom)
ufw allow OpenSSH || ufw allow 22/tcp

# 4) Open necessary application ports
ufw allow 80/tcp
ufw allow 443/tcp
# Examples:
# ufw allow 3306/tcp             # MySQL (prefer private network only)
# ufw allow from 203.0.113.10 to any port 5432 proto tcp   # Restrict Postgres by IP

# 5) Enable and log
ufw logging low
ufw enable

# 6) Verify, then test externally
ufw status numbered
curl -I http://your-server-ip
curl -I https://your-domain

Tip: When exposing databases or admin panels, restrict by source IP to reduce attack surface.

Real-World Scenarios We Fix at YouStable

Scenario A: UFW enabled, but website still unreachable

Cause: Missing 80/443 allows or provider firewall blocking. Fix: Allow ports in UFW and in the cloud firewall. Confirm Nginx/Apache are listening on the correct IP/port with ss -tulpn.

Scenario B: Fail2ban not banning effectively

Cause: Fail2ban using iptables while UFW uses nftables (or vice versa). Fix: Align backends and set banaction to ufw in jail.local so bans show as UFW rules.

Scenario C: Docker app exposed despite UFW denies

Cause: Docker publishes ports before UFW chains. Fix: Enforce DOCKER-USER policy, set UFW forward policy to DROP, and only allow explicit ports. Optionally place a reverse proxy in front and expose only 80/443.

If you host on YouStable, our support can review your UFW rules, provider firewalls, and Docker networking to harden your setup without downtime.

Best Practices for a Secure, Maintainable UFW

• Default deny inbound; allow only necessary ports
• Always allow SSH first and test in a second session
• Prefer IP-restricted rules for admin panels and databases
• Use numbered rules to manage order precisely
• Enable logging and watch /var/log/ufw.log or journalctl -u ufw
• Keep IPv6 consistent with IPv4 policy (IPV6=yes)
• Avoid multiple firewall managers; pick UFW or firewalld, not both
• Document changes and back up rules before big edits
• Use application profiles: ufw app list, ufw app info “OpenSSH”
• Pair with Fail2ban for SSH and web brute-force protection

Commands Reference (Copy-Paste)

# See everything
ufw --version
ufw status verbose
journalctl -u ufw -b --no-pager | tail -n 100

# Core policy
ufw default deny incoming
ufw default allow outgoing

# Allows
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp

# Restrict by IP
ufw allow from 203.0.113.10 to any port 22 proto tcp

# Ordering
ufw status numbered
ufw insert 1 allow 443/tcp
ufw delete 3

# Service control
systemctl enable ufw
systemctl restart ufw
ufw reload
ufw disable && ufw enable

# Reset and rebuild
ufw reset

Troubleshooting “UFW Not Working” on Different Distros

Ubuntu/Debian

UFW is native here. Confirm backend, ensure no firewalld, and verify Docker behavior. AppProfiles like OpenSSH and Nginx Full simplify rules.

Rocky/Alma/RHEL

firewalld is default. If you insist on UFW, ensure it’s installed, firewalld disabled, and backends are consistent. Otherwise, consider staying with firewalld for native support.

VPS and Cloud Environments

Mirror ports in both UFW and the provider firewall. On YouStable VPS, you can define instance-level firewall rules from the panel for an extra layer of protection.

FAQ