Falsche DNS Auflösung bei bestehender VPN-Verbindung

[h34di 10]

Hallo zusammen,

 

bei einem Anwender unseres Kunden haben wir ein Problem mit der DNS Auflösung bei bestehender VPN Verbindung festgestellt.

Aufgefallen ist das bei dem Zugriff auf die Intranet Website (intranet.domain.de). Ohne VPN Verbindung konnte der Anwender ohne Probleme auf die Website zugreifen, mit VPN Verbindung aber nicht. Komischerweise kann der Anwender aber auf den Sharepoint zugreifen (sharepoint.domain.de), sowohl mit als auch ohne VPN Verbindung.

Andere Anwender haben keine Probleme damit.

Eine Überprüfung des Systems hat keine Fehler hervorgebracht. Der Client erhält die richtigen TCP/IP Einstellungen für die VPN Verbindung (inkl. richtige DNS-Server) und kann auch im Remote-Netzwerk arbeiten (z.B. Zugriff auf Netzlaufwerke).

Die DNS Auflösung hat dann den entscheidenden Hinweis gebracht.

Der Client fragt trotz VPN Verbindung immer den lokalen DNS zuerst (eine FritzBox; 192.168.178.1). Dabei erhält der Client dann natürlich die öffentliche Adresse der Intranetwebsite.

Ein Test mit unseren Laptops hat gezeigt, dass wir mit VPN Verbindung zuerst den Remote-DNS-Server abfragen und deshalb auch die interne Adresse bekommen. Also tippen wir auf einen Fehler am Client.

So weit wir wissen sollte doch der VPN Client alle Anfragen auch an den Remote-DNS stellen, oder?

Vielleicht kennt jemand das Problem und kann uns helfen.

 

(Warum die externe IP Adresse des Sharepoints im Netzwerk richtig geroutet wird, die der Intranetwebsite aber nicht, ist ein anderes Thema.)

 

Danke.

Gruß

Christian

[Okular 10]

Versuche auf dem Client doch mal ein beherztes ipconfig /flushdns. Hat bei mir gelegentlich schon geholfen....

 

Okular

[h34di 10]

Das habe ich schon gemacht und hat leider nicht geholfen.

 

Seit gestern haben wir noch einen weiteren User, der das Problem hat.

[micha12344 10]

Hallo,

 

tritt das Problem temporär auf oder generell?

Unter Netzwerkverbindungen (rechte Maustaste auf Netzwerkumgebung > Eigenschaften) klick mal auf Erweitert > erweiterte Einstellungen. Dort setz die VPN/RAS-Verbindung mal an erster Stelle.

 

Micha

[h34di 10]

Das Problem tritt immer auf.

 

Deinen Ansatz habe ich auch schon verfolgt - leider ohne Erfolg.

[IThome 10]

"Domain.de" ist eine offizielle Domäne im Internet, die auch intern benutzt wird ? Ist das ein Windows-VPN ? Normalerweise wird erst der DNS-Server der lokalen Netzwerkkarte befragt und dann erst der Server der VPN-Verbindung ...

http://www.mcseboard.de/windows-forum-ms-backoffice-31/namensaufloesung-vpn-funktioniert-156308.html

[micha12344 10]

Wenn alles nichts hilft setze Einträge in die hosts-Datei. Ist zwar keine schöne Lösung aber es funktioniert erst mal und du kannst in Ruhe testen.

 

Gib den Rechnern mal beide DNS-Server mit.

 

Micha

[h34di 10]

"Domain.de" ist eine offizielle Domäne im Internet, die auch intern benutzt wird ? Ist das ein Windows-VPN ?

 

Beides Ja.

 

Ist das ein Windows-VPN ? Normalerweise wird erst der DNS-Server der lokalen Netzwerkkarte befragt und dann erst der Server der VPN-Verbindung ...

 

Das hab ich aber andes in Erinnerung. Es müsste doch eigentlich der gesamte Traffic über die VPN Verbindung gehen - außer das was in meinem lokalen Netz liegt.

