3
Windows VPN - NLA ist Public statt Domain
Hallo Administratoren,
ich komme erneut mit einem Problem :X
Wir haben seit einem Jahr den Windows 10 AlwaysOn VPN über SCCM verteilt und bislang keine Probleme gehabt.
Seit heute, 10 Uhr, funktioniert der VPN bei den meisten nur noch bedingt.
Die Verbindung wird hergestellt, der NLA definiert das Netzwerk als Public und es werden keine DNS-Abfragen an unseren DC weitergeleitet. Meistens laufen die über den lokalen Router der Benutzer.
Testweise haben wir die Metrik des VPN-Adapters heruntergestuft, sodass er geringer ist als die des physischen Adapters.
Siehe da - es funktioniert - das Netzwerk wird als Domain definiert. Aber er leitet jetzt natürlich jeden Traffic von DNS Abfragen direkt über unseren DC... Was nicht so sauber ist.
Habt ihr da eventuell eine Idee, woran es liegen könnte?
Die Kerberos-Tickets kann er sich nicht holen, weil die Verbindung zum DC nicht funktioniert.
Den DC kann ich aber bspw. über nslookup | lserver DC.FQDN.net erreichen.
Wir sind schon am verzweifeln
Mit freundlichen Grüßen
Celiko
ich komme erneut mit einem Problem :X
Wir haben seit einem Jahr den Windows 10 AlwaysOn VPN über SCCM verteilt und bislang keine Probleme gehabt.
Seit heute, 10 Uhr, funktioniert der VPN bei den meisten nur noch bedingt.
Die Verbindung wird hergestellt, der NLA definiert das Netzwerk als Public und es werden keine DNS-Abfragen an unseren DC weitergeleitet. Meistens laufen die über den lokalen Router der Benutzer.
Testweise haben wir die Metrik des VPN-Adapters heruntergestuft, sodass er geringer ist als die des physischen Adapters.
Siehe da - es funktioniert - das Netzwerk wird als Domain definiert. Aber er leitet jetzt natürlich jeden Traffic von DNS Abfragen direkt über unseren DC... Was nicht so sauber ist.
Habt ihr da eventuell eine Idee, woran es liegen könnte?
Die Kerberos-Tickets kann er sich nicht holen, weil die Verbindung zum DC nicht funktioniert.
Den DC kann ich aber bspw. über nslookup | lserver DC.FQDN.net erreichen.
Wir sind schon am verzweifeln
Mit freundlichen Grüßen
Celiko
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 982502713
Url: https://administrator.de/forum/windows-vpn-nla-ist-public-statt-domain-982502713.html
Ausgedruckt am: 22.12.2024 um 06:12 Uhr
3 Kommentare
Neuester Kommentar
Hi
Was wurde den um 10 Uhr geändert?
Was wurde bisher probiert ?
Wurden neue öffentliche DNS Einträge gesetzt ?
NLA DNS Probe mal geprüft:
https://www.msxfaq.de/netzwerk/grundlagen/network_location_awareness.htm
Was kommt wenn du extern deine AD Domain aufrufst ? Sprich in den Browser AD.Domain.de eingibst ?
Was kommt zurück?
Welche Viren / Firewall Lösung setzt ihr ein ? Wurde hier was geändert ? Update? Mal deaktiviert?
Mal das letzte Windows Update deinstalliert ? WSUS / SCCM Console mal geprüft welches als letztes freigeben wurde bzw. wann laufen eure ADRs am SCCM?
Wurde was an einer Policy geändert ? Sollte sich am Timestampe nachweisen lassen ?
Mit freundlichen Grüßen Nemesis
Was wurde den um 10 Uhr geändert?
Was wurde bisher probiert ?
Wurden neue öffentliche DNS Einträge gesetzt ?
NLA DNS Probe mal geprüft:
https://www.msxfaq.de/netzwerk/grundlagen/network_location_awareness.htm
Was kommt wenn du extern deine AD Domain aufrufst ? Sprich in den Browser AD.Domain.de eingibst ?
Was kommt zurück?
Welche Viren / Firewall Lösung setzt ihr ein ? Wurde hier was geändert ? Update? Mal deaktiviert?
Mal das letzte Windows Update deinstalliert ? WSUS / SCCM Console mal geprüft welches als letztes freigeben wurde bzw. wann laufen eure ADRs am SCCM?
Wurde was an einer Policy geändert ? Sollte sich am Timestampe nachweisen lassen ?
Mit freundlichen Grüßen Nemesis
1
Nichts - keiner in der IT hat eine Änderung vorgenommen deshalb sind wir auch so verwirrt :D
Verringerung der Metrik des VPN Adapters kleiner als die des physischen Adapters hat geholfen (ist aber nicht die Ursache)
Werde mich morgen durcharbeiten - Diesen NLA habe ich noch nie wirklich verstanden ^^
Was kommt wenn du extern deine AD Domain aufrufst ? Sprich in den Browser AD.Domain.de eingibst ?
Was kommt zurück?
Kann nicht erreicht werden (respond took too long) - weder per IP noch per DNS
Die ADR laufen alle immer an einem Samstag.
Weitere Info:
In unserem VPN Profil haben wir angegeben, dass unsere Domäne ein TrustedNetwork ist und den DNS Suffix mitgegeben. Wir haben einen Split-Tunneling aktiv, der nur gewisse Netzwerke über den VPN jagen soll.
DNS Abfrage läuft standardmäßig über dem Router des Clients - wenn der DNS nicht gefunden wird fragt er unseren DNS.
Natürlich geht der Traffic direkt über den VPN Tunnel wenn der DNS Name im Cache bereits gespeichert ist.
Was wurde bisher probiert ?
Manuelle IP Vergabe, Neuinstallation, Überprüfung des VPN Profils, Installation auf Testclient (funktioniert)....Verringerung der Metrik des VPN Adapters kleiner als die des physischen Adapters hat geholfen (ist aber nicht die Ursache)
Wurden neue öffentliche DNS Einträge gesetzt ?
Auch DNS technisch keine Änderungen vorgenommenWerde mich morgen durcharbeiten - Diesen NLA habe ich noch nie wirklich verstanden ^^
Was kommt wenn du extern deine AD Domain aufrufst ? Sprich in den Browser AD.Domain.de eingibst ?
Was kommt zurück?
Welche Viren / Firewall Lösung setzt ihr ein ? Wurde hier was geändert ? Update? Mal deaktiviert?
Windows Defender | Dell NSA - Keine Veränderungen vorgenommen. Problem tritt nur bei einigen Clients auf - bei dem Großteil funktioniert es.Mal das letzte Windows Update deinstalliert ? WSUS / SCCM Console mal geprüft welches als letztes freigeben wurde bzw. wann laufen eure ADRs am SCCM?
Windows Update hat bei mehreren Clients seit dem 7.7.21 keine Updates installiert.Die ADR laufen alle immer an einem Samstag.
Wurde was an einer Policy geändert ? Sollte sich am Timestampe nachweisen lassen ?
Wir haben eine neue RDS-Farm 2019 produktiv eingeschaltet und haben eine Gegenpolicy für den RDS WebFeed erstellt, der alle Reste im Startmenü, Appdata und in der Registry löscht. Das ist eine Policy auf höchster Domänenebene, weshalb diese Änderung auszuschließen ist. Die Zeiteinstellungen bei den Clients ist gleich wie die unseres DC01 (NTP-Rolle). Kann jetzt aber nicht mehr erreicht werden, da DNS nicht funktioniert.Weitere Info:
In unserem VPN Profil haben wir angegeben, dass unsere Domäne ein TrustedNetwork ist und den DNS Suffix mitgegeben. Wir haben einen Split-Tunneling aktiv, der nur gewisse Netzwerke über den VPN jagen soll.
DNS Abfrage läuft standardmäßig über dem Router des Clients - wenn der DNS nicht gefunden wird fragt er unseren DNS.
Natürlich geht der Traffic direkt über den VPN Tunnel wenn der DNS Name im Cache bereits gespeichert ist.
Mit freundlichen Grüßen Nemesis
Grüße zurück, Celiko
Hi
Okay was passiert auf den wenigen betroffenen Clients bei einem ipconfig /flushdns ? Ggf mehrfach und dann ein gpupdate /force ?
Sind die clients bei einem anderen Internetanbieter, als da wo du den Ping probiert hast?
Hatte sowas mal bei der Telekom die haben statt der nicht auflösbaren Domain ne Werbeseite der Telekom bzw t-online geladen ... Fachbegriff entfallen wie diese Art der Domainumleitung beim Provider heißt.
Wie sieht es den bei AD Sites aus ist das richtige Netz für deine always on Client hinterlegt oder fehlt eine kleine Teilmenge ?
Da du schreibst nur ein Teil der Clients sind es immer die selben oder gibt sich das Problem ?
Ggf ein Admin doch ne GPO losgelassen und diese um sie zu "vertuschen" gelöscht ? Oder bist du die ganze IT
?
Sind die beiden im always on VPN angegebenen internen DNS Server erreichbar ? Oder gibt es hier DNS Fehler ?
Mit freundlichen Grüßen Nemesis
Okay was passiert auf den wenigen betroffenen Clients bei einem ipconfig /flushdns ? Ggf mehrfach und dann ein gpupdate /force ?
Sind die clients bei einem anderen Internetanbieter, als da wo du den Ping probiert hast?
Hatte sowas mal bei der Telekom die haben statt der nicht auflösbaren Domain ne Werbeseite der Telekom bzw t-online geladen ... Fachbegriff entfallen wie diese Art der Domainumleitung beim Provider heißt.
Wie sieht es den bei AD Sites aus ist das richtige Netz für deine always on Client hinterlegt oder fehlt eine kleine Teilmenge ?
Da du schreibst nur ein Teil der Clients sind es immer die selben oder gibt sich das Problem ?
Ggf ein Admin doch ne GPO losgelassen und diese um sie zu "vertuschen" gelöscht ? Oder bist du die ganze IT
?Sind die beiden im always on VPN angegebenen internen DNS Server erreichbar ? Oder gibt es hier DNS Fehler ?
Mit freundlichen Grüßen Nemesis
