Firewall Rule Generator

Build UFW, iptables, and nftables firewall rules with a guided interface. Add presets and generate a complete ruleset ready to paste.

Firewall Type

UFW (Uncomplicated Firewall) is the recommended frontend for iptables on Ubuntu/Debian.

Quick Presets

Click a preset to add it as a new rule.

Block IP / Subnet

Enter an IP address or CIDR subnet to add a deny rule. Press Enter or click Block.

Rules (0 rules)

No rules yet. Click "Add Rule" or use a quick preset above.

Generated Commands

# Add rules above and they will appear here.

All rule generation happens entirely in your browser. No IP addresses, ports, or configuration details are sent to any server.

Linux Firewall Fundamentals

Linux firewalls are built on netfilter, a framework built into the Linux kernel that provides packet filtering, network address translation (NAT), and other packet mangling capabilities. Every packet entering or leaving a Linux system passes through the netfilter framework, which evaluates it against a set of rules organised into chains and tables.

The three core built-in chains that apply to most use cases are INPUT (packets destined for the local machine), OUTPUT (packets originating from the local machine), and FORWARD (packets being routed through the machine). Rules in each chain are evaluated top-to-bottom and the first matching rule determines what happens to the packet — ACCEPT, DROP, or REJECT.

Tables group chains by their purpose. The filter table is where most firewall rules live. The nat table handles network address translation, and the mangle table handles packet modification. For most server firewall purposes, you only need to interact with the filter table.

Understanding default policies is critical. If no rule matches a packet, the chain's default policy applies. A secure server should have a default policy of DROP on INPUT and FORWARD, meaning all traffic is blocked unless explicitly permitted. OUTPUT is usually left as ACCEPT, though hardened environments may restrict outbound traffic too.

UFW vs iptables vs nftables

All three tools ultimately interact with the Linux kernel's netfilter system, but they differ significantly in syntax, complexity, and target audience.

UFW

Best for: Ubuntu/Debian servers where simplicity matters. UFW wraps iptables with human-readable syntax — ufw allow 22/tcp is far more readable than the equivalent iptables command. UFW maintains persistent rules across reboots automatically and is the recommended tool for most NetOz virtual machines running Ubuntu.

iptables

Best for: Advanced configurations, older distributions, and when you need precise control over every aspect of packet filtering. iptables is available on virtually every Linux distribution and gives you direct access to netfilter tables and chains. Rules must be explicitly saved with iptables-save or they will be lost on reboot.

nftables

Best for: Modern distributions (Debian 10+, RHEL 8+, Ubuntu 20.10+). nftables replaces iptables with a cleaner syntax, better performance, and atomic rule replacement. It consolidates IPv4 and IPv6 rules into unified inet tables, reducing duplication. If you are starting fresh on a modern system, nftables is the forward-looking choice.

Common Firewall Configurations

Web Server

A typical web server needs to accept inbound connections on ports 80 (HTTP) and 443 (HTTPS) from any source, while SSH access (port 22) should ideally be restricted to known management IP addresses or a VPN range. Outbound connections are usually left unrestricted so the server can reach package repositories, Let's Encrypt, and external APIs. Use UFW's limit action on port 22 to automatically block IPs that attempt too many connections — an effective defence against brute-force attacks.

Database Server

Database servers (MySQL on 3306, PostgreSQL on 5432, Redis on 6379) should never be exposed to the public internet. Restrict inbound connections on these ports to the specific CIDR range of your application servers — for example, from 10.0.0.0/24 to any port 3306. If your application server and database server are on the same host, bind the database to 127.0.0.1 and you do not need any firewall rules for database access at all.

Development Server

Development VMs often need more open access for testing, but should still be secured. A common pattern is to allow all traffic from your office or home IP range and block everything else. Use source IP restrictions (from 151.158.22.0/24) rather than leaving all ports open. Remember to allow outbound traffic so the server can download packages and dependencies.

NetOz Virtual Machines

NetOz virtual machines run on Linux with full root access from our Adelaide data centre at NextDC AD1. Configuring a proper firewall is one of the first steps you should take after provisioning a new VM. We recommend enabling UFW immediately after your initial SSH session, adding your SSH rule first so you do not lock yourself out, then applying the default deny policy. Because our VMs have public IP addresses, an unconfigured server is exposed to the internet from the moment it is provisioned.

Our network-level infrastructure sits behind BGP routing managed from AS142205, but host-level firewall rules are your responsibility and your first line of defence. Use this tool to generate the rules you need, then paste them into your VM's terminal.

Firewall Best Practices

  • Always add your SSH allow rule before setting the default policy to deny.
  • Use the limit action on SSH to prevent brute-force attacks.
  • Restrict database ports to your private network range, never expose them publicly.
  • Add comments to your rules so future-you knows why each rule exists.
  • Test firewall changes in a screen or tmux session so you can recover if you lose SSH access.
  • For iptables, always save your rules with iptables-save — they do not persist across reboots by default.
  • Audit your rules regularly with ufw status verbose, iptables -L -n -v, or nft list ruleset.