Genau das zeigt auch ein Test mit meinem Laptop. Sobald ich die VPN Verbindung zum Kunden aufbaue geht alles über die VPN Strecke.

 

Wenn alles nichts hilft setze Einträge in die hosts-Datei. Ist zwar keine schöne Lösung aber es funktioniert erst mal und du kannst in Ruhe testen.

 

Kann ich nicht, da es von intern und extern erreichbar sein muss.

 

Gib den Rechnern mal beide DNS-Server mit.

 

Wie meinst du das?

[IThome 10]

Das hab ich aber andes in Erinnerung. Es müsste doch eigentlich der gesamte Traffic über die VPN Verbindung gehen - außer das was in meinem lokalen Netz liegt.

Genau das zeigt auch ein Test mit meinem Laptop. Sobald ich die VPN Verbindung zum Kunden aufbaue geht alles über die VPN Strecke.

Sniffe das mal und Du wirst sehen, dass DNS-Abfragen zuerst an den lokal konfigurierten DNS-Server gehen (und genau das ist Dein Problem, da von ihm bzw. vom zuständigen DNS-Server im Internet eine negative Antwort kommt. Auch eine negative Antwort vom authoritativen DNS-Server ist eine gültige Antwort).

[h34di 10]

Da magst du recht mit haben, aber das erklärt mir nicht, warum ich auf einem funktionierendem System folgendes Szenario habe:

 

VPN Verbidnung getrennt:

- nslookup geht automatisch an lokalen DNS (DSL-Router)

 

VPN Verbindung aufgebaut:

- nslookup geht automatisch an Remote DNS-Server

[micha12344 10]

VPN Verbidnung getrennt:

- nslookup geht automatisch an lokalen DNS (DSL-Router)

 

VPN Verbindung aufgebaut:

- nslookup geht automatisch an Remote DNS-Server

Beide DNS-Server in die VPN-Verbindung eintragen, das meinte ich.

[IThome 10]

Sniffen, dann siehst Du, was passiert und warum das nicht geht ...

Poste doch mal IPCONFIG /ALL bei bestehender Verbindung eines funktionierenden und eines nicht funktionierenden Systems ...

[h34di 10]

Gesniffert habe ich. Da ist dann eine Anfrage an meinen lokalen DNS drin udn eine Anfrage an meinen Remote DNS. Angezeigt bekam ich bisher das Ergebniss des lokalen DNS.

 

Bin jetzt aber ein Stück weiter (fragt nicht warum, ich weiß es nicht).

 

Der VPN Client nimmt sich jetzt schonmal den remote DNS-Server als "pirmären" DNS-Server in nslookup.

Also werden die FQDNS in interne Adressen aufgelöst.

 

Wenn ich jetzt ein PING oder TRACERT auf den FQDN abgebe, dann nimmt der Client trotzdem die öffentliche IP (ipconfig /flushdns hab ich gemacht).

 

mit Fehler: 
Windows-IP-Konfiguration

       Hostname. . . . . . . . . . . . . : name
       Primäres DNS-Suffix . . . . . . . : domain1.de
       Knotentyp . . . . . . . . . . . . : Hybrid
       IP-Routing aktiviert. . . . . . . : Nein
       WINS-Proxy aktiviert. . . . . . . : Nein
       DNS-Suffixsuchliste . . . . . . . : domain1.de
                                           local.domain1.de
                                           domain2.de

Eth Netzwerkverbindung:

       Verbindungsspezifisches DNS-Suffix: Belkin
       Beschreibung. . . . . . . . . . . : WLAN Adapter
       Physikalische Adresse . . . . . . : 00-C0-A8-D7-5A-62
       DHCP aktiviert. . . . . . . . . . : Ja
       Autokonfiguration aktiviert . . . : Ja
       IP-Adresse. . . . . . . . . . . . : 192.168.2.3
       Subnetzmaske. . . . . . . . . . . : 255.255.255.0
       Standardgateway . . . . . . . . . : 192.168.2.1
       DHCP-Server . . . . . . . . . . . : 192.168.2.1
       DNS-Server. . . . . . . . . . . . : 192.168.2.1
       Lease erhalten. . . . . . . . . . : Dienstag, 24. November 2009 11:44:21
       Lease läuft ab. . . . . . . . . . : Dienstag, 19. Januar 2038 04:14:07

