GVC hängt bei „Acquiring IP“: Es ist kein Passwortproblem

Der Global VPN Client bleibt bei „Acquiring IP“ stehen, und der Reflex ist, das Passwort neu einzugeben oder den Client neu zu installieren. Beides berührt nicht die Stufe, die fehlgeschlagen ist. Die Authentifizierung war abgeschlossen, bevor der Client überhaupt eine Adresse angefragt hat, die Anmeldedaten halten Sie also nicht an dieser Zeile. Was Sie dort festhält, ist ein DHCP-Austausch, der nicht zu Ende gekommen ist, und er kann an drei verschiedenen Stellen hängen bleiben.

Authentifizierung und Adresszuweisung sind getrennte Stufen

GVC weist zuerst nach, wer Sie sind, und fordert dann die Einstellungen für seinen virtuellen Adapter gemäß der Ihrer Verbindung zugewiesenen Richtlinie an. Das sind aufeinanderfolgende Schritte mit unterschiedlichen Fehlermerkmalen. Schlechte Anmeldedaten scheitern meist früher, mit einer Authentifizierungs- oder Aushandlungsmeldung statt der Adresszeile.

Diese Reihenfolge erklärt, warum ein Passwort-Reset, ein neuer lokaler Benutzer oder eine Neuinstallation hier nichts ändern. Der Client ist bereits autorisiert; er wartet jetzt auf einen Lease, den das Gateway oder sein DHCP-Partner liefern muss. Selbst eine Richtlinie, die den Benutzer zulässt, aber keinen Adressbereich zuweist, erzeugt genau diesen Bildschirm.

Die erste nützliche Frage ist also nicht, ob die Anmeldedaten stimmen, sondern welche Richtlinie zugewiesen wurde und was sie über die Adressierung des virtuellen Adapters sagt. Lesen Sie die wirksame Konfiguration für diese Verbindung, nicht den funktionierenden Screenshot eines Kollegen.

Woher der Lease tatsächlich kommt

Zwei Modelle sind üblich. Die Firewall kann selbst einen DHCP-Bereich für VPN-Clients betreiben oder die Anfrage an einen externen DHCP-Server im internen Netz weiterleiten. Das Modell bestimmt, welche Protokolle zählen und wen man anruft.

Prüfen Sie beim internen Modell, ob der Bereich noch existiert, zur richtigen Schnittstelle gehört und freie Leases hat. Ein erschöpfter Bereich erzeugt einen Client, der sich einwandfrei authentifiziert und nie eine Adresse erhält, und das Gateway-Protokoll zeigt möglicherweise nur die Anfrage. Beim Relay-Modell müssen das Relay-Ziel, die Route zurück zum VPN-Client-Bereich und jede interne DHCP-Autorisierung zusammenpassen.

Notieren Sie, welches Modell Ihr Deployment verwendet, bevor Sie irgendetwas testen. Die Hälfte der widersprüchlichen Ratschläge online setzt das andere voraus.

Ein Tunnel kann stehen und den Lease trotzdem verlieren

Eine aufgebaute Steuerverbindung beweist, dass die Aushandlung funktioniert hat, nicht dass getunnelte Daten in beide Richtungen fließen. Der DHCP-Austausch braucht Anfrage und Antwort, die den Datenpfad überstehen, und dort liegen Verschlüsselungseinstellungen, die Richtlinie für die VPN-Zone und MTU-Probleme.

Der Rat zum NAT-Traversal ist das deutlichste Beispiel dafür, dass der Kontext zählt. Manche Pfade brauchen es aktiviert, andere funktionieren nur damit ausgeschaltet, und das dazwischenliegende NAT plus die ausgehandelte Verbindung entscheiden, was gilt. Es blind zu ändern, während Sie auch Client-Einstellungen ändern, bedeutet, dass Sie nicht wissen, welche Änderung das Ergebnis gebracht hat. Notieren Sie den ausgehandelten Pfad und die Belege, bevor Sie die Kapselung ändern.

Der Neustart des Heimrouters gehört in dieselbe Kategorie. Er beseitigt manchmal das Symptom, zeigt aber nicht, warum der Lease fehlschlug, und das Problem kehrt bei der nächsten Verbindung zurück.

Gehen Sie den Lease-Pfad der Reihe nach durch

Beginnen Sie am Adapter und arbeiten Sie sich nach außen, damit jeder Schritt nur aus einem Grund scheitern kann:

> Get-NetAdapter | Where-Object Name -like "*GVC*"
> ipconfig /all | findstr /i /c:"GVC" /c:"IPv4" /c:"DHCP"
> Test-NetConnection 10.60.0.1 -Port 443

Eine Adresse wie 169.254.x.x bedeutet, dass der Adapter existiert und überhaupt keine Antwort erhalten hat, was auf die Lease-Quelle oder den Datenpfad deutet. Eine korrekte Adresse im VPN-Bereich mit falschen DNS-Einträgen ist ein anderer Fehler: Der Lease hat funktioniert, und die Richtlinie lieferte unvollständige Einstellungen. Ein Adapter, der nie erscheint, bedeutet, dass der Client es nicht bis zu seiner Erstellung geschafft hat.

Sobald ein Lease erscheint, testen Sie die eigentliche Ressource, statt an der Adresszeile den Sieg zu erklären. Wenn der Datei- oder Intranetzugriff weiterhin fehlschlägt, behalten Sie den erfolgreichen Lease als Beleg und gehen Sie zur Namensauflösung oder Richtlinie über, denn Sie haben den ursprünglichen Fehler hinter sich gelassen.

SonicWalls Hinweis zum virtuellen Adapter listet mehrere getrennte Zweige auf, und seine älteren Screenshots sollten nicht als aktuelle Menükarte gelesen werden. Nutzen Sie ihn, um die erreichte Stufe zu bestätigen, nicht als Checkliste zum pauschalen Abarbeiten.