Problem bei Windows Firewall Profilwechsel LAN-WiFi-LAN

[codeslayer 10]

Wir haben auf 2 neuen Notebooks (Lenovo ThinkBook 16p G4 IRH) ein Probleme mit der Profilerkennung auf der Windows Firewall. Es ist mir nur durch Zufall aufgefallen und auf anderen Notebooks haben wir das Problem nicht. Auch auf den >40 PCs wird das Profil richtig auf "Domain" eingestellt.

 

Wenn man von LAN auf WiFi wechselt (zB. durch abstecken von der Docking Station, oder auch Ethernet-Adapter) ist alles ok und das Profil "Domain network" wird beibehalten.

Aber wenn man dann wieder zurückkommt, ansteckt und das LAN als Primär-Verbindung erkannt wird, wechselt das Profil auf "Public network" und bleibt dort (für lange Zeit). Obwohl der Datenverkehr über das LAN Netzwerk läuft, Domain Controller richtig erkannt werden und Wifi nicht in Betrieb ist.

Am Anfang hatte es auch den Anschein, als ob es fix auf Public bleiben würde, aber so nach 10-20 Min (Screen off) oder nach eine wakeup aus dem Sleep, scheint die Firewall es langsam mitzubekommen und wechselt dann doch aufs Domain Profil. Nach dem Sleep sind dann beide Profile "connected", dann geht das Public aber auf "not connected" und das Domain-Profil bleibt dann.

 

Beim Herumprobieren habe ich zufällig 2 fixes gefunden:
Variante 1: WiFi vor dem LAN anschließen disablen (Notebook ist kurzfristig ohne Netzwerk) - das LAN wird dann richtig als "Domain network" erkannt, danach kann das WiFi wieder enabled werden.
Variante 2: Wenn Notebook schon am LAN hängt und die FW auf "Public" steht: LAN und WiFi disablen, LAN enablen und nach paar Sekunden WiFi wieder enables.

Variante 3: Rechner in den Sleep legen und wieder aufwecken.

OS: Win 11 Pro, 22H2 / Build: 22621,2428 (OS direkt von einem Lenovo Image installiert)

 

[NorbertFe 1.805]

Variante 4: nla Service durchstarten? 

[Sunny61 773]

Es gibt eine Einstellung um das WiFi bzw. das LAN abzuschalten, wenn das andere verbunden ist. Setz doch die Einstellung mal und probier es nochmal.

bearbeitet 17. November 2023 von Sunny61

[daabm 1.185]

Bin bei Norbert: nla durchstarten hilft. Geht notfalls per geplantem Task mit Trigger auf noch zu ermittelnde Events (gibt Eventlogs für wired und wifi, sollte sich was finden lassen).

[Weingeist 157]

NLA startet man aber nicht (mehr) ohne so weiteres durch. Ist mittlerweile ein geschützter Dienst bei neueren Builds. Den kannst nur mit taskkill und entsprechenden Berechtigungen zur Aufgabe zwingen. Starten tut er wieder selbst. Ob das aktuell immer noch so ist oder ob das wieder geändert wurde, habe ich schon ein weilchen nicht mehr getestet.

 

Ansonsten hilft in der Regel folgendes vorgehen:

Fixe IP: Adapter deaktivieren/aktivieren den man zum Update von NLA zwingen will

Dynamische IP: ipconfig /renew  reicht aus. Also auch für einfache Benutzer machbar. (allenfals Adapterspezifisch) oder eben auch Adapter Aktivieren/Deaktivieren. Letzteres seit geraumer Zeit nicht mehr 100% zuverlässig, warum, keine Ahnung. Meine Scripts mit Aktivieren/Deaktivieren funktionieren jedenfalls nicht mehr zuverlässig.

 

Was wohl nachhaltig gegen NLA-Ärger hilft: Komplette Neuinstallation mit aktueller ISO und integrierten Updates von MS. Meine neueren Installationen machen jedenfalls keinen Ärger. Oder noch nicht

 

Die ganzen Tipps bezüglich passive/active probing sind fast immer für die Tonne bei neueren Builds. Am besten funktionierts mit Werkseinstellungen und allenfalls angpassten Zielen für den Connectionstest etc.

 

Was auf meiner Todo-Liste steht: Auswerten was bei ipconfig /renew oder aktivieren/deaktivieren alles an Registry Werten geändert wird. Allenfalls wird da irgend ein Counter hochgestuft welcher von NLA geprüft wird. Wo wir wieder beim triggern wären.

 

Ich bin mir fast sicher, dass es irgend einen WMI-Befehl geben wird, welcher ein Update eines Netzadapters oder sonstigen Entscheidungsgrundlagen für den NLA anstossen kann. Gibts ja für fast alles. Das wäre dann zuverlässig. Ich selber habe leider zu wenig Ahnung von WMI um mich da durchzuwühlen. Allenfalls hat auch der NLA-service versteckte Befehle mit dem man ihn triggern könnte bis anhin bin ich aber nicht auf entsprechende Quellen gestossen.

 

Vielleicht erbarmt sich ja mal jemand mit Connections zu MS um ein Paper zur genauen Funktionsweise von NLA zu erhalten und allenfals Trigger die man manuell anstossen könnte.

[codeslayer 10]

