Auch nach vielfacher Kontrolle der IKE Proposals (IKEv2 in diesem Fall), lässt sich ein VPN-Tunnel manchmal partout nicht aufbauen. Das ist uns ein paar mal bei Gegenstellen von Palo Alto begegnet – was aber Zufall sein mag. IPSEC Implementierungen gibt es viele. Auf der Lokalen Seite waren es verschiedene Setups, darunter Lancom, SonicWall, Sophos und ein nativer strongSwan.
Der Tunnelaufbau scheitert direkt in Phase 1, nachdem die Encryption Proposals akzeptiert wurden:
Message: IKEv2 Initiator: Proposed IKE ID mismatch Notes:VPN Policy: POLICYNAME; id <IP>, does not match peer IKE id in policy
Lösung
Die lokale und remote IKE ID müssen vom Typ IP(v4) sein und eine IP(v4) Adresse enthalten.
RFC 7296 definiert für IKEv2 sieben verschiedene ID Typen (Peer ID / Local ID). DArunter FQDN, ASN Identifier, IPv6 und weitere. Aber es gibt einen spannenden „should“ Passus, der die Kompatibilität der Verhandlung potenziell einschränkt:
To assure maximum interoperability, implementations MUST be configurable to send at least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be configurable to accept all of these four types. Implementations SHOULD be capable of generating and accepting all of these types.
Genau das macht Palo Alto nicht: Die (heute) aktuellen Geräte unterstützen nur einen einzigen Typ: IPv4 (einzelne IP-Adresse). Ob das ein RFC-Verstoß ist, ist eine Frage der Rhetorik, denn die Typen „sollen“ ja auch nur unterstützt werden. MÜSSEN konfigurierbar sein (unserer Ansicht nach auch eher zweifelhaft), SOLLEN aber gesendet und empfangen werden können.
Alle anderen Typenkombination (die wir ausprobiert haben) scheiterten. Auch wenn das ID-Feld in Panorama wie ein „String“ Feld aussieht und sich (eingabetechnisch) auch so verhält – der Typ der im IKE-Paket ausgegeben wird, ist immer „IP“. Stell man beide Seiten auf IP, geht der Tunnel (mit diesem Fehler) sofort auf.
Nach dem Update auf Version 13 startet die Veeam Backup & Replication Konsole in der Regel nicht mehr.
Das Verbindungs-Fenster meckert stattdessen:
Failed to connect to the backup server: Access to the
registry key 'HKEY_LOCAL_MACHINE\SOFTWARE\Veeam
\Veeam Backup and Replication\Plugins' is denied.
Lösung
Auf den genannten Registry-Schlüssel braucht man nur die Berechtigung „Lesen“ für „Authentifizierte Benutzer“ zu vererben und schon geht die Konsole (für jeden Benutzer des Computers) wieder fehlerfrei auf.
HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\Plugins
Nach dem Upgrade der VMware Tools auf Version 13 (0.1.0+) startet der „VMware Tools“ Dienst auf virtuellen Maschinen (VMs) unter Windows Server 2019 nicht mehr. Versucht man das manuell, sieht man im Anwendungs-Ereignisprotokoll die Meldung:
Name der fehlerhaften Anwendung: vmtoolsd.exe, Version: 13.0.5.0,
Name des fehlerhaften Moduls: MSVCP140.dll, Version: 14.36.32532.0,
Ausnahmecode: 0xc0000005
Fehleroffset: 0x0000000000012f58
ID des fehlerhaften Prozesses: 0x2b8
Pfad der fehlerhaften Anwendung: C:\Program Files\VMware\VMware Tools\vmtoolsd.exe
Pfad des fehlerhaften Moduls: C:\Windows\SYSTEM32\MSVCP140.dll
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:
Lösung
Die jeweils aktuelle Microsoft Visual C++ Redistributable (14) installieren und neu starten.
Bereits ab vSphere 6.7 kann man ein virtuelles Trusted Platform Module (vTPM) zu VM Gästen hinzufügen. Damit können Gastbetriebssysteme ihre privaten Schlüssel in einem „physischen“ (meint: VM-Hardware) TPM 2.0-Chips erstellen und speichern. Für den Gast ist das vollständig transparent, dieser kann nicht feststellen das er nicht mit einem „echten“ TPM spricht.
Der wesentliche Vorteil von vTPM ist, dass im ESXi-Host kein physischer TPM-Chip eingebaut sein muss. Server-TPMs sind ja auch nicht gerade günstig. Die Secrets aus dem vTPM wiederum werden (verschlüsselt) in der .nvram Datei des ESXi zu jeder VM einzeln und lokal abgelegt.
Die Verschlüsselungsschlüssel für das vTPM selbst wird von einem „Schlüsselanbieter“ verwaltet. Das kann ein externer (KMIP) Key Provider (SKP) oder der im vCenter integrierte Native Key Provider (NKP) sein. Die (zentrale) Verwaltung der Schlüsselanbieter erfordert aber eigentlich immer den Einsatz des vCenters. Windows 11 auf einem ESX-Standalone Host als Gast zu betreiben ist also eigentlich nicht möglich.
Interessanterweise nutzt das vCenter zur Verwaltung nur public vSphere-APIs, die auf ESXi-Hosts verfügbar sind um Schlüssel hinzuzufügen oder zu entfernen. Die Funktionen zur Verwaltung der Schlüssel ist aber ESXi Bestandteil. Das bedeutet, man kann das auch manuell machen: nicht so komfortabel wie ein vCenter Server, aber trotzdem vTPM für VMs auf eigenständigen (Standalone) ESXi-Hosts.
vSphere Master Willian Liam hat dazu einen fantastischen Artikel geschrieben und ein PowerShell-Script erstellt, das einem den Großteil der Arbeit abnimmt.
vTPM auf einem ESXi Host aktivieren, ohne Neustart
⚠️ Wichtig: Nach dieser Prozedur starten VMs nach einem ESX Reboot nicht mehr. Man muss sich um die Schlüsselpersistenz der TPM-Keys selbst kümmern (siehe weiter unten).
vmWare PowerCli Module installieren und importieren, sofern noch nicht geschehen: Install-Module VMware.PowerCLI Import-Module VMware.PowerCLI
PowerCLI mit dem ESXi-Host verbinden: Connect-VIServer -Server ESX.EXAMPLE.COM
Den TPM-Provider einrichten, also den lokalen Host für den Anbieter vorbereiten: Prepare-VMHostForEncryption
Einen ESXi Hostschlüssel erzeugen: New-InitialVMHostKey -Operation CREATE -KeyName "esx10-key-1" ⚠️ Diesen Vorgang nur ein einziges Mal durchführen!
vTPM Schlüssel für VMs erstellen: New-VMTPMKey -Operation CREATE -KeyName "windows-11-key"
Und endlich kann man das vTPM zu den VMs (jeweils einzeln) hinzufügen: Reconfigure-VMWithvTPM -KeyName "windows-11-key" -VMName "EXAMPLE-VM"
⚠️ Schlüsselpersistenz – Schlüssel nach (ESX-) reboots wiederherstellen
Standardmäßig speichert ESXi leider keine Verschlüsselungsschlüssel über einen Neustart hinweg. Man muss alle Host- und VM-Schlüssel nach einem Neustart erneut hinzufügen, sonst lässt sich eine solche VM nicht mehr starten.
Dies ist der Hauptvorteil des vCenters: Das Management des SKP (oder NKP) und der bereitgestellten Schlüssel für die ESXi-Hosts und VMs.
Als Workaround gibt es eine „automatische“ Sicherung der Verschlüsselungsschlüssel im Script. Das CSV-Backup wird bei der Generierung von Host- oder VM-Schlüsseln erstellt. Die Datei heißt tpm-keys.csv und sollte DRINGEND gut gesichert abgelegt werden Mit dieser Sicherungsdatei kann man alle Schlüssel (nach reboots) problemlos wieder auf den ESXi-Host importieren.
Wenn man über einen echten physischen TPM2.0 Chip verfügt (FIFO Modus, nicht CRB – bei HPE-Servern im BIOS umstellen!), kann man die „Schlüsselpersistenz“ im ESXi aktivieren. Damit werden die Schlüssel automatisch auf dem TPM-Chip gespeichert.
Wenn man keinen physischen TPM Chip hat, muss man sicherstellen, dass die Sicherungskopie der Host- und VM Schlüssel vorhanden ist. Nach dem Reboot kann man diese einfach wieder importieren. Man verbindet sich mit dem Host (siehe oben) und importiert die CSV wieder:
Den Erfolgt des Imports kann man jederzeit mit Get-VMHostTPMKeys kontrollieren.
🆘Hinweis zu Windows 11, wenn es nicht mehr bootet
Wenn eine Windows 11 VM nicht mehr neu starten sollte, weil man kein Backup der Schlüssel mehr hat:
VM aus der Bestandsliste entfernen (de-registrieren)
Die VMX Datei der VM manuell bearbeiten
Alle Zeilen, die mit dem vTPM zu tun haben löschen: vtpm.ekCSR vtpm.ekCRT vtpm.present encryption.keysafe encryption.data
Dann die VM (*.vmx) erneut zur Bestandsliste hinzufügen
Die VM hat dann zwar eine neue ID bekommen und muss (wahrscheinlich) erneut zur Datensicherungslösung hinzugefügt werden, bootet aber wieder problemlos.
