# Der erste echte Job für ein MCP-Gateway: das OPNsense-Cluster reviewen

> Das MCP-Gateway steht, und jetzt fehlt eine sinnvolle Aufgabe dafür. Hier ist eine gute erste: einen Agenten auf das OPNsense-Cluster richten und fragen, was daran nicht stimmt. Ein kurzer Auftrag rein, eine Liste echter Befunde raus — in acht Minuten und ohne eine einzige SSH-Sitzung.

Canonical: https://www.toolmesh.io/de/blog/reviewing-an-opnsense-ha-cluster/

Die meisten begegnen MCP auf dieselbe Weise: Man verdrahtet ein Gateway, sieht ein Modell ein Tool aufrufen, es funktioniert — und dann kommt die verlegene Pause. Es kann jetzt an die eigenen Systeme. Und was macht man damit?

Hier ist ein guter erster Job, weil er keine Automatisierung braucht, nichts verändert und etwas liefert, mit dem man noch am selben Nachmittag arbeiten kann: **einen Agenten fragen, was an der eigenen Firewall nicht stimmt.**

Wir haben es an einem laufenden OPNsense-HA-Paar gemacht — zwei Geräten, die identisch sein sollen und die lange niemand Feld für Feld verglichen hat.

:::note[Der vollständige Auftrag]
Erstelle ein Firewall-Cluster-Review der beiden Knoten, nur mit den OPNsense-Tools. Nutze kein weiteres Wissen — kein Wiki, keine Notizen, keine Erinnerungen. Erstelle einen Report dazu.
:::

Mehr ist es nicht. Kein Skript zu schreiben, kein Field-Mapping, keine Pipeline zu pflegen.

## Was man dafür braucht

