VPN ohne extra client WinXP -> 1811 Problem

Michael Rignaz · Beitrag von **Michael Rignaz** » 13 Okt 2006, 00:25

Hallo,

Hilfe!Ich scheitere leider wiedermal, und zwar an einer VPN Verbindung zwischen einem XP Pro hinter einem NAT und einem 1811er, diesmal dauert das Problem schon tagelang an und ist sicher kein "Zufall" wie letztes mal, nochmal Entschuldigung.
Bin total aufgeschmissen, mir sagen die Fehlermeldungen nix, und da man am Client ja leider kaum oder sehr schwer "tracen" kann, hab ich null Anhaltspunkte.

Habe 2 1811er (6.22) in verschiedenen Netzren miteinander verbunden, funktioniert wunderbar.
Habe mir jetzt den Artikel von eddia bzgl. VPN von Windows aus ohne Zusatzclient durchgelesen.
Alles getan wie im Artikel, nur es will einfach nicht funktionieren. Unter Eigene Zertifikate wird das eigene crt angezeigt, sowie unter vertrauenswürdige Stammzertifizierungsstellen die CA die auch am 1811er ist.
Habe nur ein CN=.. definiert, nix weiteres, also kanns an der richtigen Reihenfolge auch kaum liegen.
Mein lokales netz ist ein 192.168.0.0/24, das fremde 192.168.1.0/24.
Hänge hinter einem WRT54G.
ein trace + vpn bringt folgendes:
IKE info: dropped message from peer unknown <öffentliche ip> port 500 due to notification type INVALID_COOKIE
IKE info: The remote server <öffentliche ip>:500 peer def-main-peer id <no_id> supports NAT-T in mode draft
IKE info: Phase-1 remote proposal 1 for peer def-main-peer matched with local proposal 1

bei einem ping vom Windows Client bekomm ich bis in alle Ewigkeit "Ip-Sicherheit wird verhandelt"

Könnte mich bitte jemand in die richtige Richtung Boxen bzw. weiss an was das liegen kann?

Die ipsec.conf:

Code: Alles auswählen

conn <name>
   left=%any
   right=<ip vom 1811er>
   rightsubnet=192.168.0.0/24
   rightca="CN = <die CN der CA>"
   network=auto
   auto=start
   pfs=yes

BTW:

In der Verbindungsliste steht bei dieser Verbindung (per Assistenten eingerichtet) als IP 0.0.0.0, bei Lancom ist ja 255.255.255.255 immer default... ändere ich das auf 255.255.255.255, kommt als Fehler im trace keine config gefunden für diese ip...

eddia · Beitrag von **eddia** » 13 Okt 2006, 18:30

Hallo Michael,

ein trace + vpn bringt folgendes:

es ist immer eine gute Idee, bei solchen Problemen den kompletten originalen Trace zu posten.

n der Verbindungsliste steht bei dieser Verbindung (per Assistenten eingerichtet) als IP 0.0.0.0,

Meinst Du wirklich die VPN-Verbindungsliste? Da muss in Deinem Fall natürlich 0.0.0.0 stehen. Wichtig ist jedoch der Eintrag in der Routingtabelle des Lancoms. Falls Du nicht mit Routingtags arbeitest, muss dort die LAN-IP Deines VPN-Clients drinstehen.

Gruß

Mario

Michael Rignaz · Beitrag von **Michael Rignaz** » 13 Okt 2006, 18:59

Eddia, vielen Dank für deine Antwort!

Poste hier alles was ich finden kann von trace + vpn, nehme nur die Meldungen zu der anderen Lancom <-> Lancom-Verbindung raus.

Das einzige was ich hier bekomme ist:

Code: Alles auswählen


[VPN-Status] 2006/10/13 18:35:47,700
IKE info: The remote server <meine öffentliche ip>:500 peer def-main-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server <meine öffentliche ip>:500 peer def-main-peer id <no_id> supports NAT-T in mode draft


[VPN-Status] 2006/10/13 18:35:47,700
IKE info: Phase-1 remote proposal 1 for peer def-main-peer matched with local proposal 1

[VPN-Status] 2006/10/13 18:37:42,930
IKE log: 183742 Default message_recv: invalid cookie(s) 9d790918ce5a3732 4a8c4e2258885238


[VPN-Status] 2006/10/13 18:37:42,930
IKE log: 183742 Default dropped message from <meine öffentliche ip> port 500 due to notification type INVALID_COOKIE


[VPN-Status] 2006/10/13 18:37:42,940
IKE info: dropped message from peer unknown <meine öffentliche ip> port 500 due to notification type INVALID_COOKIE


