Probleme bei VPN-Verb. über IPSec

[sternschnute]

Hallo zusammen,

ich habe ein Problem mit einer VPN-Verbindung eines Users. Da ich mich auf diesem Gebiet nicht so ganz gut auskenne, hoffe ich, dass ich hier Hilfe finde.

Also:

Router: Bintec VPN25

User nutzen den Bintec FEC Secure IPSec Client

Ein User kann sich derzeit nicht mit dem Client in das Netzwerk einwählen. Die Logs besagen, dass er connected ist, aber Zugriff auf die Ressourcen sowie Outlook ist nicht möglich. Internetverbindung steht natürlich Habe mir vom User mal das Log vom client geben lassen:

10.7.2009 11:42:38  LinkStatus Change - 0,Intel(R) PRO/Wireless 3945ABG Network Connection (Microsoft's Packet Scheduler) 

10.7.2009 11:42:38  Remove Adapter - 203,Bluetooth BNEP from TOSHIBA (Microsoft's Packet Scheduler) 

10.7.2009 11:42:38  EAPOL:send EAPOL_LOGOFF

10.7.2009 11:42:38  EAP:Bluetooth BNEP from TOSHIBA (Microsoft's Packet Scheduler)  authentication failure ! - EAPOL - admin close

10.7.2009 11:42:38  LinkStatus Change - 100,NdisWan Adapter (Microsoft's Packet Scheduler) 

10.7.2009 11:42:39  IPSDIALCHAN::start building connection

10.7.2009 11:42:39  NCPIKE-phase1:name(xxxx) - outgoing connect request - aggressive mode.

10.7.2009 11:42:39  XMIT_MSG1_AGGRESSIVE - xxxx

10.7.2009 11:42:40  RECV_MSG2_AGGRESSIVE - xxxx

10.7.2009 11:42:40  IKE phase I: Setting LifeTime to 28800 seconds

10.7.2009 11:42:40  MSU VPN ->Support for NAT-T version - 3

10.7.2009 11:42:40  IPSDIAL->FINAL_TUNNEL_ENDPOINT:xxx.xxx.xxx.xxx

10.7.2009 11:42:40  Turning on NATD mode - xxxx - 1

10.7.2009 11:42:40  XMIT_MSG3_AGGRESSIVE - xxxx

10.7.2009 11:42:40  NCPIKE-phase1:name(xxxx) - connected

10.7.2009 11:42:40  Phase1 is Ready: IkeIndex = 00000006

10.7.2009 11:42:40  Quick Mode is Ready: IkeIndex = 00000006 , VpnSrcPort = 4500

10.7.2009 11:42:40  Assigned IP Address: 100.100.100.106

10.7.2009 11:42:41  XMIT_MSG1_QUICK - xxxx

10.7.2009 11:42:42  RECV_MSG2_QUICK - xxxx

10.7.2009 11:42:42  XMIT_MSG3_QUICK - xxxx

10.7.2009 11:42:42  NCPIKE-phase2:name(xxxx) - connected

10.7.2009 11:42:42  IPSDIAL  - verbunden mit xxxx auf Kanal 1.

10.7.2009 11:42:42  IPCP  - verbunden mit xxxx mit IP Adresse: 100.100.100.106. : 100.100.100.107.

Kann mir jemand die Logs deuten?

Viele Grüße und vorab schonmal vielen Dank

Sternschnute

[Thanks-and-Goodbye]

Über welchen Internetprovider geht der User online?

Funktioniert die Namensauflösung über das VPN in das interne Netz?

Ursache könnte hier liegen:

http://www.heise.de/netze/Telekom-leitet-DNS-Fehlermeldungen-um--/news/meldung/136338

http://www.heise.de/ct/Kein-VPN-Zugriff-per-T-Online--/hotline/140655

[sternschnute]

Über welchen Internetprovider geht der User online?

Funktioniert die Namensauflösung über das VPN in das interne Netz?

Ursache könnte hier liegen:

heise Netze - 17.04.09 - Telekom leitet DNS-Fehlermeldungen um

Kein VPN-Zugriff per T-Online - c't

erstmal vielen Dank für Deine schnelle Antwort. Bin total aufgeschmissen, weil ich echt kein Fachmann für sowas bin.

Der Internetprovider ist QSC.

Wie teste ich die Namensauflösung?

Tausend Dank für Deine Hilfe!

[Thanks-and-Goodbye]

Am entsprechenden Notebook das VPN aufbauen.

Eingabeaufforderung öffnen

tracert $exchangeservername

nslookup $exchangeservername

[sternschnute]

Problem erkannt, die namensauflösung funzt nicht.

Wie kann ich das Problem lösen (tut mir leid, dass ich so doof fragen muss.)

[Thanks-and-Goodbye]

Wie kann ich das Problem lösen (tut mir leid, dass ich so doof fragen muss.)

http://www.heise.de/ct/Kein-VPN-Zugriff-per-T-Online--/hotline/140655

Das lesen und dann ab in die Registry.

[sternschnute]

So, habe mit dem User zusammen am Telefon den Artikel befolgt.

Neu geschaut mit tracert-Befehl: Zielname konnte nicht aufgelöst werden.

[Thanks-and-Goodbye]

Reboot nach der Registryänderung gemacht?

[sternschnute]

ja, hab ich grad, leider erfolglos...

Liegt es denn direkt am User/Notebook oder kann es auch am DNS auf dem Server liegen? Bis vor kurzem gings bei dem User noch einwandfrei.

Da gerade alle aus dem Haus und nicht erreichbar sind, kann ich auch nicht nachfragen, wer noch Probleme mit dem VPN hat. Auf Mails hab ich noch keine Antwort bekommen.

*seufz*

[Mr.O]

also keine schöne aber manchmal hilfreiche Varinaten ist das umschreiben der Hosts datei.

da kannst du quasi manuell Namen drin auflösen. Zu finden ist diese Datei unter

C:\WINDOWS\system32\drivers\etc (bei WinXP bei Vista kann ich das leider nicht genau sagen) einfach nach der Datei hosts suchen.

dort einfach unter

127.0.0.1 localhost

10.3.0.100 Mailserver

z.B. eintragen dann sollte es gehen.

[Thanks-and-Goodbye]

Das beseitigt leider nicht den ursächlichen Fehler in der Namensauflösung.

[Mr.O]

das stimmt aber der Kunde/Mitarbeiter kann arbeiten und man hat Zeit den fehler zu suchen *g*

Ursachen könnte sein:

neuens Sicherheitsupdate von MS?

Update der Firewall durchgeführt?

Update der Virensoftware durchgeführt?

wenn das alles ausgeschlossen ist...

dir das Laptop zukommen lassen und mit Wireshark mal gucken was genau der macht.

[sternschnute]

Guten Morgen zusammen,

vorerst einmal vielen Dank für die Tips.

ich hoffe, der User kommt heute im Büro vorbei und ich kann mir das mal genauer anschauen.

Die Idee mit der Hosts-Datei umschreiben ist prima, dann kann ich in Ruhe die Ursache suchen.

Vielen Dank vorerst.

Ich melde mich, sobald ich was erreicht habe.

Danke

Sternschnute

[sternschnute]

Hallo,

hab im Anhang mal einen Screenshot angehängt. Habe das über die host-datei versucht. Hat aber nicht funktioniert.

Könnt Ihr damit was anfangen?

Viele Grüße

Sternschnute

[lupo49]

Es sieht so aus, als würde der Client versuchen, einen internen Hostnamen über einen öffentlichen DTAG Nameserver aufzulösen. Der VPN-Nutzer sollte nach erfolgreicher Herstellung der VPN-Verbindung, die DNS-Konfiguration des VPN-Gateways übernehmen ("pushen").

Habt ihr keinen WINS/DNS-Server im internen LAN?

(Es ist nicht förderlich, die relevanten Teile auf dem Screenshot mit blauen Marker unkenntlich zu machen.)

[sternschnute]

Hallo Lupo,

doch, ein DNS-Server ist konfiguriert. Leider kenne ich mich damit nicht so besonders aus, was aber niemanden davon abhält, dass ich das Problem lösen muss.

Ich habe auf dem Screenshot was unkenntlich gemacht, weil ich nicht wollte, dass gegebenenfalls vertraulich Daten als Angriff dienen könnten. Verstehst was ich meine? Unter den blauen weggemarkterten stand der Name des Servers.

[lupo49]

Was für DNS-Server sind denn konfiguriert?

Poste mal die, die ihr intern im LAN benutzt und die der VPN-Client konfiguriert hat.

(Solange du keine FQDN oder eure öffentlichen IP-Adressen postest, sollte das sicherheitstechnisch egal sein. Es kann keiner was mit dem internen Servernamen anfangen.)

[sternschnute]

allo Lupo,

vielen Dank für Dein Posting. Bin für jede Hilfe sehr dankbar.

Ich versuch es mal:

Vorweg muss ich sagen, dass unser Server hier msuhh05 mit einem Server an einem anderen Standort "kommuniziert". Auf beiden Servern sind die gleichen DNS-Server konfiguriert:

msuhh05 (für unseren Standort) sowie MSUHG02 (für den anderen Standort).

Auf beiden Servern läuft Windows 2003 Server.

Unter MSUHH05 sind folgende Einträge unter Forward-Lookupfunktionen:

FQDN von unserem Standort, Typ AD-integriert, primär

FQDN vom Partnerstandort, Typ Sekundär sowie

"_msdcs.." gefolgt von unserem FQDN, Typ AD-integriert, primär

Bei dem MSUHG02 ist es genau umgekehrt konfiguriert.

MSUHH05 hat die interne IP-Adresse 172.16.4.5. Es ist eine Weiterleitung eingerichtet zum Server am anderen Standort. (Registerkarte Weiterleitung)

Im Client ist folgendes VPN-IP-Netz eingetragen: 172.16.4.0

Der client ist soweit auch richtig konfiguriert. Habe alles nochmal genau durchgeschaut. Eine ausreichende Dokumentation liegt hier auch vor.

Hoffe, ich konnte die nötigen Infos geben und habe nicht zu viel verraten.

Bei allen anderen Usern funktioniert die VPN-Verbindung einwandfrei.

Viele Grüße

[sternschnute]

Hallo zusammen,

kaum zu glauben, aber das Problem ist gelöst. Möchte Euch nicht vorenthalten, woran es gelegen hat.

Ich bin auf folgendes Ereignis gestoßen:

Ereignistyp: Fehler

Ereignisquelle: DNS

Ereigniskategorie: Keine

Ereigniskennung: 6525

Datum: 13.07.2009

Zeit: 08:30:50

Benutzer: Nicht zutreffend

Computer: MSUHH05

Beschreibung:

Eine Anforderung zur Zonenübertragung für die sekundäre Zone 2.16.172.in-addr.arpa wurde vom Master-DNS-Server auf 172.16.2.6 abgelehnt. Überprüfen Sie die Zone bei dem Masterserver 172.16.2.6, um sicherzustellen, dass der Zonentransfer zu diesem Server aktiviert ist. Öffnen Sie die DNS-Konsole, wählen Sie den Masterserver 172.16.2.6 als den entsprechenden Server, und wählen Sie in der sekundären Zone 2.16.172.in-addr.arpa "Eigenschaften" und die Registerkarte "Zonenübertragungen". Überprüfen Sie die Einstellungen, und ändern Sie ggf. die Konfiguration (hier oder auf der Registerkarte "Namenserver"), sodass eine Zonenübertragung zu diesem Server möglich wird.

Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter Events and Errors Message Center: Basic Search.

Gesagt - getan - alles läuft wieder!

Ich möchte Euch für Eure hilfreiche Unterstützung danken!

Viele Grüße

Sternschnute