SSH Workbench

Firewall Rule Generator

Build firewall rules for any major platform — or paste a rule and get a plain-English explanation.

Client-side only — nothing leaves your browser

Generated rule
sudo ufw allow in from any port 22 proto tcp comment "Allow SSH"

Always test new rules on a console you can recover from. Locking yourself out of a remote server with a bad firewall rule is a common — and avoidable — failure mode.

About Firewall Rules

A firewall rule is a single decision the firewall makes about a packet: who it's from, who it's to, what protocol and port it uses, and what to do with it (allow, drop, reject). Different platforms write these rules in very different syntaxes — UFW reads like English, iptables uses a wall of flags, nftables uses a programming-language-style ruleset, and the cloud providers each have their own JSON or CLI dialect — but the underlying concepts are nearly identical. This generator lets you describe a rule once and emit it in the syntax you need, and the Explain mode goes the other direction: paste any rule, get plain English back.

Firewall Rule Actions Explained

Every firewall rule terminates in an action (sometimes called a target, verdict, or disposition). The most common ones:

ActionWhat it doesSender sees
allow / acceptPass the packet through to the destination.Normal connection.
deny / dropSilently discard the packet with no reply.Connection timeout.
rejectDiscard the packet and send back an ICMP error (or TCP RST)."Connection refused" immediately.
logWrite to the firewall log without taking a verdict.Nothing — usually paired with another rule.

Drop is friendlier to your server (no work to send a reply, no information leaked) but rougher on legitimate users who'll wait for a long timeout. Reject is friendlier to clients — they fail fast — but tells attackers the port exists. The standard advice is drop on internet-facing rules, reject on internal rules where the slow timeout would just frustrate developers.

Same Rule, Eight Syntaxes

How "allow inbound SSH (TCP 22) from 203.0.113.0/24" looks in each system:

PlatformRule
UFWsudo ufw allow in from 203.0.113.0/24 to any port 22 proto tcp
iptablessudo iptables -A INPUT -s 203.0.113.0/24 -p tcp --dport 22 -j ACCEPT
nftablessudo nft add rule inet filter input ip saddr 203.0.113.0/24 tcp dport 22 accept
firewalldsudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.0/24" port port="22" protocol="tcp" accept'
WindowsNew-NetFirewallRule -DisplayName "Allow SSH" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 22 -RemoteAddress 203.0.113.0/24
AWSaws ec2 authorize-security-group-ingress --group-id sg-... --ip-permissions 'IpProtocol=tcp,FromPort=22,ToPort=22,IpRanges=[{CidrIp=203.0.113.0/24}]'
GCPgcloud compute firewall-rules create allow-ssh --direction=INGRESS --action=ALLOW --rules=tcp:22 --source-ranges=203.0.113.0/24
Azureaz network nsg rule create --resource-group rg --nsg-name nsg --name allow-ssh --priority 1000 --direction Inbound --access Allow --protocol Tcp --source-address-prefixes 203.0.113.0/24 --destination-port-ranges 22

Firewall Rule Best Practices

  • Default deny. The base policy should drop everything, then explicitly allow the few protocols and sources you need. Allow-by-default firewalls are not firewalls.
  • Most specific rules first. Most firewalls evaluate top-down and stop at the first match. Put narrow rules (allow SSH from one IP) above broad ones (deny SSH from anywhere).
  • Scope sources tightly. "Allow SSH from anywhere" is a recipe for brute-force noise. Use your office CIDR, a VPN range, or a single jump host instead of 0.0.0.0/0.
  • Always allow loopback. Many services bind to 127.0.0.1 and break in subtle ways if you accidentally drop loopback traffic.
  • Allow established/related early. A stateful ct state established,related accept rule near the top of INPUT lets reply traffic pass without re-evaluating every later rule.
  • Test before you persist. On a remote box, schedule a rollback (at now + 5 min << restore.sh) before applying — if the new rules lock you out, the server reverts itself.
  • Comment every rule. Six months from now, "why is port 8443 open from this random /24?" will be a mystery. Every generator above supports comments — use them.

