Merge pull request 'Say which way the console orders rules, and fix the numbering' (#5) from console-order into main

Reviewed-on: #5
Reviewed-by: branderson <brad@branderson.io>

bin/dejima-devbox-audit

@@ -190,8 +190,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)"