Firewall Rule Logic Simulator

Test a packet against an ordered rule set and see which rule decides

Firewall rule sets go wrong in one specific way: a rule near the top is broader than its author realised, and every rule below it that overlaps is dead. Nothing tells you. The traffic that should be denied is allowed, or the traffic you carefully allowed never reaches its rule, and the only symptom is a ticket that says “it works from the office but not from the VPN”.

This tool makes the decision visible. Build an ordered list of rules, define a packet by its five-tuple, and it walks the list top to bottom exactly the way a packet filter does: first match wins, disabled rules are skipped, and anything that reaches the bottom hits the implicit deny. You get the verdict, the rule number and name that produced it, and a trace showing every rule the packet was compared against on the way there.

It is vendor-neutral by design. There is no iptables syntax, no Cisco ASA configuration, no pfSense or Palo Alto import — you enter rules into a generic table and reason about ordering and matching logic, which is the part that transfers between every platform. Nothing is uploaded; the whole simulation runs in your browser, and nothing is persisted between page loads.

What a rule consists of

Rules are reordered with the up and down arrows, which is the control that matters most here: in a first-match-wins evaluator, order is policy. Two identical rule sets in different orders are two different firewalls.

One behaviour to know before you rely on it: Log is a terminating action in this simulator. A packet that matches a Log rule stops there and the result is recorded as denied. On real hardware, a log action is often non-terminating — the packet is recorded and evaluation continues — so use Log rules here to represent “matched and caught by my catch-all”, not to model a pass-through logging rule.

The last row of the table is fixed and cannot be deleted: implicit deny all. Every packet that matches no enabled rule lands there. It appears in the exported documentation too, because a rule set is not fully described without it.

The classic mistake: a broad allow above a specific deny

Load the Web Server preset and look at the order it ships in:

Now run the SSH from External quick packet: 203.0.113.50:54321 → 10.0.1.10:22 over TCP. Rules 1 and 2 fail on the destination port. Rule 3 fails on the source — 203.0.113.50 is not inside 10.0.0.0/24. Rule 4 matches everything headed for that host, so evaluation stops there and the packet is denied, having been compared against four rules. Compare with SSH from Admin (10.0.0.5): the same packet from inside the admin range matches rule 3 and is allowed after three comparisons.

Rule 4 is the lesson. It is a catch-all scoped to one host, and anything you add below it for that host — a deny for a specific attacker, an allow for a new service port — will never be reached. Add such a rule, test the packet, and watch the trace stop at #4 anyway. Then move your new rule above #4 with the arrow and test again. That is the whole exercise, and it is the one that costs people outages.

The mirror-image mistake lives in the Corporate LAN preset, where the last rule denies inbound traffic to 192.168.1.0/24. Move any of the allow rules below it and they stop taking effect. Specific before general, always — and the way to prove it is to test a packet, not to read the list.

Stateful versus stateless

The third tab makes the difference concrete rather than theoretical. In stateless mode, every packet is evaluated against the rule list on its own merits, with no memory. That is the model of an AWS network ACL or a basic packet filter, and its consequence is that return traffic needs its own rule: a rule permitting your host to reach a web server on port 443 does nothing for the server’s reply, which arrives from port 443 to a high port on your host and must be permitted separately.

Switch to stateful mode and a connection table appears. When a packet matches an Allow (or a Log) rule, an entry is recorded with its five-tuple in the NEW state. Before evaluating any subsequent packet, the simulator checks that table for a matching connection with the source and destination reversed — and if it finds one, the packet is allowed immediately as return traffic, promoting the entry to ESTABLISHED, without any rule being consulted at all. The result panel labels this and reports zero rules evaluated, which is exactly what the trace should look like.

The sequence worth running by hand: test an outbound packet in stateless mode, then construct its reply by swapping the addresses and ports, and test that. It gets denied. Turn on stateful mode, run the outbound packet again to create the state entry, then run the same reply. It is allowed. Two behaviours, same rules.

Two honest limits on the state model. The timeout values shown in the table are labels, not a running clock — nothing expires while you work, so you cannot demonstrate an idle connection dropping out of the table. And although the state column can display RELATED, the simulator never assigns it; there is no modelling of the related-connection tracking that a real conntrack implementation uses for things like FTP data channels or ICMP errors bound to an existing flow.

The analysis pass, and what it does not catch

The analysis tab runs four checks over the rule set:

• Overly permissive (high) — an enabled Allow rule with any source, any destination and protocol Any. The check is blunt because the finding is: this rule turns the firewall off.
• Shadowed rule (high) — a rule sitting below an earlier enabled rule that matches all traffic on every field, and is therefore unreachable.
• Redundant rule (medium) — two enabled rules with identical match criteria and the same action. The second can never fire, and it is usually the fossil of a change nobody finished.
• Missing egress filtering (low) — no enabled Deny rule with a specific destination anywhere in the set. Most rule sets are written entirely inbound, and outbound is where data leaves.

Be clear about the boundary. The shadow check only fires on a completely unrestricted earlier rule; a partially broad rule like Log Other Traffic above shadows plenty and is not flagged, because determining whether one rule's match set contains another's across CIDR blocks, port ranges and protocols is a different and much harder problem. The analyser is a lint pass for obvious mistakes. The packet tester and its evaluation trace are the ground truth — when you want to know whether a rule can ever fire, send it a packet.

Alongside the findings, the tab charts hit counts per rule from your test session, including the implicit deny. A rule with zero hits after you have tested the traffic you care about is either unreachable or unnecessary, and either way it deserves attention. The traffic log lists every packet tested with its verdict and the rule that produced it.

Documenting what you built

Two exports are available. The text export writes the rule set in a readable form with the implicit deny appended. The PDF export produces a documentation pack — the full rule table, up to twenty-five test results from your session, and the security-analysis findings on their own page. Both are generated in the browser. This is the artefact to attach to a change request: a rule set, the packets that were tested against it, and what each one did.

Where the model stops

Knowing the boundaries keeps the conclusions sound:

• IPv4 only. CIDR matching is arithmetic on dotted quads; IPv6 addresses will not match as you expect.
• Layer 3 and 4 only. There is no application awareness, no deep packet inspection, no TLS SNI or URL filtering, no user or group identity, and no geo or reputation feeds. Modern next-generation firewalls decide on all of those; this models the ordered five-tuple layer beneath them.
• No interfaces or zones. Real policies are usually written per interface or zone pair, which changes which rules a packet is even evaluated against.
• No NAT. Address translation happens at a defined point relative to filtering on every platform, and getting that order wrong is its own classic bug — but it is not modelled here.
• No fragments, no TCP flags. A rule cannot match on SYN-only, and there is no fragment handling.
• Nothing is saved. The rule set lives in the page; export before you close the tab.

Within those limits, the tool answers the question that causes the most real outages: given this ordering, which rule decides this packet — and is the rule I just wrote ever going to be reached?