12
DNS Probleme nach VPN-Verbindung Lancom
Hallo zusammen,
ich bin hier gerade etwas am Verzweifeln.
Hier ist eine Lancom Firewall UF-360 im Einsatz welche auch als IKEV2 VPN-Gateway fungiert.
Die VPN-Verbindnungen auf den Windows-Clients erfolgen durch den Lancom Advanced VPN-Client.
DNS-Server und DHCP auf einem MS-Server 2019.
Der VPN-Tunnelaufbau funktioniert einwandfrei, allerdings habe ich das Problem, dass nach Abbau der VPN-Verbindung der Client sich nicht mehr am AD authentifiziert.
VPN-Verbindung wird über eine WLAN-Verbindung im Homeoffice aufgebaut, in der Firma dann per Kupfer.
Folgende Beobachtung:
Wenn die VPN-Verbindung abgebaut ist, und der Client ans Firmen-LAN angeschlossen wird, erhält die Netzwerkschnittstelle vom DHCP die richtige IP-Adresse, aber ich habe keinen Zugriff auf die Domäne, die Netzwerkverbindung indentifiziert sich auch nicht an der Domäne (statt firma.local steht dort dann "Netzwerk 5") und Netzwerk-Typ ist "öffentlich".
Die Netzwerkidentifizierung dauert auch recht lange.
Dies ist auch zu beobachten, wenn die Netzwerkschnittstelle eine fixe Adresse statt DHCP erhält.
Wenn dieser Status vorhanden ist, kann ich unser Gateway anpingen (xxx.xxx.xxx.10) , die DNS-Server (xxx.xxx.xxx.100 + xxx.xxx.xxx.110) jedoch nicht.
In der Ereignisanzeige erhalte ich auch den DNS Fehlereintrag 8015.
Nach manuellem "Rückstellen" (fixe IP Adresse vergeben, dann wieder auf DHCP) funktioniert dieses wieder,
oder nach manuellem Deaktivieren / Aktivieren.
Aber das kann ja nicht richtig sein.....
Gibt es hier irgendetwas was ich übersehen habe?
Besten Dank und Gruß
Jan
ich bin hier gerade etwas am Verzweifeln.
Hier ist eine Lancom Firewall UF-360 im Einsatz welche auch als IKEV2 VPN-Gateway fungiert.
Die VPN-Verbindnungen auf den Windows-Clients erfolgen durch den Lancom Advanced VPN-Client.
DNS-Server und DHCP auf einem MS-Server 2019.
Der VPN-Tunnelaufbau funktioniert einwandfrei, allerdings habe ich das Problem, dass nach Abbau der VPN-Verbindung der Client sich nicht mehr am AD authentifiziert.
VPN-Verbindung wird über eine WLAN-Verbindung im Homeoffice aufgebaut, in der Firma dann per Kupfer.
Folgende Beobachtung:
Wenn die VPN-Verbindung abgebaut ist, und der Client ans Firmen-LAN angeschlossen wird, erhält die Netzwerkschnittstelle vom DHCP die richtige IP-Adresse, aber ich habe keinen Zugriff auf die Domäne, die Netzwerkverbindung indentifiziert sich auch nicht an der Domäne (statt firma.local steht dort dann "Netzwerk 5") und Netzwerk-Typ ist "öffentlich".
Die Netzwerkidentifizierung dauert auch recht lange.
Dies ist auch zu beobachten, wenn die Netzwerkschnittstelle eine fixe Adresse statt DHCP erhält.
Wenn dieser Status vorhanden ist, kann ich unser Gateway anpingen (xxx.xxx.xxx.10) , die DNS-Server (xxx.xxx.xxx.100 + xxx.xxx.xxx.110) jedoch nicht.
In der Ereignisanzeige erhalte ich auch den DNS Fehlereintrag 8015.
Nach manuellem "Rückstellen" (fixe IP Adresse vergeben, dann wieder auf DHCP) funktioniert dieses wieder,
oder nach manuellem Deaktivieren / Aktivieren.
Aber das kann ja nicht richtig sein.....
Gibt es hier irgendetwas was ich übersehen habe?
Besten Dank und Gruß
Jan
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: 1978623881
Url: https://administrator.de/forum/dns-probleme-nach-vpn-verbindung-lancom-1978623881.html
Ausgedruckt am: 03.01.2025 um 01:01 Uhr
12 Kommentare
Neuester Kommentar
Zitat von @japper:
Der VPN-Tunnelaufbau funktioniert einwandfrei, allerdings habe ich das Problem, dass nach Abbau der VPN-Verbindung der Client sich nicht mehr am AD authentifiziert.
Der VPN-Tunnelaufbau funktioniert einwandfrei, allerdings habe ich das Problem, dass nach Abbau der VPN-Verbindung der Client sich nicht mehr am AD authentifiziert.
Heißt der Benutzer trennt zuhause die VPN Verbindung, nimmt seinen Client (noch immer eingeschaltet) mit in die Firma und verbindet den dann dort via LAN Kabel mit dem Firmen-Netzwerk?
Oder wird der Client heruntergefahren?
VPN-Verbindung wird über eine WLAN-Verbindung im Homeoffice aufgebaut, in der Firma dann per Kupfer.
Folgende Beobachtung:
Wenn die VPN-Verbindung abgebaut ist, und der Client ans Firmen-LAN angeschlossen wird, erhält die Netzwerkschnittstelle vom DHCP die richtige IP-Adresse, aber ich habe keinen Zugriff auf die Domäne, die Netzwerkverbindung indentifiziert sich auch nicht an der Domäne (statt firma.local steht dort dann "Netzwerk 5") und Netzwerk-Typ ist "öffentlich".
Die Netzwerkidentifizierung dauert auch recht lange.
Folgende Beobachtung:
Wenn die VPN-Verbindung abgebaut ist, und der Client ans Firmen-LAN angeschlossen wird, erhält die Netzwerkschnittstelle vom DHCP die richtige IP-Adresse, aber ich habe keinen Zugriff auf die Domäne, die Netzwerkverbindung indentifiziert sich auch nicht an der Domäne (statt firma.local steht dort dann "Netzwerk 5") und Netzwerk-Typ ist "öffentlich".
Die Netzwerkidentifizierung dauert auch recht lange.
Das klingt nach fehlerhafter Network Awareness (NLA Dienst). Versuche mal bitte den genannten Dienst am Client neu zu starten, nachdem er wieder im Firmennetzwerk hängt.
Hat der Domänen-Controller denn das Richtige bei seiner Netzwerkverbindung da stehen (z.B. mein.firma.de)?
Gruß
Marc
Blöde Frage....DNS holt sich der Client auch per DHCP?
Ansonsten Workaround über den VPN-Vlient.
Da sollte man doch in den Verbindungsoptionen auch Batches starten (externe Anwendung starten) können. Und da gabs als Trigger auch das nach Verbindungsabbau.
Da mal per ipconfig den DNS raushauen und neu holen lassen. (release, renew, flushdns)
Ist aber schon lange her, dass ich den Client mal gesehen hab. Insgesamt würde ich das auf den Client schieben. Lancom ist oftmals sehr gut, solange es funktioniert. Fehlersuche oft die Hölle.
Ansonsten Workaround über den VPN-Vlient.
Da sollte man doch in den Verbindungsoptionen auch Batches starten (externe Anwendung starten) können. Und da gabs als Trigger auch das nach Verbindungsabbau.
Da mal per ipconfig den DNS raushauen und neu holen lassen. (release, renew, flushdns)
Ist aber schon lange her, dass ich den Client mal gesehen hab. Insgesamt würde ich das auf den Client schieben. Lancom ist oftmals sehr gut, solange es funktioniert. Fehlersuche oft die Hölle.
Zitat von @radiogugu:
Heißt der Benutzer trennt zuhause die VPN Verbndung, nimmt seinen Client (noch immer eingeschaltet) mit in die Firma und verbindet den dann dort via LAN Kabel mit dem Firmen-Netzwerk?
Oder wird der Client heruntergefahren?
Zitat von @japper:
Der VPN-Tunnelaufbau funktioniert einwandfrei, allerdings habe ich das Problem, dass nach Abbau der VPN-Verbindung der Client sich nicht mehr am AD authentifiziert.
Der VPN-Tunnelaufbau funktioniert einwandfrei, allerdings habe ich das Problem, dass nach Abbau der VPN-Verbindung der Client sich nicht mehr am AD authentifiziert.
Heißt der Benutzer trennt zuhause die VPN Verbndung, nimmt seinen Client (noch immer eingeschaltet) mit in die Firma und verbindet den dann dort via LAN Kabel mit dem Firmen-Netzwerk?
Oder wird der Client heruntergefahren?
Hi, der Client wird heruntergefahren, ein Neustart bring auch beim Testen nichts.
VPN-Verbindung wird über eine WLAN-Verbindung im Homeoffice aufgebaut, in der Firma dann per Kupfer.
Folgende Beobachtung:
Wenn die VPN-Verbindung abgebaut ist, und der Client ans Firmen-LAN angeschlossen wird, erhält die Netzwerkschnittstelle vom DHCP die richtige IP-Adresse, aber ich habe keinen Zugriff auf die Domäne, die Netzwerkverbindung indentifiziert sich auch nicht an der Domäne (statt firma.local steht dort dann "Netzwerk 5") und Netzwerk-Typ ist "öffentlich".
Die Netzwerkidentifizierung dauert auch recht lange.
Folgende Beobachtung:
Wenn die VPN-Verbindung abgebaut ist, und der Client ans Firmen-LAN angeschlossen wird, erhält die Netzwerkschnittstelle vom DHCP die richtige IP-Adresse, aber ich habe keinen Zugriff auf die Domäne, die Netzwerkverbindung indentifiziert sich auch nicht an der Domäne (statt firma.local steht dort dann "Netzwerk 5") und Netzwerk-Typ ist "öffentlich".
Die Netzwerkidentifizierung dauert auch recht lange.
Das klingt nach fehlerhafter Network Awareness (NLA Dienst). Versuche mal bitte den genannten Dienst am Client neu zu starten, nachdem er wieder im Firmennetzwerk hängt.
Hat der Domänen-Controller denn das Richtige bei seiner Netzwerkverbindung da stehen (z.B. mein.firma.de)?
Ja der AD-Controller hat die richtigen Einträge,.
Gruß
Jan
Zitat von @kpunkt:
Ist aber schon lange her, dass ich den Client mal gesehen hab. Insgesamt würde ich das auf den Client schieben. Lancom ist oftmals sehr gut, solange es funktioniert. Fehlersuche oft die Hölle.
Ist aber schon lange her, dass ich den Client mal gesehen hab. Insgesamt würde ich das auf den Client schieben. Lancom ist oftmals sehr gut, solange es funktioniert. Fehlersuche oft die Hölle.
Absolute Zustimmung.
Eventuell auch mal den in Windows integrierten L2TP / IPSec Client nutzen und testen.
Gruß
Marc
Zitat von @kpunkt:
Blöde Frage....DNS holt sich der Client auch per DHCP?
Ansonsten Workaround über den VPN-Vlient.
Da sollte man doch in den Verbindungsoptionen auch Batches starten (externe Anwendung starten) können. Und da gabs als Trigger auch das nach Verbindungsabbau.
Da mal per ipconfig den DNS raushauen und neu holen lassen. (release, renew, flushdns)
Ist aber schon lange her, dass ich den Client mal gesehen hab. Insgesamt würde ich das auf den Client schieben. Lancom ist oftmals sehr gut, solange es funktioniert. Fehlersuche oft die Hölle.
Blöde Frage....DNS holt sich der Client auch per DHCP?
Ansonsten Workaround über den VPN-Vlient.
Da sollte man doch in den Verbindungsoptionen auch Batches starten (externe Anwendung starten) können. Und da gabs als Trigger auch das nach Verbindungsabbau.
Da mal per ipconfig den DNS raushauen und neu holen lassen. (release, renew, flushdns)
Ist aber schon lange her, dass ich den Client mal gesehen hab. Insgesamt würde ich das auf den Client schieben. Lancom ist oftmals sehr gut, solange es funktioniert. Fehlersuche oft die Hölle.
Hi, auch ein manuelles IPCONFIG /flushdns /renew bringt nicht, nur das manuelle deaktivieren / aktivieren der Schnittstelle behebt das Problem.
Am DHCP kanns nicht liegen, da das Problem auch mit einer fest eingestellten IP-Konfig. auftritt.
Das Problem ist auch nicht auf eine Maschine begrenzt, es betrifft sämtliche PCs, die VPN nutzen.
Gruß
Jan
Dann eben direkt
netsh winsock reset
Und ich würd da mal direkt bei Lancom nachfragen. Zumindest im Forum, wenn nicht direkt beim Support und Case öffnen.
Sorry, winsock reset braucht neustart.
Aber das Interface kann man de- und reaktivieren ohne Neustart
Interface-Name über
netsh interface show interface
netsh winsock reset
Und ich würd da mal direkt bei Lancom nachfragen. Zumindest im Forum, wenn nicht direkt beim Support und Case öffnen.
Sorry, winsock reset braucht neustart.
Aber das Interface kann man de- und reaktivieren ohne Neustart
netsh interface set interface name ="interfacename" admin=disabled
netsh interface set interface name ="interfacename" admin=enabled Interface-Name über
netsh interface show interface
Welche Software läuft auf der UF? Mit 10.6RU5 hatte ich massive IPsec Probleme. Deswegen läuft unsere auf RU4.
Zitat von @Looser27:
Welche Software läuft auf der UF? Mit 10.6RU5 hatte ich massive IPsec Probleme. Deswegen läuft unsere auf RU4.
Welche Software läuft auf der UF? Mit 10.6RU5 hatte ich massive IPsec Probleme. Deswegen läuft unsere auf RU4.
Wir haben die 10.6RU6 mit Hotfix.
Lancom hat bei uns den Hotfix wegen der IPsec-Problematik eingespielt, soll wohl in der 10.7 mit drin sein.
Zitat von @kpunkt:
Dann eben direkt
netsh winsock reset
Und ich würd da mal direkt bei Lancom nachfragen. Zumindest im Forum, wenn nicht direkt beim Support und Case öffnen.
Sorry, winsock reset braucht neustart.
Aber das Interface kann man de- und reaktivieren ohne Neustart
Interface-Name über
netsh interface show interface
Dann eben direkt
netsh winsock reset
Und ich würd da mal direkt bei Lancom nachfragen. Zumindest im Forum, wenn nicht direkt beim Support und Case öffnen.
Sorry, winsock reset braucht neustart.
Aber das Interface kann man de- und reaktivieren ohne Neustart
netsh interface set interface name ="interfacename" admin=disabled
netsh interface set interface name ="interfacename" admin=enabled Interface-Name über
netsh interface show interface
Ja, das würde ich gerne machen, Fehlermeldung da: "Die Daten sind unzuässig".
Ich kann die Schnittstelle allerdings auch grade nicht manuell deaktivieren, bekomme da eine Fehlermeldung
Die Verbindung konnte nicht deaktiviert werden. Möglicherweiße werden von de
Verbindung Protokolle verwendet, die Plug & Play nicht unterstützen, oder die
Verbindung wurde von einem anderen Benutzer oder dem Systemkonto
initialisiert
Da habe ich jetzt übelst den Client in Verdacht.
Deinstallier den mal restlos und versuch dann mal das passende Interface per netsh zu de- und reaktivieren.
Theoretisch würde ich ja sagen irgend ein Dienst, aber wenns bei allen Clients Probleme macht.....Der VPN-Client wird sich da heftig in den Socket eingraben. Würd mich bei Lancom nicht wirklich wundern.
Vielleicht testweise auch mal Shrew auspropieren.
Deinstallier den mal restlos und versuch dann mal das passende Interface per netsh zu de- und reaktivieren.
Theoretisch würde ich ja sagen irgend ein Dienst, aber wenns bei allen Clients Probleme macht.....Der VPN-Client wird sich da heftig in den Socket eingraben. Würd mich bei Lancom nicht wirklich wundern.
Vielleicht testweise auch mal Shrew auspropieren.
...oder wechsel auf OpenVPN. Das rennt problemlos.
So,
Fehler ist bei Lancom gemeldet, wir konnten den Fehler auch im Beisein (remote) vom Lancom-Support auch reproduzieren, dieser hat den Case bei sich hocheskaliert. Bis da eine Rückmeldung kommt behelfen wir uns mit einer kleinen Batch-Datei die die Kollegen beim Rückkehren vom Homeoffice ins Büro ausführen
geht halt erstmal nicht anders.....
Ich update mal wenn was vom Support kommt.
Fehler ist bei Lancom gemeldet, wir konnten den Fehler auch im Beisein (remote) vom Lancom-Support auch reproduzieren, dieser hat den Case bei sich hocheskaliert. Bis da eine Rückmeldung kommt behelfen wir uns mit einer kleinen Batch-Datei die die Kollegen beim Rückkehren vom Homeoffice ins Büro ausführen
netsh winsock reset
shutdown.exe /r /t 00geht halt erstmal nicht anders.....
Ich update mal wenn was vom Support kommt.