Jede Firewall ist ein Backend am Gateway, beschrieben durch eine einzige YAML-Datei, die festhält, was die OPNsense-API anbietet — diese Beschreibung ist [DADL](https://dadl.ai), und daraus werden die Tools, die der Agent aufrufen kann. Es gibt keinen MCP-Server zu schreiben und nichts, was auf der Firewall selbst installiert werden müsste. Der API-Key liegt im Gateway, nicht im Chat-Client.

Gearbeitet wird dann im Code Mode: Statt eines Tool-Aufrufs pro Frage schreibt das Modell ein kurzes Skript, das in der Sandbox des Gateways läuft, abfragt, was es braucht, und nur sein eigenes Ergebnis zurückgibt. Das ist wichtiger, als es klingt, denn nur was das Skript zurückgibt, erreicht überhaupt das Modell. Ein einziger Firmware-Endpunkt antwortet mit rund 330 KB — neunhundert Pakete plus Changelog — auf die schlichte Frage „welche Plugins sind hier installiert?". In der Sandbox schrumpft das auf fünf Namen.

Aufwand für das Ganze: **acht Minuten, keine SSH-Sitzung, nichts verändert.** Eine Einschränkung gehört deutlich dazu: Unser Key hatte Vollzugriff, und der Agent hat schlicht nichts anderes als Lese-Tools aufgerufen. Das ist eine Entscheidung, keine Garantie. Jedes Tool der Beschreibung trägt eine Zugriffsstufe, das Gateway kann also ausschließlich die lesenden anbieten — für ein Review ist das der vorzuziehende Aufbau.

## Was zurückkam

Das erste Ergebnis ist das langweilige, und es ist das, das man sich wünscht: **Die Regelwerke stimmen überein.** 27 Benutzerregeln je Knoten, Feld für Feld verglichen — Aktion, Interface, Richtung, Protokoll, Quelle und Ziel inklusive Negation, Ports, Logging, Gateway, Reihenfolge — mit null Abweichungen. Dasselbe bei den 23 Aliasen, den NAT-Regeln, den Benutzern. Beide Knoten führen vergleichbar große State-Tabellen, und so sieht funktionierende Zustandsreplikation aus; ob ein Failover die Sitzungen tatsächlich erhält, sagt einem nur ein Failover. 70 virtuelle IPs, jede davon MASTER auf dem einen und BACKUP auf dem anderen Knoten, keine doppelt beansprucht.

Und dann der interessante Teil.

- **Ein TLS-Zertifikat, das am 3. August 2019 abgelaufen ist** und weiterhin als in Benutzung markiert wird. Ein ACME-Client ist installiert, und im Zertifikatsspeicher liegt nichts, was er je ausgestellt hätte.
- **Eine unterschiedliche MTU auf demselben Uplink** — ein Knoten steht auf 1456, der andere auf 1500. Heute ist daran nichts falsch. Sichtbar wird der Unterschied erst an dem Tag, an dem der zweite Knoten übernimmt, als die Sorte Pfad-MTU-Problem, die einen Nachmittag Suche kostet.
- **Automatische Firmware-Updates um 04:00 Uhr — auf beiden Cluster-Knoten.** Derselbe Job, dieselbe Zeit, kein Versatz. Beide Geräte können damit in derselben Nacht dasselbe Update ziehen — genau das, wogegen ein Paar existiert.
- **Eine verwaiste Testadresse** auf einem Knoten, laut Beschreibung temporär, an dessen Hardware-Adresse gebunden und keiner Failover-Rolle folgend.
- **Auseinanderdriftende Log-Einstellungen:** Beide Knoten senden an denselben Collector, aber mit unterschiedlicher Ausführlichkeit und unterschiedlichem Nachrichtenformat. Was diese Logs auswertet, sieht nach einem Failover etwas anderes.
- **Drei Konten, alle Administrator, kein zweiter Faktor, keine Quellnetz-Beschränkung an der Admin-Gruppe.**

Nichts davon ist exotisch. Es ist das Sediment, das jede lang gelebte Firewall ansammelt: einmal während einer Migration gesetzt, ein Test, den nie jemand aufgeräumt hat, ein Default, den niemand noch einmal angesehen hat. Genau die Sorte Sache, nach der zu suchen langweilig und die während einer Störung zu entdecken unangenehm ist.

## Zwei Dinge, bevor man einem Report glaubt

Ein Review durch einen Agenten ist immer noch ein Review, und es gelten dieselben zwei Regeln wie bei einem menschlichen.

**Prüfen, bevor man handelt.** Befunde kommen sauber formatiert und selbstsicher formuliert an, und diese Form ist unabhängig davon, ob sie stimmen. In unserem ersten Lauf stellte der Report fest, Logs existierten nur auf den Geräten und würden nirgendwohin geschickt. Werden sie, und zwar seit jeher — die Antwort stand in einem Teil einer API-Antwort, den der Agent bereits abgerufen und nicht zu Ende gelesen hatte. Gefangen wurde es, weil ein Mensch, der das Netz kennt, den Report las und widersprach. Jeder Befund ist eine Spur, kein Urteil: Die billige Gegenprobe ist der eine Screen in der Weboberfläche, auf den der Befund zeigt.

**Nichts gefunden heißt nicht, dass nichts da ist.** Das ist die Hälfte, die gern vergessen wird. Wir haben das Review ein zweites Mal mit strengerem Auftrag gefahren; dieser Lauf hat die Logging-Frage geklärt und einiges gefunden, was der erste übersehen hatte — aber er hat den Plattenplatz nie angesehen und deshalb nie erwähnt, dass die Log-Partition eines Knotens fast voll ist. Kein Fehler, keine falsche Aussage: eine Stelle, auf die niemand die Lampe gehalten hat.

Die praktische Konsequenz ist klein. Lass den Report seine eigene Abdeckung ausweisen — welche Tools er aufgerufen hat und welche Bereiche er ausgelassen hat und warum — und lies das vor den Befunden. Ein Agent kann nicht zuverlässig aufzählen, woran er nicht gedacht hat, aber er kann genau sagen, was er angefasst hat; die Differenz zwischen dieser Liste und der eigenen Landschaft bleibt die eigene Verantwortung.

## Was das nicht ersetzt

Es ist kein Penetrationstest und kein Compliance-Audit. Es sieht, was die API hergibt — viel, aber nicht alles: Ob ein Zertifikat tatsächlich auf der Leitung ausgeliefert wird, beantwortet man mit einer TLS-Verbindung, nicht mit einem Konfigurations-Flag. Und es ist eine Momentaufnahme: Es sagt, dass die beiden Knoten sich heute unterscheiden, nicht seit wann.

Was es ersetzt, ist der mühsame Vergleich, der es nie in irgendeine Arbeitswoche schafft.

## Am eigenen Paar ausprobieren

Der OPNsense-Connector ist eine YAML-Datei, die die API beschreibt, hinter einem Apache-2.0-Gateway, das man selbst betreibt: [DADL](https://dadl.ai) und [ToolMesh](https://www.toolmesh.io). Beide Firewalls als Backends eintragen, auf jeder einen API-Key anlegen, den Auftrag vom Anfang dieses Beitrags einfügen. Und dann den ersten Befund von Hand nachprüfen, bevor irgendetwas geändert wird.

Derselbe Auftrag funktioniert gegen ein NetBox, das sich von der Realität entfernt hat, gegen einen Alerting-Stack voller Regeln, die seit zwei Jahren niemand gelesen hat, gegen einen Switch-Bestand, eine Ticket-Queue — gegen alles, was eine API und eine Beschreibungsdatei davor hat. Dieser Beitrag ist der erste einer Serie, die diese Fälle nacheinander durchgeht; ein Folgebeitrag geht eine Ebene tiefer und behandelt, wie man den Auftrag formuliert, damit die Befunde halten.

Fragen, Korrekturen und Kriegsgeschichten sind in den [GitHub Discussions](https://github.com/DunkelCloud/ToolMesh/discussions) willkommen; wer das lieber als betriebene Instanz hätte, erreicht uns unter vertrieb@dunkel.cloud.