Quelle: bugs.md #7 (Deep-Dive Runde 2, 2026-09-17) — bewusst offen, kein Fix geplant ohne Produktentscheidung Confidence: hoch (Regel-Reihenfolge im Code nachvollzogen), nicht live reproduziert
FirewallConfig.buildCommands() setzt die Regel "forward established,related → accept" auf Position 4, die Isolations-Drop-Regeln erst ab Position 7+. Für eine neue Verbindung zwischen zwei isolierten Netzen ist das korrekt. Für eine zum Zeitpunkt des Anwendens bereits bestehende (im Conntrack getrackte) Verbindung greift weiterhin Regel 4 zuerst — sie bleibt offen, bis sie von selbst endet. Das ist Standardverhalten jeder stateful/conntrack-basierten Firewall (RouterOS, iptables, pf, …), kein App-spezifischer Fehler.
Der bisher einzige Live-Test dieser Funktion (M8, 2026-09-15) betraf einen frisch aufgeteilten Port ohne bestehende Verbindung — dieser Randfall wurde nie geprüft.
Warum kein automatischer Fix: ein Fix würde bedeuten, beim Aktivieren der Isolation gezielt /ip firewall connection remove für die betroffenen Netzpaare auszulösen — ein zusätzlicher, potenziell überraschender Seiteneffekt (kappt aktive Verbindungen, die der Nutzer evtl. bewusst offen hat). Das ist eine bewusste Produktentscheidung, keine reine Korrektur — offen für Diskussion/Priorisierung.
**Quelle:** bugs.md #7 (Deep-Dive Runde 2, 2026-09-17) — **bewusst offen, kein Fix geplant ohne Produktentscheidung**
**Confidence:** hoch (Regel-Reihenfolge im Code nachvollzogen), nicht live reproduziert
`FirewallConfig.buildCommands()` setzt die Regel "forward established,related → accept" auf Position 4, die Isolations-Drop-Regeln erst ab Position 7+. Für eine **neue** Verbindung zwischen zwei isolierten Netzen ist das korrekt. Für eine zum Zeitpunkt des Anwendens bereits **bestehende** (im Conntrack getrackte) Verbindung greift weiterhin Regel 4 zuerst — sie bleibt offen, bis sie von selbst endet. Das ist Standardverhalten jeder stateful/conntrack-basierten Firewall (RouterOS, iptables, pf, …), kein App-spezifischer Fehler.
Der bisher einzige Live-Test dieser Funktion (M8, 2026-09-15) betraf einen frisch aufgeteilten Port ohne bestehende Verbindung — dieser Randfall wurde nie geprüft.
**Warum kein automatischer Fix:** ein Fix würde bedeuten, beim Aktivieren der Isolation gezielt `/ip firewall connection remove` für die betroffenen Netzpaare auszulösen — ein zusätzlicher, potenziell überraschender Seiteneffekt (kappt aktive Verbindungen, die der Nutzer evtl. bewusst offen hat). Das ist eine bewusste Produktentscheidung, keine reine Korrektur — offen für Diskussion/Priorisierung.
kay
changed title from bugs.md #7: Beobachtung — Netzwerk-Isolation wirkt nicht rückwirkend auf bestehende Verbindungen to bugs.md #7: Isolation wirkte nicht rückwirkend auf bereits bestehende Verbindungen2026-09-17 21:31:32 +02:00
Gefixt (Commit dcb9d9e). Neue SSHTransport.flushConnections/ConnectionService.flushConnections entfernen bereits getrackte Verbindungen zwischen zwei Netzen, sobald sie als isoliert angewendet werden (/ip firewall connection remove [find where (src-address in A) and (dst-address in B)], beide Richtungen), aufgerufen direkt nach den Firewall-Befehlen.
Ehrlicher Verifikationsstand: Die einzelnen Bausteine sind live bestätigt (CIDR-Filterung via print count-only where ... in ..., einfaches remove [find where dst-address=<exakte-IP>] löscht wirklich). Die kombinierte Bedingung, die der Fix nutzt, ließ sich nicht sauber Ende-zu-Ende beweisen — ein erster scheinbarer Erfolg war ein Messfehler (natürlicher ICMP-Conntrack-Timeout, nicht der remove-Befehl). Für den vollen Beweis fehlen zwei echte, getrennte Testnetze mit echten Endgeräten. Details: bugs.md #7.
Schließe als "fixed" (Code + Build + 103 Tests grün), aber mit dokumentiertem Vorbehalt — ein echter Mehrnetz-Live-Test ist der natürliche nächste Schritt, falls gewünscht.
**Gefixt** (Commit dcb9d9e). Neue `SSHTransport.flushConnections`/`ConnectionService.flushConnections` entfernen bereits getrackte Verbindungen zwischen zwei Netzen, sobald sie als isoliert angewendet werden (`/ip firewall connection remove [find where (src-address in A) and (dst-address in B)]`, beide Richtungen), aufgerufen direkt nach den Firewall-Befehlen.
**Ehrlicher Verifikationsstand:** Die einzelnen Bausteine sind live bestätigt (CIDR-Filterung via `print count-only where ... in ...`, einfaches `remove [find where dst-address=<exakte-IP>]` löscht wirklich). Die *kombinierte* Bedingung, die der Fix nutzt, ließ sich nicht sauber Ende-zu-Ende beweisen — ein erster scheinbarer Erfolg war ein Messfehler (natürlicher ICMP-Conntrack-Timeout, nicht der `remove`-Befehl). Für den vollen Beweis fehlen zwei echte, getrennte Testnetze mit echten Endgeräten. Details: bugs.md #7.
Schließe als "fixed" (Code + Build + 103 Tests grün), aber mit dokumentiertem Vorbehalt — ein echter Mehrnetz-Live-Test ist der natürliche nächste Schritt, falls gewünscht.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Quelle: bugs.md #7 (Deep-Dive Runde 2, 2026-09-17) — bewusst offen, kein Fix geplant ohne Produktentscheidung
Confidence: hoch (Regel-Reihenfolge im Code nachvollzogen), nicht live reproduziert
FirewallConfig.buildCommands()setzt die Regel "forward established,related → accept" auf Position 4, die Isolations-Drop-Regeln erst ab Position 7+. Für eine neue Verbindung zwischen zwei isolierten Netzen ist das korrekt. Für eine zum Zeitpunkt des Anwendens bereits bestehende (im Conntrack getrackte) Verbindung greift weiterhin Regel 4 zuerst — sie bleibt offen, bis sie von selbst endet. Das ist Standardverhalten jeder stateful/conntrack-basierten Firewall (RouterOS, iptables, pf, …), kein App-spezifischer Fehler.Der bisher einzige Live-Test dieser Funktion (M8, 2026-09-15) betraf einen frisch aufgeteilten Port ohne bestehende Verbindung — dieser Randfall wurde nie geprüft.
Warum kein automatischer Fix: ein Fix würde bedeuten, beim Aktivieren der Isolation gezielt
/ip firewall connection removefür die betroffenen Netzpaare auszulösen — ein zusätzlicher, potenziell überraschender Seiteneffekt (kappt aktive Verbindungen, die der Nutzer evtl. bewusst offen hat). Das ist eine bewusste Produktentscheidung, keine reine Korrektur — offen für Diskussion/Priorisierung.bugs.md #7: Beobachtung — Netzwerk-Isolation wirkt nicht rückwirkend auf bestehende Verbindungento bugs.md #7: Isolation wirkte nicht rückwirkend auf bereits bestehende VerbindungenGefixt (Commit
dcb9d9e). NeueSSHTransport.flushConnections/ConnectionService.flushConnectionsentfernen bereits getrackte Verbindungen zwischen zwei Netzen, sobald sie als isoliert angewendet werden (/ip firewall connection remove [find where (src-address in A) and (dst-address in B)], beide Richtungen), aufgerufen direkt nach den Firewall-Befehlen.Ehrlicher Verifikationsstand: Die einzelnen Bausteine sind live bestätigt (CIDR-Filterung via
print count-only where ... in ..., einfachesremove [find where dst-address=<exakte-IP>]löscht wirklich). Die kombinierte Bedingung, die der Fix nutzt, ließ sich nicht sauber Ende-zu-Ende beweisen — ein erster scheinbarer Erfolg war ein Messfehler (natürlicher ICMP-Conntrack-Timeout, nicht derremove-Befehl). Für den vollen Beweis fehlen zwei echte, getrennte Testnetze mit echten Endgeräten. Details: bugs.md #7.Schließe als "fixed" (Code + Build + 103 Tests grün), aber mit dokumentiertem Vorbehalt — ein echter Mehrnetz-Live-Test ist der natürliche nächste Schritt, falls gewünscht.