PPP-Adapter Anbieter (VPN):

       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : WAN (PPP/SLIP) Interface
       Physikalische Adresse . . . . . . : 00-53-45-00-00-00
       DHCP aktiviert. . . . . . . . . . : Nein
       IP-Adresse. . . . . . . . . . . . : x.x.10.108
       Subnetzmaske. . . . . . . . . . . : 255.255.255.255
       Standardgateway . . . . . . . . . : x.x.10.108
       DNS-Server. . . . . . . . . . . . : x.x.10.30
                                           x.x.10.25
       Primärer WINS-Server. . . . . . . : x.x.10.25

ohne Fehler:
Windows-IP-Konfiguration

       Hostname. . . . . . . . . . . . . : name
       Primäres DNS-Suffix . . . . . . . : domain1.de
       Knotentyp . . . . . . . . . . . . : Hybrid
       IP-Routing aktiviert. . . . . . . : Nein
       WINS-Proxy aktiviert. . . . . . . : Nein
       DNS-Suffixsuchliste . . . . . . . : domain1.de
                                           local.domain1.de
                                           domain2.de

Eth Netzwerkverbindung:

       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : Intel(R) WiFi
       Physikalische Adresse . . . . . . : 00-22-FA-F5-6F-FE
       DHCP aktiviert. . . . . . . . . . : Nein
       IP-Adresse. . . . . . . . . . . . : 192.168.3.67
       Subnetzmaske. . . . . . . . . . . : 255.255.255.0
       Standardgateway . . . . . . . . . : 192.168.3.50
       DNS-Server. . . . . . . . . . . . : 192.168.3.50

PPP-Adapter Anbieter:

       Verbindungsspezifisches DNS-Suffix:
       Beschreibung. . . . . . . . . . . : WAN (PPP/SLIP) Interface
       Physikalische Adresse . . . . . . : 00-53-45-00-00-00
       DHCP aktiviert. . . . . . . . . . : Nein
       IP-Adresse. . . . . . . . . . . . : x.x.10.105
       Subnetzmaske. . . . . . . . . . . : 255.255.255.255
       Standardgateway . . . . . . . . . : x.x.10.105
       DNS-Server. . . . . . . . . . . . : x.x.10.30
                                           x.x.10.25
       Primärer WINS-Server. . . . . . . : x.x.10.25

[IThome 10]

Gesniffert habe ich. Da ist dann eine Anfrage an meinen lokalen DNS drin udn eine Anfrage an meinen Remote DNS. Angezeigt bekam ich bisher das Ergebniss des lokalen DNS.

So habe ich es erwartet ...

Der VPN Client nimmt sich jetzt schonmal den remote DNS-Server als "pirmären" DNS-Server in nslookup.

Also werden die FQDNS in interne Adressen aufgelöst.

 

Wenn ich jetzt ein PING oder TRACERT auf den FQDN abgebe, dann nimmt der Client trotzdem die öffentliche IP (ipconfig /flushdns hab ich gemacht).

Dann sollte es ja auch Unterschiede beim Sniffen beider Varianten geben, was ich ehrlich gesagt gar nicht glauben kann. Der Unterschied ist, dass sich NSLOOKUP ganz eigen verhält (Abbruch nach der ersten Antwort, wie auch immer die ausfällt) ...

 

Was passiert denn, wenn der jetzt nicht funktionierende Client (der am Gateway 192.168.2.1) am anderen Router angeschlossen wird (am 192.168.3.50) angeschlossen wird und der jetzt funktionierende Client am nicht funktionierenden Gateway ?

[h34di 10]

Was passiert denn, wenn der jetzt nicht funktionierende Client (der am Gateway 192.168.2.1) am anderen Router angeschlossen wird (am 192.168.3.50) angeschlossen wird und der jetzt funktionierende Client am nicht funktionierenden Gateway ?

 

Kann ich leider nicht sagen, da der User in Stuttgart sitzt und ich in Frankfurt.