Frequently Asked Questions

What is a firewall rule?
A firewall rule is a single decision the firewall makes when a packet arrives: it specifies a match (source IP, destination IP, protocol, port, direction, interface) and an action (allow, drop, reject, log). The firewall walks its rule list in order for each packet and applies the first rule that matches. A complete firewall configuration is just a sequence of these rules ending in a default policy (usually deny on inbound and allow on outbound). Different platforms use different vocabulary — iptables calls the action a target, nftables calls it a verdict, AWS calls the rule a security group entry — but every modern firewall reduces to match-plus-action over an ordered ruleset.
What is the difference between inbound and outbound firewall rules?
Inbound (ingress) rules apply to traffic arriving at the host or network — connections initiated from outside. Outbound (egress) rules apply to traffic leaving the host — connections your own machine starts. On most servers, the inbound policy is restrictive (deny by default, allow only the ports you serve) and the outbound policy is permissive (allow anything because you trust your own software). Hardened environments invert this for outbound too: blocking egress except to known endpoints catches malware that tries to phone home. Direction also matters for stateful matching — a stateful firewall remembers the inbound connection so the corresponding outbound reply is allowed automatically, without needing a separate rule.
What is the difference between drop and reject in firewall rules?
Both stop the packet from reaching its destination, but they treat the sender differently. Drop silently discards the packet — no reply, no acknowledgement — so the sender sees a long connection timeout. Reject discards the packet and sends back an ICMP error (or a TCP RST for TCP) so the sender immediately gets a clear &quot;connection refused.&quot; Drop is the conventional choice for internet-facing rules because it doesn&apos;t leak the existence of the port to scanners and uses zero CPU on a reply. Reject is the polite choice for internal networks where the slow timeout would just annoy your own developers. Windows Defender Firewall doesn&apos;t support reject at all — &quot;Block&quot; behaves like drop.
In what order are firewall rules evaluated?
For most firewalls (iptables, nftables, UFW, Windows Defender, pfSense, OPNsense, Sophos) rules are evaluated top-down and the first match wins — later rules are not consulted. This means rule order matters enormously: an &quot;allow all from 10.0.0.0/8&quot; rule above a &quot;deny SSH&quot; rule renders the deny useless. Cloud firewalls work differently. GCP and Azure NSGs use numeric priorities (lower number = higher precedence), so order in the file doesn&apos;t matter. AWS security groups are purely allow-lists with no priorities — if any rule matches, the packet is allowed; there&apos;s no explicit deny. Always check your specific platform&apos;s evaluation model before assuming.
Are firewall rules stateful?
Modern firewalls are stateful by default — they track every connection in a conntrack table and automatically allow reply packets without needing an explicit rule. This is why a single &quot;allow inbound TCP 443&quot; rule is enough to serve HTTPS: the firewall remembers the inbound SYN and lets the outbound SYN-ACK and subsequent packets through. iptables and nftables expose this explicitly via the conntrack module (<code>-m conntrack --ctstate ESTABLISHED,RELATED</code>) and most well-written rulesets allow established/related traffic in the very first rule of every chain. AWS security groups, Azure NSGs, and GCP firewalls are stateful with no configuration needed. The only common stateless option left is network ACLs (AWS NACLs) and very old hardware firewalls, where you have to write explicit return-traffic rules.

Related Tools

iptables to nftables

Convert iptables rules to nftables. Translates chains, NAT, conntrack, and common matchers.

rsync Command Builder

Build rsync commands visually. Local or remote source/destination, flag toggles, exclude patterns, and presets.

rsync Flag Explainer

Paste any rsync command and instantly see what every flag does, with risky-flag warnings.

Docker Compose Generator

Build docker-compose.yml visually. Add services, volumes, networks, env vars — with live YAML and lint warnings.

Dockerfile Generator

Build Dockerfiles from form inputs. Multi-stage builds, healthchecks, and best-practice hints inline.

Need to manage SSH connections?

SSH Workbench lets you connect, browse files, and manage servers visually.

Try SSH Workbench Free