[VPN-Status] 2006/10/13 18:37:42,940
IKE info: The remote server <meine öffentliche ip>:500 peer def-main-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server <meine öffentliche ip>:500 peer def-main-peer id <no_id> supports NAT-T in mode draft


[VPN-Status] 2006/10/13 18:37:42,940
IKE info: Phase-1 remote proposal 1 for peer def-main-peer matched with local proposal 1

[VPN-Status] 2006/10/13 19:03:36,400
VPN: selecting first remote gateway using strategy eFirst for home
     => no remote gateway selected

Unter Verbindungsliste steht folgendes für diese Verbindung:
Name der Verbindung home
Extranet-Adresse 0.0.0.0
Entferntes Gateway 0.0.0.0
Verbindungs-Parameter p-home
Regelerzeugung Manuell
Dynamische VPN-Verbindung (nur mit kompatiblen Gegenstellen)
Kein dynamisches VPN
Main Mode
IKE-CFG Aus

In der Routingtable hab ich eine weitere 255.255.255.255 mit 0.0.0.0 maske, aber routing tag 1 angelegt (mit dem richtigen Eintrag unter "router")

Was kann denn das sein?Problem mit Zertifikaten?Mit den Proposals?Mit den IpSec Parametern?Mit dem routing?

Vielen dank für jede Hilfe,

Lg,
Michael[/code]

eddia · Beitrag von **eddia** » 13 Okt 2006, 21:08

Hallo Michael,

In der Routingtable hab ich eine weitere 255.255.255.255 mit 0.0.0.0 maske, aber routing tag 1 angelegt (mit dem richtigen Eintrag unter "router")

und die Regel unter Firewall/QoS für diese Verbindung enthält ebenfalls den Routingtag 1? Falls Dein VPN-Client eine feste LAN-IP hat, musst Du nicht mit den Routingtags arbeiten - da reicht einfach die Angabe dieser IP in der Routingtabelle.

Was kann denn das sein?Problem mit Zertifikaten?

