Der Zertifikatsfehler war die Firewall
TL;DR
- Die Zugangsdaten waren nachweislich richtig, trotzdem brach die Verbindung zu Cloud Connect mit einem Zertifikatsfehler ab.
- Ursache war die TLS-Inspection auf der Firewall des Kunden. Sie hat sich in die Verbindung gehängt und ein eigenes Zertifikat vorgelegt.
- Lösung: Die Ziele der Cloud-Connect-Umgebung vom Entschlüsseln ausnehmen. Und beim nächsten Mal früher daran denken.
Ein Kunde mit Hyper-V richtet seine erste Veeam Software Appliance ein, Version 13.1.1.18, frisch installiert. Die Sicherungen sollen zusätzlich außer Haus gehen, zu uns, angebunden über Cloud Connect. Der Kunde klickt selbst, wir leiten per Bildschirmfreigabe an.
Der Fehler, der nicht passte
Beim Hinzufügen des Service Providers kam ein Zertifikatsfehler. Die naheliegende Erklärung wäre gewesen: falsche Zugangsdaten oder ein Problem auf unserer Seite.
Beides war es nicht. Wir haben dieselben Zugangsdaten parallel in unserer eigenen Umgebung eingegeben, und dort ging die Verbindung sofort auf. Die Gegenstelle war also in Ordnung, die Zugangsdaten auch.
Regel um Regel
Also lag es am Weg dazwischen. Wir haben an der Firewall des Kunden Ports nachgezogen, Regeln angepasst und neu getestet. Mehrere Durchgänge lang. Der Fehler blieb jedes Mal derselbe.
Im Nachhinein ist klar, warum. Die Ports waren nie das Problem. Die Firewall ließ die Verbindung durch, nur eben nicht unverändert.
Was wirklich dazwischen war
Die Firewall des Kunden führte TLS-Inspection durch, auch SSL-Decrypt genannt. Dabei bricht sie verschlüsselte Verbindungen auf, schaut hinein und verschlüsselt sie mit einem eigenen Zertifikat neu. Für Browser funktioniert das, weil die Clients der Zertifizierungsstelle der Firewall vertrauen.
Der Backup-Server tut das nicht. Er erwartet das Zertifikat der Cloud-Connect-Umgebung und bekommt das der Firewall. Für ihn sieht das aus wie ein Angriff in der Mitte, und genau so soll er auch reagieren.
Die Lösung war eine Ausnahme: Die Ziele der Cloud-Connect-Umgebung werden nicht mehr entschlüsselt. Danach ging die Verbindung auf.
Was wir daraus mitnehmen
- Wenn die Zugangsdaten nachweislich funktionieren und der Zertifikatsfehler trotzdem bleibt, gehört TLS-Inspection ganz oben auf die Verdachtsliste. Nicht erst nach der dritten Firewall-Regel.
- Ein offener Port heißt nicht, dass die Verbindung unverändert ankommt.
- Ausnahmen vom Entschlüsseln eng fassen: nur die Ziele, die es brauchen, nicht ganze Netze.
- Vor dem Termin fragen, ob die Firewall des Kunden TLS-Inspection macht. Die Frage kostet eine Minute.
Was die Appliance sonst noch kann, auch abseits der Oberfläche, steht in Die Appliance kann mehr, als die Oberfläche zeigt .
Warum jetzt auf 13.1?
Gegen TLS-Inspection hilft keine Version. Die Ausnahme muss man an der Firewall selbst setzen. Aber 13.1 verkleinert die Fläche, auf der man so etwas suchen muss.
Bisher lief die Backup-Kommunikation über einen breiten dynamischen Portbereich, 2500 bis 3300. In 13.1 läuft sie über einen einzigen Port. Die REST API braucht keinen eigenen Port mehr und antwortet auf 443. Weniger Ports heißt weniger Regeln, und weniger Regeln heißt weniger Durchgänge, bis man merkt, dass es gar nicht an den Ports liegt.
Warum also jetzt? Wer eine Appliance neu aufsetzt oder die Firewall-Matrix für Veeam ohnehin anfassen muss, macht das einmal für 13.1. Mit einem Port statt eines Bereichs, und mit der Frage nach TLS-Inspection gleich auf der Liste.