Skip to content
~/UFW / iptables Rule Generator
$

UFW / iptables Rule Generator

Visually build firewall rules for UFW or iptables — configure actions, ports, protocols, source/destination IPs, then copy the generated commands.

Output Format

Presets / Templates

Rules (1)

Rule #1
sudo ufw allow in proto tcp from any to any

Generated Commands

# Enable UFW (if not already enabled)
sudo ufw enable

# Set default policies
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Apply the rules below:
sudo ufw allow in proto tcp from any to any

# Check status
sudo ufw status verbose

Quick Reference

UFW Basics

  • ufw enable
  • ufw disable
  • ufw status verbose
  • ufw reset
  • ufw delete <rule-number>
  • ufw default deny incoming
  • ufw default allow outgoing

iptables Basics

  • iptables -L -n -v
  • iptables -F
  • iptables -P INPUT DROP
  • iptables -P OUTPUT ACCEPT
  • iptables -D INPUT <rule-number>
  • iptables-save > /etc/iptables/rules.v4
  • iptables-restore < /etc/iptables/rules.v4

What is the difference between ufw and iptables?

iptables is the classic interface to the Linux kernel's netfilter packet filter: powerful, but verbose, with rules organized into tables and chains like INPUT, OUTPUT, and FORWARD. UFW (Uncomplicated Firewall) is a friendly frontend that translates short commands like ufw allow 22/tcp into those underlying rules for you. UFW ships as the default on Ubuntu and Debian; everything it does, iptables can do — the reverse is not true, since raw iptables exposes NAT, mangle, and connection tracking.

How does this generator work?

Switch between UFW and iptables output, then build rules with an action (allow/deny/reject, mapped to ACCEPT/DROP/REJECT for iptables), direction (incoming/outgoing, or INPUT/OUTPUT/FORWARD chains), protocol (TCP, UDP, or any), a port or port range, optional source and destination IPs, a network interface, and a comment. Switching modes converts your existing rules automatically. One-click presets cover web servers, SSH-only, databases, mail servers, Docker hosts, and a lock-down profile. Everything runs in your browser.

How do I avoid locking myself out when enabling a firewall?

Always allow SSH before turning the firewall on: run ufw allow 22/tcp first, then ufw enable — never the other way around on a remote server. With raw iptables, append your ACCEPT rule for port 22 before any DROP policy, or use iptables-apply, which reverts automatically if you do not confirm within a timeout. A belt-and-braces trick is scheduling a flush before risky changes, e.g. echo 'iptables -F' | at now + 5 minutes, then cancelling it once you confirm access still works.

Why does Docker bypass my UFW rules?

Docker programs the kernel's nat table directly, so a port published with -p 8080:80 is reachable from outside even when ufw status says traffic is denied — the packets are routed through the FORWARD chain and Docker's own chains, never hitting UFW's INPUT rules. Fixes: bind containers to localhost with -p 127.0.0.1:8080:80, add restrictions in the DOCKER-USER chain that Docker reserves for admins, or set iptables: false in daemon.json if you fully manage rules yourself.

Are iptables rules persistent after a reboot?

No — raw iptables rules live only in kernel memory and vanish on reboot, a classic surprise after a server restart silently drops your firewall. Persist them with the iptables-persistent package (netfilter-persistent save) on Debian/Ubuntu, or iptables-save > /etc/iptables/rules.v4 restored by a systemd unit. UFW does not have this problem: its rules are stored in /etc/ufw/ and reapplied automatically at boot, which is one of the main reasons beginners should start with UFW.

Should I use deny (DROP) or reject (REJECT)?

DROP silently discards the packet, so the client hangs until it times out; REJECT answers immediately with an ICMP error or TCP reset, so connections fail fast. REJECT is kinder on internal networks — your own services and monitoring get instant, debuggable failures instead of 30-second stalls. DROP is common on internet-facing ports since it gives scanners no response, though it does not truly hide you: tools like nmap flag filtered ports anyway. This generator supports both, in both modes.

What about firewalld and nftables?

RHEL, CentOS Stream, Rocky, and Fedora use firewalld, a zone-based frontend (firewall-cmd --add-service=http --permanent) playing the same role UFW does on Ubuntu. Under the hood, modern distros have moved the backend from legacy iptables to nftables — on these systems the iptables command is actually iptables-nft, a compatibility shim translating to nft rules. The commands this tool generates work through that shim, so they remain valid on current distributions while you migrate to native nft syntax at your own pace.