Könnte durchaus sein. Zuerst wäre es entscheidend, ob Du für die Zertifikate des Lancoms und des VPN-Clients unterschiedliche CAs verwendest. Falls nicht, ist es nur wichtig, dass auf beiden Seiten das gleiche CA-Zertifikat bekannt ist (im Lancom unter show vpn ca und im VPN-Client unter ->lokaler Computer->vertrauenswürdige Stammzertifizierungsstellen. Und natürlich muss jede Seite über ein Clientzertifikat verfügen, welches bei Prüfung gegenüber der abseits eingetragenen CA als korrekt angesehen wird.

Gruß

Mario

Michael Rignaz · Beitrag von **Michael Rignaz** » 15 Okt 2006, 16:37

Hallo eddia,

Die CA ist auf beiden Seiten gleich. Der Client key auf meiner Seite ist von dieser CA zertifiziert.
Kann also an den zertifikaten ansich dann nicht liegen.. nur vielleicht findet er auf meiner Seite irgendwie das Zertifikat nicht?Naja es ist sowie du in deinem tutorial beschrieben, am richtigen Ort. Musste aber damit mein Client Zertifikat unter "eigene Zertifikate/zertifikate" erscheint, den Ort selbst wählen.. wenn ich "automatisch" auswählte, hat ers dort nicht gespeichert. Die CA ist auf jeden Fall bei "automatisch wählen" in der richitigen Kategorie erschienen.

Ja, auch die Regel in der Firewall hat den Routing Tag 1.. (muss der nicht inder Verbindungsliste auch auf 1 stehn?Wie auch immer funktioniert so ja auch nicht)

Hab jetzt die Verbindung gelöscht und nochmal neu per Assistenten laut deinen Anweisungen in der FAQ erstellt.. wieder dasselbe...
Diesmal hab ichs mit fixen ips probiert.. im Assistenten also meine lokale (bin wie gesagt hinter einem nat) ip gegeben.
Wieder dasselbe.. nach einem IKE info: Phase-1 remote proposal 1 for peer def-main-peer matched with local proposal 1.... gibts keine meldungen mehr.. nach einiger Zeit dann invalid_cookie.
Was mich wundert bei der Meldung ist, dass die andere VPN Verbindung zu einem anderen 1811er mit Namen "xyz" bei dieser Ereignisart für die "xyz" Verbindung mit Namen auftaucht.. also nicht Phase-1 remote proposal 1 for peer def-main-peer sondern for peer "xyz" .

Hab dann in der verbindugsliste mal die Gatewayip auf meine lokale so wie beim assistenten eingegeben gestellt.
Dann kommt:IKE info: Phase-1 negotiation failed: no configuration found for incoming peer <öff. ip>
und wenig später:
IKE log: 162535 Default dropped message from <öff ip> port 500 due to notification type INVALID_MESSAGE_ID
[/b]

Stell ich zurück, also als gatewayip in der Verbindungsliste wieder 0.0.0.0, wie vom Assistenten konfiguriert, kommt wieder folgendes:

[VPN-Status] 2006/10/15 16:30:59,270
IKE info: The remote server <öff ip>:500 peer def-main-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server <öff ip>:500 peer def-main-peer id <no_id> supports NAT-T in mode draft

[VPN-Status] 2006/10/15 16:30:59,270
IKE info: Phase-1 remote proposal 1 for peer def-main-peer matched with local proposal 1

dann lange nix und dann:
[VPN-Status] 2006/10/15 16:33:13,980
IKE log: 163313 Default message_recv: invalid cookie(s) 273834295014a4fb 93f8c318da0595da

[VPN-Status] 2006/10/15 16:33:13,980
IKE log: 163313 Default dropped message from <öff ip> port 500 due to notification type INVALID_COOKIE

[VPN-Status] 2006/10/15 16:33:13,980
IKE info: dropped message from peer unknown <öff ip> port 500 due to notification type INVALID_COOKIE

Unglaublich was ich da für Probleme damit hab

Mich ärgerts dass das Log nicht auf den Fehler schließen lässt, oder kann man den jetzt eingrenzen?
Es wird doch wohl auf der Clientseite nicht stören dass die CN von der CA CN='blabla' heisst und nicht CN=blabla... die hochkommata sind doch auch normale Zeichen oder? Die beiden lancoms, zwischen denen die Verbindung steht hat das auch nicht gestört.

Danke vielmals für eure hoffentlich weitere Hilfe!!

eddia · Beitrag von **eddia** » 16 Okt 2006, 19:14

Hallo Michael,

Musste aber damit mein Client Zertifikat unter "eigene Zertifikate/zertifikate" erscheint, den Ort selbst wählen.. wenn ich "automatisch" auswählte, hat ers dort nicht gespeichert. Die CA ist auf jeden Fall bei "automatisch wählen" in der richitigen Kategorie erschienen.

ich ahne schlimmes. Du solltest doch die beigelegte ipsec.msc benutzen, um die Zertifikate zu importieren und dann funktioniert das mit der automatischen Auswahl auch problemlos. Sieh bitte genau nach, ob die beiden Zertifikate unter 'lokaler Computer' vorhanden sind. Unter 'aktueller Benutzer' sind die nutzlos, da für den Aufbau der IPSec-Verbindung ausschliesslich das Computerkonto benutzt wird.

Gruß

Mario

Michael Rignaz · Beitrag von **Michael Rignaz** » 16 Okt 2006, 19:21

Hallo eddia,

Ja, die beiden sind unter Zertifikate (Lokaler Computer) gelistet.
Ich habe die ipsec.msc verwendet, nur beim automatischen importieren erschien die client.crt nicht richtig. hab sie so manuell in "eigene zertifikate" gesteckt.
Das ganze befindet sich in "Zertifikate (Lokaler Computer)"

Hmm was kann denn dann noch der Fehler sein? Connection Problem durchs NAT vom Linksys WRT54G?

eddia · Beitrag von **eddia** » 16 Okt 2006, 20:17

Hallo Michael,

nur beim automatischen importieren erschien die client.crt

lese ich das richtig - .crt? Du versuchst doch nicht etwa, eine VPN-Verbindung mit einem Client-Zertifikat ohne privaten Schlüssel herzustellen...? Sieh mal unter den eigenen Zertifikaten nach, ob Dir dort angezeigt wird, dass Du einen privaten Schlüssel für dieses Zertifikat besitzt.

Der muss natürlich vorhanden sein. Zum Import des Clientzertifikates unter Windows muss das Client-Zertifikat zwingend im PKCS#12 Format vorliegen (Endung .p12 oder .pfx). Für das CA-Zertifikat ist das egal, da der private Schlüssel dieses Zertifikates nicht erforderlich ist, sondern dieses Zertifikat allein der Gültigkeitsprüfung anderer Zertifikate dient.

Gruß

Mario

Michael Rignaz · Beitrag von **Michael Rignaz** » 17 Okt 2006, 00:37

Danke eddia, ich vollidiot!!Ich hab mich dabei schon gewundert wie wohl dann der .key gefunden wird.
Verdammter Mißt.
Sowas Blödes.
Vielen vielen Dank für deine ausführliche, nicht abgerissene Hilfestellung!
Jaja so blöd kann man sein

Jetzt hauts natürlich hin.
Danke, schönen Abend,

Michael

Michael Rignaz · Beitrag von **Michael Rignaz** » 20 Okt 2006, 16:17

Hallo,

leider wieder -seit Herstellung der 1. Verbindung- große Probleme.

Die beiden Verbindungen zu den beiden Lancoms können unabhängig voneinander aufgebaut werden.. funktionieren dann ein, zwei, vielleicht 5 Minuten, dann reisst alles ab.. Ich schicke andauernd pings raus und sehe dass in periodischen Intervallen kurz was geht, und dann wieder nix mehr geht.
Auf der Lancomseite "steht" weiterhin die Verbdinung und die icmp echo replies/requests gehen auch durch... sehr merkwürdig.

[VPN-Packet] 2006/10/20 16:08:52,650
received: <meine öff ip>-><lancom's öff ip> 112 ESP SPI[26caa417]

[VPN-Packet] 2006/10/20 16:08:52,650
decrypted: <meine öff ip>-><lancom's öff ip> 96 IP-ENCAP

[VPN-Packet] 2006/10/20 16:08:52,650
decap: 192.168.1.101->192.168.0.2 60 ICMP ECHOREQUEST

[VPN-Packet] 2006/10/20 16:08:52,650
for send: 192.168.0.2->192.168.1.101 60 ICMP ECHOREPLY

[VPN-Packet] 2006/10/20 16:08:52,650
encap: <lancom's öff ip>-><meine öff ip> 80 IP-ENCAP

[VPN-Packet] 2006/10/20 16:08:52,650
encrypted: <lancom's öff ip>-><meine öff ip> 112 ESP SPI[df888cb5]

Nur sieht mein Client davon urplötzlich NIX mehr..
Das ändert sich wenn nach ein paar Minuten dann ein "invalid cookie" error kommt und der Tunnel neu aufgebaut wird. Dann bekomme ich wieder für einige Zeit replies, dann wieder nix mehr...
So wiederholt sich das den ganzen Tag, alle Tage..

An was kann denn das liegen??
Vielen Dank für eure Hilfe (hoffentlich

)!

Michael Rignaz · Beitrag von **Michael Rignaz** » 25 Okt 2006, 05:05

Ich hoffe ein push ist erlaubt..
Der letzte Post in diesem eigentlich schon abgeschlossenen Thread war ja von mir, vielleicht isses nicht aufgefallen.. bitte falls ihr irgendeine Ahnung habt an was das liegen könnte, lasst es mich wissen

DANKE!

backslash · Beitrag von **backslash** » 25 Okt 2006, 14:17

Hi Michael Rignaz,

das Problem dürfte sein, daß der Client hinter einem NAT-Router steht, der IPSec-Passthrough nicht so richtig beherrscht - bzw. dann daran scheitert, wenn ein weiterer Client IPSec machen will.

Ich weiß jetzt nicht, ob der MS-Client NAT-T beherrscht, aber du könntest mal probieren im LANCOM NAT-T zu aktivieren - vielleicht hilft's ja...

Gruß
Backslash

Michael Rignaz · Beitrag von **Michael Rignaz** » 25 Okt 2006, 15:16

Vielen Dank backslash!
Habe jetzt mal die firmware des Linksys wrt54g von der Sveasoft auf dd-wrt geflasht, mal sehn ob das was bringt, wenn nicht werde ich mal nat-t einschalten.. doch bei nat-t müssen dann doch beim client -falls hinter einem nat- bestimmte ports geforwarded werden oder? Das schränkt dann natürlich ein bzgl. dyn ips und standort wechseln... wär schade wenns daran liegt..

backslash · Beitrag von **backslash** » 25 Okt 2006, 17:22

Hi Michael Rignaz

doch bei nat-t müssen dann doch beim client -falls hinter einem nat- bestimmte ports geforwarded werden oder? Das schränkt dann natürlich ein bzgl. dyn ips und standort wechseln... wär schade wenns daran liegt..

nein, da der Client die Verbindungen initiiert - das ist ja der "Trick"...
Nur wenn der Server hinter einem NAT-Router steht, dann muß neben dem UDP-Port 500 auch der UDP-Port 4500 weitergeleitet werden.

Gruß
Backslash

eddia · Beitrag von **eddia** » 25 Okt 2006, 19:40

Hallo Backslash,

Ich weiß jetzt nicht, ob der MS-Client NAT-T beherrscht,

das kann er nur per L2TP.

Gruß

Mario