Say which way the console orders rules, and fix the numbering

The runbook said the console appends new rules at the bottom and that entering them in the documented order was all it took. It inserts them at the top. Entering the table in order therefore produces the reverse of it: the four DROPs above every pinhole, and a devbox that cannot reach its forge.

That made the instructions produce the exact failure the same section warns about, and it is the failure with no symptom - the VM boots, the console shows the rules present, and nothing looks wrong until something tries to reach the forge. The runbook now names the behaviour, gives both ways through it, and says to read the finished list against the table before trusting it, because nothing else catches this.

The template and the audit's FAIL message said the same wrong thing and are corrected. So is test/firewall.bats's explanation of why it exists, which is now stronger: getting the order wrong is the default outcome of following the table rather than an unusual mistake.

Separately, the rule numbers in that section were inherited from the sister project's eight-row table and never updated for this one's ten rows. It cited rules 5-8 as the DROPs, rules 2-4 as the LAN exposure and rule 8 as the last. Those are 7-10, 3-6 and 10 here. The Values that must agree table further down was already correct, which is what made the mismatch survive a read.

bin/dejima-devbox-audit

@@ -140,8 +140,9 @@ cmd_reach() {
             say "  Either the hypervisor rules are not applied to this VM, or an"
             say "  exception above the DROPs is wider than it looks. Check the"
             say "  Network device's Firewall checkbox first, then rule order in the"
-            say "  security group - the console appends, so a rule added later sits"
-            say "  below the DROPs and does nothing."
+            say "  security group - the console inserts new rules at the top, so"
+            say "  the documented order has to be built by dragging or entered"
+            say "  backwards, and a rule left where it landed does nothing."
             say ""
             say "  One false alarm is possible: if a rule REJECTs rather than DROPs,"
             say "  the block is working but sends an answer back, and this probe"

proxmox/README.md

@@ -285,17 +285,31 @@ once, in one place, and cannot drift between hosts.
 **Order matters within the group, and it is the one thing here that is easy to
 get wrong.**
 Rules are evaluated top to bottom and the first match wins. Your forge and
-your resolver are *inside* the ranges rules 5–8 drop, so if either pinhole
+your resolver are *inside* the ranges rules 7–10 drop, so if either pinhole
 ends up below them it is dead and the VM cannot reach the forge or resolve
-anything. The console appends new rules at the bottom, so adding them in the
-order above is all it takes — but check the list afterwards, and drag rows if
-they are out of sequence.
+anything.
 
-Rules 2–4 are the entire remaining LAN exposure, and they are why "no LAN
-access" is not literally true. Both destinations are pinned to one host and
-one port.
+**The console inserts each new rule at the TOP of the list, not the bottom.** So
+entering the rules in the order they are written above leaves you with them in
+reverse: the four DROPs on top, every pinhole beneath them, and a devbox that
+cannot reach its forge. Following the table without watching the list is enough
+to produce exactly the failure this section is warning about.
 
-Nothing follows rule 8. The public internet is reached by the default policy.
+Two ways through it. **Drag each rule to the bottom as you add it**, which keeps
+the list matching the table at every step and is the easier one to check. Or
+enter them in reverse, from the last row up to the first, and let the insertions
+stack into the right order — quicker, and you are reading the table backwards
+while doing it, which is its own way to get one wrong.
+
+Either way, **read the finished list top to bottom and compare it against the
+table** before you trust it. Nothing else catches this: a dead pinhole looks
+exactly like a working firewall until something tries to reach the forge.
+
+Rules 3–6 are the entire remaining LAN exposure, and they are why "no LAN
+access" is not literally true. Both destinations are pinned to one host, on
+the ports named.
+
+Nothing follows rule 10. The public internet is reached by the default policy.
 
 ### Values that must agree
 

proxmox/firewall.fw.template

@@ -105,8 +105,12 @@ IN ACCEPT -p udp -dport 68 -log nolog
 # --- the two LAN exceptions -------------------------------------------------
 # ORDER MATTERS: these must come before the DROPs below, because first match
 # wins and both of these addresses are inside the ranges those DROPs cover.
-# The console appends new rules at the bottom, so adding them in this order is
-# the whole trick.
+#
+# In the web console this is harder than it looks. New rules are inserted at
+# the TOP of the list, so entering them in the order written here produces the
+# reverse of it - DROPs above the pinholes, and a devbox that cannot reach its
+# forge. Drag each one to the bottom as you add it, or enter them backwards.
+# proxmox/README.md section 3 says this where someone following it will see it.
 #
 # These are the entire remaining LAN exposure, and they are why "no LAN
 # access" is not literally true: you cannot push without the forge, and the

test/firewall.bats

@@ -8,8 +8,9 @@
 # is dead, and dead in the quietest possible way: the VM boots, the console
 # shows the rules present, and the box simply cannot reach its forge.
 #
-# The console appends new rules at the bottom, so getting this wrong is the
-# default outcome of adding a rule later rather than an unusual mistake.
+# The console inserts new rules at the TOP of the list, so entering them in the
+# documented order produces the reverse of it. Getting this wrong is therefore
+# the default outcome of following the table, not an unusual mistake.
 
 setup() {
     REPO="$(cd "$BATS_TEST_DIRNAME/.." && pwd)"