Shrew Soft VPN will nicht verbinden.

[dburkel]

Danke für den Hinweis, aber die Secrets sind identisch.

[froeschi62]

Hi,

dann solltest Du eine Anfrage mit Deinem Trace im ShrewSoft Forum stellen. Ich muss aus der Ferne passen ohne Deine übrige genaue Konfiguration zu kennen.
Normalerweise funktioniert der ShrewSoft einwandfrei und lässt sich easy konfigurieren. Ich hatte sowohl den aggressive Mode als auch momentan den Main Mode mit Zertifikaten perfekt am Laufen. Ich antworte Dir gerade über eine VPN Verbindung mit ShrewSoft und einem Lancom 1823.

Gruß
Dietmar
Ps: Hast Du alle übrigen Aufzählungspunkte von mir beachtet?

[dburkel]

Ja, habe ich.

Ich habe auf meinem Home Pc, also meinem Macbook, IPSecuritas eingerichtet.
Ist in etwa genauso zu konfigurieren wie dieses ShrewSoft.
Ehrlich gesagt finde ich IPSecuritas noch eine Spur besser, aber ShrewSoft ist auch ok und vor allem für Windows und Free.

Meine Vermutung ist, dass der Client gar nicht erst rauskommt, da die LC im Trace nichts aufzeigt.

[froeschi62]

Ja, das wollte ich Dir gerade schreiben, deshalb meine Empfehlung, die UDP Ports 500 und 4500 explizit in der Vista Firewall freizuschalten. Darauf bekam ich bisher keine Reaktion von Dir. Auch Virenscanner oder andere Firewalls können Ports blocken. Mit einem Wireshark Trace könntest Du das gegebenenfalls genau rausbekommen.

Gruß
Dietmar

[dburkel]

Nein, auf dem Rechner sind keinerlei Security Suites oder sonstiges installiert.
Nur die Windows Firewall ist aktiv. Ports sind freigeschaltet. Mit deaktivierter Firewall geht es aber auch nicht.

Der Tipp mit WireShark ist gut. Den werde ich jetzt mal testen.

[dburkel]

Aber ich frage mich gerade, welches Interface ich tracen soll?!

Da passt nichts so recht.

Intel Gigabit Network Connection -> passt nicht
Microsoft -> passt nicht
MS Tunnel Interface Driver -> keine Ahnung. Da werden keine Pakete hochgezählt.

[froeschi62]

Du wählst auf dem Client Rechner das WAN Interface aus.
Gruß
Dietmar

[froeschi62]

Hi,

ich sehe gerade, du nutzt Windows Vista. Sobald Du Dich hinter einem NAT befindest, funktioniert ShrewSoft über Vista offensichtlich nicht. Ich habe es gerade mit einer UMTS Verbindung probiert, bei der ich vom T-Mobile Gateway eine private Adresse bekomme. Es erscheinen im Client Trace die gleichen Fehlermeldungen wie bei Dir und es erfolgt auch kein Traffic zum Router. Entsprechende Supportanfrage an den Entwickler läuft.
Du musst leider solange auf Windows XP ausweichen. Oder Du nutzt den kostenpflichtigen ADV/NCP Securuty Entry Client. Der läuft unter Vista.
Fazit: Damit ist die Vistatauglichkeit von ShrewSoft v2.1.1 momentan hinfällig obwohl die Installation als solches einwandfrei funktioniert.

Leider hatte ich in der Betaphase von ShrewSoft v2.1.x den letzten VPN Test über ISDN gemacht. Da lief es über Vista.

Gruß
Dietmar

[dburkel]

Schön, dass es bei dir auch nicht funktioniert
ShrewSoft kann aber offensichtlich mit NAT-T umgehen, anscheinend unter Vista doch nicht so recht.

Ich schaue ja gerade nach einer Alternative zum AVC, da dieser derzeit unter Vista auch muckt.
Die DPD-Pakete werden auf manchen Clients nicht mehr beantwortet -> Verbindung bricht alle 3 Minuten ab.

Lancom Support weiß außer DPD sich auch keinen Rat. NCP ist derzeit am forschen. Bisher ohne Erfolg.
Sie wollen wohl meine Teststellung 1:1 nachstellen

[froeschi62]

Mit DPD hatte ich ebenfalls massive Probleme aber auch mit dem ShrewSoft unter Win XP. Bei LC erhält man nur die Standardantwort "alles RFC konform". NCP scheint sich stattdessen wohl mehr zu bemühen.
Die Verbindung bleibt bestehen wenn Du in den Clients (NCP/ShrewSoft) DPD abschaltest. Gestern hatte ich über UMTS mit dem NCP Client (neuste Build 9.04) eine 10 stündige VPN Verbindung (DPD abgeschaltet). UMTS eignet sich zum idealen VPN Stabiltätstest weil Du es hier mit enormen, andauernd schwankenden Latenzen bis zu Timeouts zu tun hast.
Du solltest generell den original NCP Security Entry Client nutzen weil LC mit Ihrem ADV Clients zwei Builds zurückliegt.. Selbst das OEM Pendant von Funkwerk ist schon eine Build weiter. Das kann teilweise, Bugfixes entsprechend, entscheidend sein.

Gruß
Dietmar

[dburkel]

UMTS zu Hause oder wo?

Ich rede eher von dem Fall UMTS im Zug oder unterwegs.
Da ist die DPD schon recht gut. Man möchte ja sehen können, dass die Verbindung nicht mehr aktiv ist. Gerade bei so wackeligen Verbindung wie UMTS.

Generell auch zu Hause ist DPD empfehlenswert. Ich meine, wenn kein Traffic mehr durch den Tunnel geht, muss was mit meinem Internet nicht stimmen, aber für den einfachen User ist die Info im Lancom auch informiert.

[froeschi62]

bei DPD wird der Tunnel aber direkt abgebrochen. Ich habe selbst erlebt, dass trotz Timeouts , sich der Tunnel wieder fängt. Ein vernünftiges DPD müsste noch flexibler einstellbar sein (Router, Client) , um es auch bei problematischen Verbindungen effektiv nutzen zu können.
UMTS nutze ich in Hotels.

Gruß
Dietmar

[dburkel]

Aber wie soll das funktionieren?

Generell ist es ja so, dass die Verbindung abbricht und die alte IP, die beim Tunnelaufbau und -aushandlung verwendet wurde, nicht mehr existent ist.

Danach gibt es ja eine neue IP-Adresse.

[froeschi62]

ich rede hier von kurzen aber vorhandenen Timeouts. Hier wird nicht neu verhandelt aber DPD schlägt hier einfach zu früh an.

Gruß
Dietmar

[dburkel]

Klar, schlägt die da zu früh an, aber in der gleichen Konstellation kann es auch zu einem längerem Timeout kommen oder gar ein Abbruch.
Ohne DPD bleibt der Tunnel (clienseitig) ja immer noch aufrechterhalten und der normale User sieht dies auch in seinem VPN-Client und geht davon aus, dass noch alle ok ist.