Mir ist mittlerweile aufgefallen, dass es dieses Problem nur bei der Windows 11 version 22H2 auftaucht, bei 21H2 war es noch nicht.

Wenn das Notebook auf sleep geht und wieder aufgeweckt wird stellt es sich meistens auch richtig ein.

 

Das Neustartten des NLA service wäre ja auch nur ein temporärer workaround, weil das Problem je jedes Mal beim Netzwerkwechsel von WiFi auf LAN auftaucht.

 

Mittlerweile hab ich dem User dieses skript zur Verfügung gestellt:

 

etsh interface set interface "Ethernet" disable
netsh interface set interface "Wi-Fi" disable
netsh interface set interface "Ethernet" enable
timeout 3
netsh interface set interface "Wi-Fi" enable

 

 

Hintergründe:

Unsere User müssen manchmal vom home-office per vpn+remotedesktop auf ihre Rechner in der Firma zugreifen. Damit das funktioniert muss der Rechner im Domain netzwerk sein denn nur dann wird bei der Firewall der RDP port geöffnet. Wenn der User dann vor dem Verlassen des Büros vergisst das Skript auszuführen und vorher mit dem WiFi verbunden war, wird die Kategorie falsch erkannt und geht auf Public statt Domain.

 

Aktuell sehe ich das Problem eher beim Windows weil sich da offensichtlich etwas geändert hat. Vielleicht liegt es auch an irgendeinem Timing der beteiligten Treiber.

 

Ich wundere mich nur, dass es bis jetzt noch nie jemandem aufgefallen ist und so ein spezielles Netzwerk und Userverhalten haben wir ja auch wieder nicht. Auf den Windows 10 Notebooks funktioniert es eigentlich auch richtig.

 

 

 

 

Am 23.11.2023 um 16:22 schrieb Weingeist:

Was wohl nachhaltig gegen NLA-Ärger hilft: Komplette Neuinstallation mit aktueller ISO und integrierten Updates von MS. Meine neueren Installationen machen jedenfalls keinen Ärger. Oder noch nicht

 

Das Notebook ist schon 2x neu mit verschiedenen ISOs neu installiert worden. Einmal mit der offiziellen Microsoft ISO und einmal mit der ISO von Lenovo für dieses Notebook. Der Fehler tritt bei Win 11 22H2 immer auf und ist 100% reproduzierbar.

[Weingeist 157]

vor 10 Stunden schrieb codeslayer:

Ich wundere mich nur, dass es bis jetzt noch nie jemandem aufgefallen ist und so ein spezielles Netzwerk und Userverhalten haben wir ja auch wieder nicht. Auf den Windows 10 Notebooks funktioniert es eigentlich auch richtig.

Och, das Netz ist voll von Ärger die NLA betreffen.   Entweder schraubt MS da immer dran rum oder das Teil "erarbeitet" sich irgendwelche Werte auf deren Basis es dann zukünftige Reaktion macht. Oder es ändern sich Bedingungen die zu unterschiedlichem Verhalten führen. Ich sage ja, es wäre äusserst hilfreich wenn jemand eine Doku zu NLA besorgen könnte.

 

Die Reihenfolge der Netzwerkadapter inklusive der ausgeblendeten spielt wohl auch irgend eine Rolle. Hatte es vor Jahren in einer Umgebung vollständig im Griff. Ohne jegliche Scripts, verzögerung des NLA-Starts etc. Dann kam das VMXNET3 Adapter Update welche alle Netzadapter gelöscht und neu installiert hat (inklusive neuer MAC's war "interessant"). Danach reagierte die Umgebung identisch wie alle anderen. Überreste vom alten Adapter verblieben damals in der Registry.

Auch die Wartungsadapter von z.B. der Intel ME scheinen einen Einfluss zu haben.

 

Wie auch immer, es bleibt für mich zu undurchsichtig. Daher habe ich es aufgegeben. Und das einzig zuverlässig ist das Deaktivieren/aktivieren der Netzadapter oder ein anderweitig angestossenens "Update" des Netztadapters wie das "aufwachen" oder sofern möglich "ipconfig /renew".

Schön wärs wenn man ein Update bei fixen IP's anstossen könnte ohne den Adapter zu deaktivieren.

 

Noch schöner wenn man das Verhalten schon vor dem Start beeinflussen könnte. Alle Maschinen die es nämlich von Haus auf können, haben z.B. die Computerrichtlinien-GPO's innerhalb 1-2 Sekunden verarbeitet, bei den anderen dauert es so 5-10 Sekunden. Gleicher Host, gleiche Hardware-Version, gleiche Netzwerkkarte.

[Sunny61 773]

vor 4 Stunden schrieb Weingeist:

Schön wärs wenn man ein Update bei fixen IP's anstossen könnte ohne den Adapter zu deaktivieren.

IPV6 de- und wieder aktivieren oder andersrum, wenn IPV6 angehakt ist.

[daabm 1.185]

Es reicht schon, einer NW-Karte eine verbindungslokale IPv6 zu verpassen - auch das triggert NLA. Und ja, der Mechanismus hat deutlich "Luft nach oben" - vor allem wenn man im öffentlichen Profil Outbound blockt und nur zulässt, was zur DC-Etkenneung "angeblich" erforderlich ist. Und nein, was man dazu im Netz findet, reicht nicht.