Hi molbrich,
danke für den Mitschnitt... Ich hab gerade mal reingeschaut und sehe mit Entsetzen, was die da machen. Das ist meiner Meinung nach in jedem Fall ein Fehler des Clients!
Als erstes baut der Client eine TCP-Verbinung zum Port 500 auf, um darüber die IKE-Verhandlung zu fahren. Das wäre gar kein Problem, da sich das LANCOM bei IPSEC nur UDP-Pakete anschaut - und genau hier liegt der Hund begraben:
Der Client fällt irgendwann auf UDP zurück (Paket 66), was das LANCOM als "Session Recovery" wertet. Das ist beim ersten Mal auch noch kein Problem...
Es wird bei der zweiten Einwahl aber zu einem Problem: Da das LANCOM keine keine ESP-Pakete gesehen hat - hier wird ja NAT-T (in einer proprietären Variante) gemacht - sind die SPIs in der Maskierungstabelle auf 0. In diesem Zustand akzeptiert das LANCOM aber kein "plötzliches" Auftauen einer weiteren Session. Es würde eine *neue* IKE-Verhandlung akzeptieren, aber den Start der Verhandlung bekommt es ja nicht mit, da er in der TCP-Session läuft...
Das ist eindeutig ein Fehlverhalten des Checkpoint-Clients - denn wozu fällt der Plötzlich auf UDP, wenn er die IKE-Verhandlung doch in einer TCP-Session führt.
Da kann der Hersteller noch so sehr sagen, das wäre ein Problem des IPSec-Passthrough. Würde er die Verhandlung komplett über UDP führen oder nicht plötzlich auf UDP zurückfallen, dann gäbe es kein Problem...
Dir bleibt daher nur, den Hersteller dazu zu bringen, den Client sauber zu programmieren und in der Zwischenzeit den IPSEC-Timeout im LANCOM drastisch herabzusetzen, z.B. auf 10 Sekunden... Den Timeout findest du unter IP-Router -> Maskierung -> IPSec-Aging
Gruß
Backslash
checkpoint VPN-1 passthrough nach disconnect keine neue Verb
Moderator: Lancom-Systems Moderatoren
Hallo Backslash,
erstmal Danke, dafür dass man bei Lancom in diesem Forum angehört und ersthaft behandelt wird, d.h. Danke dass die Firma dieses Forum unterstützt.
Sicher werd ich meine Zeit nicht weiter damit verbringen können mich an Checkpoint wer weiss wo auch immer zu wenden.
Ich als einzelner Endanwender kann auch absolut nichts dazu sagen, das müßtet Ihr unter Euch Firmen ausmachen, denn immerhin sind Lancom und Checkpoint beides im VPN Bereich angesehene und nicht kleine Firmen die sich da einigen sollten.
Allerdings stimmt es mich etwas nachdenklich, dass der Checkpoint Client mit den 0-8-15 Telecom + Fritzbox Schleudern problemlos läuft und nur mit Lancom nicht. (VW Helpdesk)
Weiterhin würde mich interessieren, was froeschi dazu sagt, bei ihm läuft es ja anscheinend.
Also so ganz aus der Verantwortung lasse ich Euch da zumindest gedanklich nicht raus.
viele Grüße Markus
erstmal Danke, dafür dass man bei Lancom in diesem Forum angehört und ersthaft behandelt wird, d.h. Danke dass die Firma dieses Forum unterstützt.
Sicher werd ich meine Zeit nicht weiter damit verbringen können mich an Checkpoint wer weiss wo auch immer zu wenden.
Ich als einzelner Endanwender kann auch absolut nichts dazu sagen, das müßtet Ihr unter Euch Firmen ausmachen, denn immerhin sind Lancom und Checkpoint beides im VPN Bereich angesehene und nicht kleine Firmen die sich da einigen sollten.
Allerdings stimmt es mich etwas nachdenklich, dass der Checkpoint Client mit den 0-8-15 Telecom + Fritzbox Schleudern problemlos läuft und nur mit Lancom nicht. (VW Helpdesk)
Weiterhin würde mich interessieren, was froeschi dazu sagt, bei ihm läuft es ja anscheinend.
Also so ganz aus der Verantwortung lasse ich Euch da zumindest gedanklich nicht raus.
viele Grüße Markus
Hallo Backslash,
ich habe Deinen Workaround unter
IP-Router -> Maskierung -> IPSec-Aging = 10 sekunden statt 2000 eingetragen und damit ist mein Problem soweit umgangen, es geht, danke.
Dabei frag ich mich natürlich, wann die 2000 eigentlich sinnvoll sind und ob das nicht von Euch standardmäßig einfach auf 10 stehen sollte.
Fraglich auch, was fröschi da drin stehen hat/hatte.
Er benutzt den Checkpoint Client allerdings nun nicht mehr
und hat sich deshalb nicht weiter zu Wort gemeldet.
Aber ich denke doch dass der ziemlich verbeitet ist.
viele Grüße und Danke Markus
ich habe Deinen Workaround unter
IP-Router -> Maskierung -> IPSec-Aging = 10 sekunden statt 2000 eingetragen und damit ist mein Problem soweit umgangen, es geht, danke.
Dabei frag ich mich natürlich, wann die 2000 eigentlich sinnvoll sind und ob das nicht von Euch standardmäßig einfach auf 10 stehen sollte.
Fraglich auch, was fröschi da drin stehen hat/hatte.
Er benutzt den Checkpoint Client allerdings nun nicht mehr
und hat sich deshalb nicht weiter zu Wort gemeldet.
Aber ich denke doch dass der ziemlich verbeitet ist.
viele Grüße und Danke Markus
Hi molbrich
Das Problem bei IPSec ist, daß ESP zunächst nicht maskierbar ist. Im ESP-Header ist kein änderbares Feld vorhanden, in dem der Router die Informationen für die Rückübersetzung ablegen kann - bei UDP und TCP wird hierzu der Quellport verwendet. Nun gibt es drei Möglichkeiten IPSec doch durch eine Maskierung hindurch zu bekommen:
1. NAT-T. Hierbei werden die ESP-Pakete in UDP-Pakete eingepacket, bei denen die Maskierung einfach wieder den Quellport ändern kann.
2. Billig-Lösung: sobald ein IKE-Paket erkannt wird, merkt sich der Router die Quelladresse des Pakets und schickt alle vom WAN empfangenen ESP-Paket an diese Adresse weiter
3. die LANCOM-Lösung: Hierbei verfolgt der Router die IKE-Verhandlung mit soweit es geht, denn ab dem zweiten Paket ist alles bis auf den Message-Typ verschlüsselt. Anhand des Message-Typs und mit Hilfe der Kristallkugel des Entwicklers wird versucht, eine Zuordnung der ESP-Pakete herzustellen. Diese trägt das LANCOM dann als lokalen und remoten SPI in die IPSec-Maskierungstabelle ein. Sobald das geschehen ist, können empfangene ESP-Pakete eindeutig zugewiesen werden.
Das Ganze hat natürlich einen Schönheitsfehler: Damit es überhaupt funktioniert, muß die gesamte Verhandlung nachgehalten werden. Und da hier der Checkpoint-Client eindeutig Mist baut, schlägt auch der Blick in die Kristallkugel fehl...
Wie schon gesagt: würde der Client die IKE-Verhandlung komplett in UDP machen, bzw. nicht aus dem TCP herausfallen, gäbe es kein Problem
Gruß
Backslash
nun ja, das könnte daran nliegen, daß diese Router gar kein IPSec-Passthrogh können oder wenn, dann nur mit einem Client.Allerdings stimmt es mich etwas nachdenklich, dass der Checkpoint Client mit den 0-8-15 Telecom + Fritzbox Schleudern problemlos läuft und nur mit Lancom nicht. (VW Helpdesk)
Das Problem bei IPSec ist, daß ESP zunächst nicht maskierbar ist. Im ESP-Header ist kein änderbares Feld vorhanden, in dem der Router die Informationen für die Rückübersetzung ablegen kann - bei UDP und TCP wird hierzu der Quellport verwendet. Nun gibt es drei Möglichkeiten IPSec doch durch eine Maskierung hindurch zu bekommen:
1. NAT-T. Hierbei werden die ESP-Pakete in UDP-Pakete eingepacket, bei denen die Maskierung einfach wieder den Quellport ändern kann.
2. Billig-Lösung: sobald ein IKE-Paket erkannt wird, merkt sich der Router die Quelladresse des Pakets und schickt alle vom WAN empfangenen ESP-Paket an diese Adresse weiter
3. die LANCOM-Lösung: Hierbei verfolgt der Router die IKE-Verhandlung mit soweit es geht, denn ab dem zweiten Paket ist alles bis auf den Message-Typ verschlüsselt. Anhand des Message-Typs und mit Hilfe der Kristallkugel des Entwicklers wird versucht, eine Zuordnung der ESP-Pakete herzustellen. Diese trägt das LANCOM dann als lokalen und remoten SPI in die IPSec-Maskierungstabelle ein. Sobald das geschehen ist, können empfangene ESP-Pakete eindeutig zugewiesen werden.
Das Ganze hat natürlich einen Schönheitsfehler: Damit es überhaupt funktioniert, muß die gesamte Verhandlung nachgehalten werden. Und da hier der Checkpoint-Client eindeutig Mist baut, schlägt auch der Blick in die Kristallkugel fehl...
Wie schon gesagt: würde der Client die IKE-Verhandlung komplett in UDP machen, bzw. nicht aus dem TCP herausfallen, gäbe es kein Problem
Gruß
Backslash
Hi molbrich
Stößt hingegen der Server das Rekeying an, und es gibt keinen Eintrag in der Maskierungstabelle, dann baut der Server die Verbindung ab, weil er keine Antwort vom Cliengt erhält.
Wenn Client und Sever Dead-Peer-Detection (DPD) beherrschen, dann wird spätestens nach 30 Sekunden ein IKE-Paket übertragen, weshalb man dann die Zeit auch auf 30 (besser 40) Sekunden herabsetzen kann. Da aber nicht jeder Client und jeder Server DPD beherrscht muß der Tiemout im Default halt mindestens so groß sein, daß die Zeit zwischen zwei Rekeyings überbrückt wird.
Gruß
Backslash
Die 2000 Sekunden kommen daher, daß es im IPSec die Möglichkeit des Rekeyings gibt. Das Rekeying kann dabei sowohl vom Client als auch vom Server angestoßen werden. Stößt der Client das Rekeying an, gibt es kein Problem auch bei kürzerem Tiemout. Das LANCOM führt dann ein Session-Recovery durch. Dabei werden aber alle ESP-Pakete des Servers solange verworfen, bis der Client wieder ein ESP-Paket gesendet hat (siehe "Kristallkugel" in meinem letzten Posting).Dabei frag ich mich natürlich, wann die 2000 eigentlich sinnvoll sind und ob das nicht von Euch standardmäßig einfach auf 10 stehen sollte.
Stößt hingegen der Server das Rekeying an, und es gibt keinen Eintrag in der Maskierungstabelle, dann baut der Server die Verbindung ab, weil er keine Antwort vom Cliengt erhält.
Wenn Client und Sever Dead-Peer-Detection (DPD) beherrschen, dann wird spätestens nach 30 Sekunden ein IKE-Paket übertragen, weshalb man dann die Zeit auch auf 30 (besser 40) Sekunden herabsetzen kann. Da aber nicht jeder Client und jeder Server DPD beherrscht muß der Tiemout im Default halt mindestens so groß sein, daß die Zeit zwischen zwei Rekeyings überbrückt wird.
Gruß
Backslash
Hallo Markus,
Also los, die wesentlichen Punkte rausarbeiten und klar definieren und dann übersetzen und ab die Post. Schließlich hat die Software doch auch Geld gekostet und dann kann man doch auch verlangen, dass sie funktioniert.
Viele Grüße,
Jirka
Du solltest es aber wenigstens versuchen! Wirklich. Wo der Fall jetzt schon mal so genau analysiert wurde, sollte das nicht für umsonst gewesen sein. Es ist mit Firmen dieser Größenordnung nicht immer leicht, aber mitunter hat man Glück ... Ich hatte vor einem Jahr mal DynDNS.org einige Verbesserungen vorgeschlagen, das wurde erst konsequent abgelehnt, dann habe ich nicht locker gelassen, bis ich vom Support zur Entwicklungsabteilung durchgestellt wurde. Da musste man allerdings wieder etwas argumentieren ... und eines Tages dann die Nachricht, man hätte das für sinnvoll erachtet und denkt darüber nach. 3 Monate später wars dann endlich umgesetzt.Sicher werd ich meine Zeit nicht weiter damit verbringen können mich an Checkpoint wer weiss wo auch immer zu wenden.
Also los, die wesentlichen Punkte rausarbeiten und klar definieren und dann übersetzen und ab die Post. Schließlich hat die Software doch auch Geld gekostet und dann kann man doch auch verlangen, dass sie funktioniert.
Viele Grüße,
Jirka
-
froeschi62
- Beiträge: 985
- Registriert: 13 Dez 2004, 10:44
Hallo Zsammen.
seltsamerweise hat bei mir aber der Checkpoint VPN1-Secure Client mit den hier vorgestellten Firewallregeln problemlos funktioniert. Ich konnte jederzeit gegen den Checkpoint VPN Server immer wieder eine Verbindung aufbauen. Das sowohl damals auf einem 1821er als auch jetzt auf dem 1823er. Allerdings sind wir jetzt auf eine ECOS Lösung umgestiegen und ich habe den Client deinstalliert.
Deshalb vermute ich bei Ihm eine nicht ganz korrekt erfolgte Konfiguration des Checkpoint VPN Servers und Clients.
Viele Grüße
Dietmar
seltsamerweise hat bei mir aber der Checkpoint VPN1-Secure Client mit den hier vorgestellten Firewallregeln problemlos funktioniert. Ich konnte jederzeit gegen den Checkpoint VPN Server immer wieder eine Verbindung aufbauen. Das sowohl damals auf einem 1821er als auch jetzt auf dem 1823er. Allerdings sind wir jetzt auf eine ECOS Lösung umgestiegen und ich habe den Client deinstalliert.
Deshalb vermute ich bei Ihm eine nicht ganz korrekt erfolgte Konfiguration des Checkpoint VPN Servers und Clients.
Viele Grüße
Dietmar
Lancom 1823 VOIP
Übrigens macht der Checkpoint Client weitere Probleme,
ich hab erst jetzt festgestellt, dass nach einem VPN Connect keine IP Kommunikation (selbst ping, usw) des PC mit anderen PCs mehr möglich ist, solange das SecuremoteProtokoll an die NW Karte gebunden ist.
Erschreckend ist, dass dies selbst ein Reboot des PC überdauert.
Entfernt man das Häkchen bei dem Protokoll, gehts wieder.
Ähnliche Erfahrungen sind auch im Checkpoint Forum beschrieben.
https://forums.checkpoint.com/forums/th ... 9&tstart=0
Gruß Markus
ich hab erst jetzt festgestellt, dass nach einem VPN Connect keine IP Kommunikation (selbst ping, usw) des PC mit anderen PCs mehr möglich ist, solange das SecuremoteProtokoll an die NW Karte gebunden ist.
Erschreckend ist, dass dies selbst ein Reboot des PC überdauert.
Entfernt man das Häkchen bei dem Protokoll, gehts wieder.
Ähnliche Erfahrungen sind auch im Checkpoint Forum beschrieben.
https://forums.checkpoint.com/forums/th ... 9&tstart=0
Gruß Markus