VPN Verbindung nicht möglich Hilfe !!

tabularaza · Beitrag von **tabularaza** » 25 Sep 2007, 13:14

Hallo,
wir haben folgendes Problem, bei dem VPN Aufbau zwischen einem Lancom I-1711 und einer Sonicwall TZ-170. Wir sind zwar keine VPN Profis, aber irgednwie werden wir aus dem Protokoll nicht schlau. Einer vor Euch kann mir mit Sicherheit das Problem sagen, welches vorliegt aus der nachfolgenden Protokolldatei des Lancom I-1711 per trace + vpn.
Hier die Log Datei vom lancom:

[VPN-Status] 2007/09/25 12:59:52,700
VPN: connecting to SONICWALL (217.236.92.61)

[VPN-Status] 2007/09/25 12:59:52,700
VPN: start dynamic VPN negotiation for SONICWALL (217.236.92.61) via ICMP/UDP

[VPN-Status] 2007/09/25 12:59:52,700
VPN: create dynamic VPN V2 authentication packet for SONICWALL (217.236.92.61)
DNS: 192.168.66.254, 0.0.0.0
NBNS: 192.168.66.254, 0.0.0.0
polling address: 192.168.66.254

[VPN-Status] 2007/09/25 12:59:52,700
VPN: installing ruleset for SONICWALL (217.236.92.61)

[VPN-Status] 2007/09/25 12:59:52,730
VPN: ruleset installed for SONICWALL (217.236.92.61)

[VPN-Status] 2007/09/25 12:59:52,740
VPN: start IKE negotiation for SONICWALL (217.236.92.61)

[VPN-Status] 2007/09/25 12:59:52,750
VPN: rulesets installed

[VPN-Packet] 2007/09/25 12:59:52,750
for send: 192.168.66.81->192.168.67.1 48 TCP port 3911->139

[VPN-Packet] 2007/09/25 12:59:52,750
no sa available: give up, should be retransmitted

[VPN-Status] 2007/09/25 12:59:52,760
IKE info: Phase-1 negotiation started for peer SONICWALL rule isakmp-peer-SONICWALL using MAIN mode

[VPN-Status] 2007/09/25 12:59:52,860
IKE info: The remote server 217.236.92.61:500 peer SONICWALL id <no_id> supports NAT-T in mode rfc

[VPN-Status] 2007/09/25 12:59:52,860
IKE info: phase-1 proposal failed: remote No 1 hash algorithm = SHA <-> local No 1 hash algorithm = MD5
IKE info: Phase-1 remote proposal 1 for peer SONICWALL matched with local proposal 2

[VPN-Status] 2007/09/25 12:59:53,150
IKE info: The remote server 217.236.92.61:500 peer SONICWALL id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 217.236.92.61:500 peer SONICWALL id <no_id> supports draft-ietf-ipsec-isakmp-xauth
IKE info: The remote server 217.236.92.61:500 peer SONICWALL id <no_id> negotiated rfc-3706-dead-peer-detection

[VPN-Packet] 2007/09/25 12:59:53,740
for send: 192.168.66.81->192.168.67.1 48 TCP port 3911->139

[VPN-Packet] 2007/09/25 12:59:53,740
no sa available: give up, should be retransmitted

Für Eure Bemühungen schon mal besten Dank im voraus.

Bis denne

tabularaza

backslash · Beitrag von **backslash** » 25 Sep 2007, 15:39

Hi tabularaza

also als erstes: Die Sonicwall wird kein dynamic VPN verstehen, also laß es weg...

als zweites: hast du eine statische oder eine dynamische IP-Adresse? Bei einer dynamischen muß dein Lancom einen Dyndns-Namen haben, welcher auf der Sonicwall hinterlegt wird. Es sei denn, du verwendest entweder den Aggressive-Mode (wovon ist aus Sicherheitsgründen abzuraten ist) oder verwendest Zertifikate...

Gruß
Backslash

tabularaza · Beitrag von **tabularaza** » 25 Sep 2007, 16:16

backslash hat geschrieben: hast du eine statische oder eine dynamische IP-Adresse? Bei einer dynamischen muß dein Lancom einen Dyndns-Namen haben, welcher auf der Sonicwall hinterlegt wird.

Ich habe eine dynamische IP auf beiden Seiten, welche jeweils in der Sonicwall und dem Lancom hinterlegt sind (DYNDNS Namen). Im Lancom ist in der Aktionstabelle der DynDNS eingetragen und von außen auch entsprechend anzusprechen.

