FRITZ!Box VPN mit Windows 11 – Nicht ohne Hürden (Teil 1)

Ein Upgrade auf Windows 11 zum Jahreswechsel – mit unerwarteten Folgen für die VPN-Anbindung

Es sind nun 7 Jahre vergangen, seit ich den Artikel zum VPN-Zugang über die FRITZ!Box geschrieben habe. In dieser Zeit hat sich einiges an meinem Arbeitsrechner sowie dem Internet-Gateway zuhause getan. Der Wechsel des Betriebssystems von Windows 7 auf Windows 10, ein neues Notebook sowie die Wechsel von Fritz!Box 7362 auf Fritz!Box 7430 und später auf Fritz!Box 7530. Dabei blieb eines stets unverändert – die sichere und stabile Verbindung mittels VPN in das heimische Netz über den AVM-Router. Dann kam Windows 11.

Ende des vergangenen Jahres stand ein Betriebssystem-Upgrade von Windows 10 auf Windows 11 für mein Firmennotebook an. Der Upgrade-Prozess verlief problemlos. Alle zuvor auf dem Rechner vorhandenen Daten und Programme waren nach Abschluss des Betriebssystemwechsels weiterhin nutzbar – zumindest augenscheinlich.

Abbildung 1 – Notebook-Setup vor und nach dem Windows 11 Upgrade

An meinem ersten Arbeitstag im neuen Jahr schloss ich das Notebook mit dem neuen Betriebssystem zum ersten Mal kabelgebunden (interne Netzwerkkarte I219-V von Intel) an das Firmennetz an. Das System startete normal, jedoch verweigerte die Netzwerkanbindung den Dienst – aber warum? Ich überprüfte zunächst die IP-Konfiguration an der Schnittstelle des Notebooks, um sicherzugehen, dass ich versehentlich keine feste Adresse eingetragen hatte. Dem war nicht so. Sowohl IP-Adress- als auch DNS-Serverzuweisung waren erwartungsgemäß automatisch auf DHCP gesetzt. In der Kommandozeile von Windows 11 ließ ich mir per ipconfig /all die entsprechenden Adressinformationen anzeigen und wurde fündig. Die Netzwerkschnittstelle hatte eine 169.254.0.0/16 IP-Adresse – eine Adresse aus dem Link Local Adressraum. Das von Windows unterstützte Automatic Private IP Addressing (APIPA) erlaubt einem Computer für den Fall, dass ein DHCP-Server nicht verfügbar oder vorhanden ist, sich selbst eine IP-Adresse aus diesem Range zuzuweisen. Der Fehler lag demnach in der gestörten Kommunikation zwischen der Netzwerkschnittstelle des Notebooks und dem DHCP-Server. Nun wurde es interessant und der IT-Administrator wurde eingeschaltet. Die gemeinsame Fehlersuche begann auf Layer 1. Wir stellten sicher, dass die physikalische Anbindung zwischen der Firmenfirewall, die zusätzlich als DHCP-Server agiert, über die Verkabelung bis zum NIC des Laptops in Ordnung war. Eine fehlerhafte Konfiguration im Firmennetzwerk wurde ebenfalls ausgeschlossen, da hier keine administrativen Änderungen stattgefunden hatten. Ich deaktivierte vorübergehend die windowseigene Firewall und den Virenschutz, jedoch blieb ich weiterhin ohne Netzwerkanbindung. Ich setzte die NIC zurück und überprüfte den Treiber auf Aktualität. Jedoch blieben auch diese Versuche erfolglos. „Irgendetwas grätscht in die Netzwerkkonfiguration der NIC rein“, so der IT-Admin – aber was? Mir fiel in der Übersicht zu meinen Netzwerkverbindungen eine Anzahl an virtuellen NICs auf, die vor längerer Zeit bei der Installation meiner Hypervisor Virtualbox und VMWare Workstation Player angelegt worden waren. Um die virtuellen NICs als mögliche Fehlerursache auszuschließen, entschied ich mich für eine Deinstallation der besagten Anwendungen.

Doch auch diese Maßnahmen brachten nicht den erhofften Erfolg. So grub ich mich tiefer rein in die Fehlersuche und hielt Ausschau nach weiteren Anwendungen und Diensten, die in Wechselwirkung mit der Konfiguration der Netzwerkschnittstelle stehen konnten. Mittlerweile meldete sich unser freundlicher IT-Admin wieder. Er hätte einen neuen Laptop, der schon fast fertig konfiguriert sei, auf seinem Schreibtisch liegen. Ich müsste nur meine Daten vom alten Notebook rüber kopieren. Kein schlechter Trost, eine neue, schnellere Hardware im Austausch für den nun etwas mehr als drei Jahre alten ThinkPad X390 Yoga. Doch der Ehrgeiz hatte mich gepackt – für eine Resignation war es mir noch zu früh. Es müsste doch möglich sein, den Fehler zu finden, ohne das System neu aufsetzen oder gar austauschen zu müssen.

Ich klickte mich durch die verschiedenen Eigenschaften der NIC, scrollte durch etliche Einstellungen und überprüfte die entsprechenden Parameter. Irgendwo muss er doch sein, ein falscher Wert, ein störendes Häkchen, irgendetwas, was die Netzwerkkarte daran hinderte, sich erfolgreich zu verbinden. Plötzlich fiel mein Blick auf einen Eintrag: Shrew Soft Lightweight Filter, ein Netzwerkdienst, der bei der Installation des VPN-Clients des Herstellers Shrew Soft Inc. angelegt und eingerichtet wurde. Mein treuer Begleiter, „Long time no see“. Freilich nutze ich ihn jedes Mal, wenn ich den zugehörigen VPN-Client startete, doch stets blieb er im Hintergrund und verrichtete seinen Dienst tadellos.

Abbildung 2: Verbindungselement “Shrew Soft Lightweight Filter” in den Eigenschaften der Netzwerkkarte

Ich beschloss, das Häkchen am besagten Netzwerkdienst zu entfernen, um zu sehen, ob es einen Einfluss auf den Verbindungsaufbau zum Firmennetzwerk hatte. Bingo! Kaum war der Dienst mit dem Entfernen des Häkchens deaktiviert und mit OK quittiert, verband sich die Netzwerkkarte anstandslos mit dem DHCP-Server, von dem sie eine IP-Adresse zugewiesen bekam. Der Übeltäter war gefunden – oder doch nicht?

Im zweiten Teil folgt die Auflösung.