Firewall Rule Generator

Most firewall mistakes are not mistakes in a rule. Each line, read alone, says something sensible: let the web port in, keep that noisy network out, allow the remote shell from the office. The mistake is in the order, because a packet filter does not weigh its rules against each other. It reads them from the top and stops at the first one that fits.

That makes a rule list less like a set of wishes and more like a queue at a door. Whoever is asked first answers for everyone behind them. A person who understands this can read any of the common host firewalls, and a person who does not will sooner or later lock themselves out of a machine they cannot walk up to.

What the filter looks at, and in what order

A host firewall decides on very little. It sees the direction of a packet, the protocol, the source and destination addresses, the ports if the protocol has them, the interface, and whether the packet belongs to a conversation that is already under way. RFC 2979 draws the line plainly: a firewall acts either as a protocol end point and relay, as a packet filter, or as some mix of the two. The tools discussed here are packet filters.

The iptables manual states the walk in one sentence. A rule gives criteria and a target; if the packet does not match, the next rule in the chain is examined, and if it does match, the target decides. ACCEPT lets the packet through, DROP discards it, and when the chain runs out the chain’s policy applies. That policy can only be ACCEPT or DROP.

The nftables manual describes the same thing with more care about what “decides” means. An accept verdict ends the evaluation of the current base chain only, while a drop ends the evaluation of the whole ruleset at once, so a drop can never be turned back into an accept by a later chain. A reject is a drop that first tries to send an error back. Within one chain the rules are still read in sequence.

The ufw manual says it most briefly: rule ordering is important and the first match wins. It then gives the advice that follows from that, which is to add the more specific rules first and the more general ones later.

First match wins is the whole grammar. Everything else, in any of these tools, is vocabulary laid over that one rule about order.

Here is the consequence with real numbers, which you can reproduce in the tool above. Take a server whose incoming default is deny, with three rules in this order: allow TCP port 22 from 203.0.113.0/24, deny TCP ports 80 and 443 from 198.51.100.0/24, allow TCP ports 80 and 443 from anywhere. A packet from 198.51.100.7 to port 443 skips the first rule, matches the second and is dropped. Now move the third rule above the second. The same packet matches the general allow first and gets in, and the deny rule below it can never be reached by any packet at all. Nothing in either rule changed.

A range written as 198.51.100.0/24 is a prefix in the sense of RFC 4632: an address and a count of leading bits that are fixed. Whether one rule hides another is therefore a question with an exact answer, because one prefix either contains another or it does not.

Default deny and the rule that makes it livable

The usual shape of a policy is to deny whatever is not named and then name what is wanted. ufw ships that way: its manual describes an incoming default of deny, a forwarding default of deny and an outgoing default of allow. Windows documents the same posture, a default block for inbound connections, and warns against changing it to allow everything.

Taken literally, default deny would break every conversation the machine itself starts. A request leaves under the outgoing policy, and the answer comes back as an incoming packet to some high port that no rule mentions. The fix is connection tracking. The filter remembers conversations, and a single rule near the top accepts packets whose state is established or related. The iptables manual defines the two words: established means the connection has seen packets in both directions, and related means a new connection associated with an existing one, such as an ICMP error.

That rule belongs above any deny, and so does the rule that accepts traffic on the loopback interface, which programs on one machine use to talk to each other. A deny placed above the established rule does not merely block new visitors. It cuts conversations in half, including the one you are typing through. This is why the generator treats the opening rules as switches with a fixed place at the top instead of as ordinary rules you might drag below something else.

Why IPv6 cannot do without ICMPv6

On IPv4 networks it became a habit to drop ICMP wholesale. Carrying that habit to IPv6 breaks the network, because IPv6 moved essential work into ICMPv6. RFC 4861 says Neighbor Discovery corresponds to a combination of IPv4’s address resolution protocol, router discovery and redirect. Block neighbor solicitations and a host cannot find the machine next to it.

Path MTU discovery depends on it too. RFC 4443 requires a router to send Packet Too Big when it cannot forward a packet that is larger than the next link allows, and the sender uses that message to pick a smaller size. Filter it out and large transfers stall while small ones work, a fault that is miserable to diagnose.

RFC 4890 turns this into lists. For traffic addressed to the machine itself it names the messages that must not be dropped: the four error types, echo request and echo response, the router and neighbor messages, the multicast listener messages, certificate path messages and multicast router discovery. That comes to 21 message types. For traffic passing through a firewall the list is shorter, six types. The same document notes that port scanning is much less of a risk on IPv6, so dropping echo requests buys little.

Writing IPv6 addresses consistently matters for a different reason: people compare them by eye. RFC 5952 recommends one form, lower case with leading zeros removed and the longest run of zero groups shortened, so that 2001:DB8:0:0:0:0:0:1 and 2001:db8::1 are visibly the same address in every output.

One policy, four syntaxes

The four syntaxes are more closely related than they look. nftables and iptables are two front ends from the same project. The nftables manual offers an inet table that holds IPv4 and IPv6 rules together, while iptables keeps two separate tools, so a rule with no address has to be written twice. ufw sits on top of that machinery: its framework manual describes rule files in iptables-restore syntax that run before and after the rules you add by command.

That layering has a practical meaning. ufw evaluates its own before file first, then your rules, then its after file, and its manual lists what the default ruleset does, including dropping invalid packets and accepting certain ICMP and ICMPv6 messages. Its command syntax has no ICMP protocol at all. So an ICMP rule cannot be translated to a ufw command; that traffic is decided somewhere your commands do not reach.

The small limits differ as well. The multiport match in iptables takes up to 15 ports in one rule, with a range counting as two, and ufw states the same limit of 15 ports. A longer list has to become several rules, which is harmless when they share one action.

Windows is the real outlier, because it does not keep order. Its documentation gives precedence instead: an explicit block rule wins over any conflicting allow rule, and an allow rule wins over the default block. A list that allows one office address and then denies the port to everyone else works on a first-match filter and fails on Windows, where the block wins. No translation can hide that; it can only be pointed out.

The lockout, and what a firewall is not

The classic accident is to load a new ruleset over the very connection that the ruleset forbids. The ufw manual warns that enabling the firewall flushes its chains and may drop existing connections, and suggests adding the rule for the remote shell before enabling. The check is mechanical, so it should be done every time: take the address you manage from and the port you use, and walk that packet down the list, along with its later packets and the replies going out.

The tools also offer ways to fail safely. nft has a check option that validates commands without applying them, and iptables-restore has a test option that builds the ruleset without committing it. iptables-apply goes further: it loads the new rules, asks you to confirm, and if you cannot answer because the connection is gone it rolls back to the previous rules after a timeout, 10 seconds unless you choose another. A timed rollback turns a locked door into a short interruption.

None of this makes a filter more than it is. It judges packets by what their headers claim. It does not know who is at the other end of an allowed address, it does not inspect what an allowed connection carries, and it does nothing for a service that is reachable and flawed. RFC 2979 is blunt that a firewall is entitled to block what its policy forbids, and that is the full extent of the promise. A short, ordered, tested list is worth having. It is one layer.