Wie genau funktioniert es mit Zertifikaten ??

Kann ich erst mit dem aggresive Mode arbeiten und dann die Zertifikatsgeschichte später machen ?? Auch wenn es etwas unsicherer ist ??

Es ist für uns wichtig, daß wir erst mal den VPN Tunnel hinbekommen und wir uns dann später noch mal die Sicherheit anschauen.

Danke schon mal.

Gruß

Tabularaza

tabularaza · Beitrag von **tabularaza** » 27 Sep 2007, 08:35

Hallo,
also ich habe den Lancom und auch die Sonicwall jetzt auf Aggresive Mode umgestellt und bekomme immer noch folgenden Fehler im trace + VPN:

[VPN-Packet] 2007/09/27 08:29:31,940ket] 2007/09/27 08:28:29,790.139:500
for send: 192.168.66.254->192.168.67.1 84 ICMP ECHOREQUEST.67.1 84 ICMP ECHOREQUESTirst for SONICWALL phase
ted rfc-

[VPN-Packet] 2007/09/27 08:29:31,940ket] 2007/09/27 08:28:29,790atus] 20
no sa available: give up, should be retransmitted up, should be retransmittedop

Wenn ich es richtig verstanden habe müßten die beiden Router doch jetzt ohne ein Zertifikat die Verbindung aufbauen können. Aber was genau heiß no SA available. Eine SA ist doch eigentlich ein Zertifikat, welche im Agressive Mode gar nicht benötigt oder verstehe ich da was falsch ??

Danke schon mal vorab für die Hilfe.

backslash · Beitrag von **backslash** » 27 Sep 2007, 12:15

Hi tabularaza

[VPN-Packet] 2007/09/27 08:29:31,940ket] 2007/09/27 08:28:29,790.139:500
for send: 192.168.66.254->192.168.67.1 84 ICMP ECHOREQUEST.67.1 84 ICMP ECHOREQUESTirst for SONICWALL phase
ted rfc-

[VPN-Packet] 2007/09/27 08:29:31,940ket] 2007/09/27 08:28:29,790atus] 20
no sa available: give up, should be retransmitted up, should be retransmittedop

wie hast du denn das geschaft, drei Traces ineinander zu rühren?

Aber unabhängig davon: Das ist erstmal kein Fehler, sondern nur eine Statusmeldung, daß z.Zt keine SA für das Paket ausgehandelt wurde. Wenn das LANCOM passnede VPN-Regeln hat, dann beginnt es nun, die SAs auszuhandeln.

Beschränke den Trace einfach auf "vpn-status" - dann sind die Paketmeldungen raus...

Wenn ich es richtig verstanden habe müßten die beiden Router doch jetzt ohne ein Zertifikat die Verbindung aufbauen können

sie sollten es auch im Mainmode können, da du ja gesagt hast, daß beide Seiten Dyndns-Namen haben und diese auch gegenseitig bekannt sind...

Aber was genau heiß no SA available. Eine SA ist doch eigentlich ein Zertifikat,

nein! Eine SA enthält die notwendigen Informationen um die Daten überhaupt verschlüsseln zu können. Dazu gehören die beidseitigen Netze, die beidseitgen öffentlichen Adressen (remote gateway, local gateway), das zu verwendende Verschlüsselungsprotokoll und der zu verwendende Key. Das alles wird beim Verbindungsaufbau ausgehandelt und hat nichts mit Zertifikaten zu tun.

Die Zertifikate dienen erstmal nur dazu, die Authentität des jeweils anderen sicherstellen zu können...

Gruß
Backslash

tabularaza · Beitrag von **tabularaza** » 28 Sep 2007, 15:05

Hallo,
ich habe nun mal nen Trace VPN-Status gemacht und als Anlage dem Thread angehängt..
Es kann teilweise von der Gegenseite eine VPN Verbindung aufgebaut werden wenn dort Anfragen ins Netzt hinter dem Lancom verschickt werden (Ping reicht), allerding von der Seite welche hinter dem Lancom sitz nicht. Im Lanmonitor erscheint immer Zeitüberschreitung während IKE-oder IPSEC Verhandlung (Initiator) [0x1106].
Ich hoffe daß mir einer von Euch was zu dem Log näher erklären kann.

Sorry für das dreifach Trace vom vorherigen posting.
Hatte die falsche Datei erwischt.

Sorry,sorry,sorry !!

