diff --git a/verfahren/aar/2026-08-01-labnet02-cfgmon.md b/verfahren/aar/2026-08-01-labnet02-cfgmon.md
index c5a2463..7e58c28 100644
--- a/verfahren/aar/2026-08-01-labnet02-cfgmon.md
+++ b/verfahren/aar/2026-08-01-labnet02-cfgmon.md
@@ -10,6 +10,10 @@ installiert, sysctl-Drop-in für `ip_forward`, Tunnel `wg-quick@lab` gestartet u
 `enabled`. Interface `lab` steht mit `10.58.75.2/24`, Routen und Forward-Regeln aktiv,
 Split-DNS gesetzt (`10.58.73.1`, `~lab`).
 
+> ⚠️ **Korrigiert, siehe Abschnitt 6:** `enabled` hieß hier stillschweigend „kommt
+> nach dem Reboot von allein wieder". Das war falsch — der Dienst ist beim Neustart
+> fehlgeschlagen.
+
 **Noch nicht funktionsfähig:** **kein Handshake** — `0 B received`. Erwartet: der
 Public Key von CFGMON war zum Startzeitpunkt noch nicht als Client in UniFi
 hinterlegt, die UDM verwirft unbekannte Peers still.
@@ -72,9 +76,61 @@ cloud-init zurück):
 3. `wg show lab` → Handshake, sobald der Client-Eintrag steht
 4. Prometheus-Target `k3s_host_node` wieder `up`
 5. `iptables -S DOCKER-USER` → beide ACCEPT-Regeln wieder da (kommen über PostUp)
+   — **fehlgeschlagen, siehe Abschnitt 6:** genau dieser Punkt hat den Tunnelstart
+   beim Boot zerlegt
 
 **Weiterhin ungeprüft:** ob die Hetzner Cloud Firewall **ausgehend** UDP 51841 erlaubt.
 Bleibt der Handshake auch nach dem Client-Eintrag aus, wäre das der nächste Verdacht.
 
 **Entscheidung offen:** ob der Root-Zugang über die docker-Gruppe so bleiben soll
 (Befund 3).
+
+## 6. Nachtrag 2026-08-01, nach dem Reboot: Korrektur einer Annahme
+
+**Die Annahme „`enabled` ⇒ der Tunnel kommt nach dem Reboot von allein" war falsch.**
+Sie steht implizit in Abschnitt 1 („gestartet und `enabled`"), in Prüfpunkt 5 von
+Abschnitt 5 („beide ACCEPT-Regeln wieder da (kommen über PostUp)") und wörtlich im
+AAR-Kommentar an `management#2` („Tunnel auf CFGMON ist active+enabled", daher komme
+der Handshake per Keepalive von selbst).
+
+**Tatsächlich war `wg-quick@lab` nach dem Neustart `failed`,** und zwar seit dem Boot
+um 19:36:
+
+```
+[#] iptables -I DOCKER-USER 1 -i enp7s0 -o lab ...
+iptables: No chain/target/match by that name.
+[#] ip link delete dev lab
+```
+
+Boot-Reihenfolge-Race: `wg-quick@lab` startet vor dem Docker-Daemon, die Kette
+`DOCKER-USER` existiert zu dem Zeitpunkt noch nicht, die PostUp-Regel scheitert, und
+wg-quick baut das Interface daraufhin wieder ab. Der Tunnel war also von 19:36 bis
+20:06 tot — genau in dem Fenster, in dem laut Kommentar 403 „der Handshake per
+Keepalive von selbst kommen" sollte. Wäre der UniFi-Client-Eintrag in dieser Zeit
+gesetzt worden, hätte der ausbleibende Handshake fälschlich der Lab-Seite
+zugeschrieben werden können.
+
+**Behoben** (2026-08-01, CFGMON):
+
+1. Drop-in `/etc/systemd/system/wg-quick@lab.service.d/10-after-docker.conf` mit
+   `Wants=docker.service` und `After=docker.service`
+2. In `lab.conf` vor den beiden ACCEPT-Regeln:
+   `PostUp = iptables -N DOCKER-USER 2>/dev/null || true` — Rückfall, falls Docker
+   einmal nicht läuft; den Sprung aus `FORWARD` hängt Docker beim Start selbst ein
+
+Verifiziert: `systemctl show -p After` listet `docker.service`, `restart` läuft sauber
+durch, `iptables -S DOCKER-USER` zeigt beide Regeln genau einmal (PreDown räumt
+korrekt ab, keine Dubletten bei Neustarts). **Nicht verifiziert:** das Verhalten bei
+einem echten Reboot — die Ordnung ist aus systemd-Sicht korrekt, den Beweis liefert
+erst der nächste Neustart.
+
+**Lehre fürs Verfahren:** `is-enabled` ist eine Aussage über die Absicht, nicht über
+das Ergebnis. Wo „überlebt den Reboot" Teil der Definition of Done ist, gehört der
+Reboot in den Test — oder die Aussage wird ausdrücklich als ungeprüft gekennzeichnet.
+Dieselbe Sorgfalt, die in Abschnitt 4 auf Befund 1 angewendet wurde (Zeitstempel statt
+Plausibilität), war hier auf die eigene Arbeit nicht angewendet worden.
+
+**Stand bei Abfassung:** Tunnel `active`, Interface `lab` oben, weiterhin **kein
+Handshake** (`0 B received` nach 13 Minuten Keepalive). Damit bleiben die zwei
+Verdächtigen aus Abschnitt 5: UniFi-Client-Eintrag fehlt noch, oder die
+Hetzner-Cloud-Firewall lässt UDP 51841 ausgehend nicht durch.