backslash · Beitrag von **backslash** » 28 Sep 2007, 15:59

Hi tabularaza,

und hier haben wir auch schon das Problem:

Code: Alles auswählen

[VPN-Status] 2007/09/28 14:49:05,110
IKE info: Phase-1 [inititiator] for peer SONICWALL between initiator id accountname.dyndns.ws, responder id accountname.dyndns.ws done
IKE info: NAT-T enabled in mode rfc, we are not behind a nat, the remote side is behind a nat
IKE info: SA ISAKMP for peer SONICWALL encryption aes-cbc authentication sha1
IKE info: life time ( 108000 sec/ 0 kb)

Die Sonicwall ist hinter einem NAT-Router. Damit das LANCOM die Verbindung aufbauen kann, muß der NAT-Router neben dem UDP-Port 500 auch den UDP-Port 4500 auf die Sonicwall weiterleiten...

Gruß
Backslash

tabularaza · Beitrag von **tabularaza** » 03 Okt 2007, 13:38

Hallo,
besten Dank für die profesionelle Hilfe. Es funktioniert nun, allerdings habe ich das Problem, das die RDP Verbindung immer wieder getrennt wird. Ich kann nur nicht sagen warum, da es keine feste Zeit dafür gibt. Es sieht für mich aus, als ob diese sporadisch getrennt wird. Es ist egal ob eine Datenübertragung stattfindet oder nicht. Über den VPN Tunnel kann ich immer noch Daten kopieren nur die RDP Verbindung trennt sich. Das trennen kommt nicht vom Server der Gegenstelle, da diese auf trennen bei Inaktivität nach 60 Minuten steht und die RDP verbindung auch beim Arbeiten auf einmal weg ist (rotes Kreuz).

Vielleicht kannst Du mir da auch Hilfestellung zu geben. Was muß ich da genau einstellen bzw. wie sehe ich von wo die verbindung getrennt wird ??

Gibt es da ein tarce befehl für ??

Danke schon mal vorab.

backslash · Beitrag von **backslash** » 03 Okt 2007, 21:05

Hi tabularaza,

RDP reagiert sehr empfindlich auf Laufzeitschwankungen... Hier hift ggf. die RDP-Session über die Firewall zu priorisieren (Stichwort: Mindestbandbreite, PMTU-Reduzierung für andere Dienste)...

Gruß
Backslash

tabularaza · Beitrag von **tabularaza** » 05 Okt 2007, 10:33

Hallo,
gibte es Empfehlungen was da eingestellt werden sollte, damit es stabil läuft ?? Wir haben auf beiden Seiten eine 6Mbit T-Com Leitung. Was genau hat es mit der PMTU Reduzierung auf sich ?? Den MTU Wert an sich habe ich schon angepasst, sodaß keine Pakete fragmentiert werden.

tabularaza · Beitrag von **tabularaza** » 29 Okt 2007, 16:32

Hallo,
die VPN verbindung an sich ist mittlerweile recht stabil. Danke schon mal für die Hilfe.
Die unregelmäßigen RDP Abbrüche sind recht nervig. Mal kann den ganzen Tag darin ohne Probs gearbeitet werden und an nem anderen Tag wieder schmiert die RDP Verbindung 5-6 Mal ab. Die Zeitabstände sind aüßerst unterschiedlich.
Ich habe eine Portpriosierung bereits konfiguriert aber leider ohne Erfolg. Habe ich das wie im Screenshot beschrieben richtig gemacht ?? Oder hatte ich eine gedankenfehler ??
Daneks chon mal vorab.

backslash · Beitrag von **backslash** » 29 Okt 2007, 17:41

Hi tabularaza,

bist du dir sicher, daß du wirklich 384kBit für die RDP-Session brauchst? das scheint mir doch zu hoch zu sein...

Aber abgesehen davon könntest du zusätzlich noch eine PMTU-Reduzierung auf z.B. 576 Bytes versuchen (das bedeutet, daß alle anderen Dienste ein kleinere PMTU gemeldet bekommen, während die RDP-Session unangetatset bleibt)

Von einer Zwangsfragmentierung hingegen solltest du Abstand nehmen, da es im Inetrnet viele Server gibt, die fragmentierte Pakete verwerfen.

Gruß
Backslash

tabularaza · Beitrag von **tabularaza** » 30 Okt 2007, 12:46

Hallo,
ich werde das mal testen und berichten ob das nach diesen Änderungen stabiler/besser läuft.

Danke schon mal vorab