Hallo zusammen,
Ich habe das Problem, dass sich nach einem Disconnect des Checkpoint VPN-1 SecureClient (R60, build 044) keine erneute VPN Verbindung nach einem Disconnect herstellen läßt, mit der Meldung => Gateway not responding.
Nach vielen Telefonaten mit der Unternehmens Helpdeskseite ist es sehr wahrscheinlich dass es etwas mit dem VPN Passthrough des Lancom 1811 zu tun hat. Allerdings gibts dort kaum Anwender mit Lancom Routern.
Also der 1811 ist als normaler DSL Router im Einsatz.
Der Checkpoint Vpn-1 SecureClient läuft auf einem Laptop oder einem PC im lokalen LAN. (Verhalten bei beiden identisch)
Der SecureClient ist die VPN-Client Version von Checkpiont die sich per DSL ins VPN einwählen kann, während der Securemote nur per ISDN/Modem EInwahl läuft. Bisher hab ich die ISDN Einwahl benutzt, neuerdings DSL.
Beim ersten mal klappt die VPN Einwahl.
Nach einem Disconnect jedoch nicht mehr.
Es ist erst ein Reboot des LAptop/PC oder des Routers notwendig, damit
es wieder geht.
Wer hat eine Idee?
Ich hoffe ich hab alles Notwendige richtig beschrieben?
Danke im Voraus
Markus
checkpoint VPN-1 passthrough nach disconnect keine neue Verb
Moderator: Lancom-Systems Moderatoren
Hi molbrich
versuch zunächst mal die aktuelle 7.30er Firmware, denn es sind ein paar Dinge an der Maskierung gefixt worden.
siehe: http://www.lancom-forum.de/topic,6855,- ... +7.30.html
Gruß
Backslash
versuch zunächst mal die aktuelle 7.30er Firmware, denn es sind ein paar Dinge an der Maskierung gefixt worden.
siehe: http://www.lancom-forum.de/topic,6855,- ... +7.30.html
- Die IPsec-Pakete des Avaya VPN Clients können maskiert werden.
(...)
- Maskierungsprobleme von parallel laufenden Pings ins WAN wurden behoben.
Gruß
Backslash
Hi molbrich
dann mußt du halt mal einiges tracen...
- ip-router
- firewall
- ip-masquerading
ebenso könnte ein Blick auf die IPSec-Maskierungstabelle helfen. Die kann unter /Setup/IP-Router/1-N-NAT/IPSec-Table eingesehen werden. Am besten parallel zu den Traces (und wiederholt), also:
trace # ip-router firewall ip-masq
rep 1 dir /se/ip-/1-/ipsec
Das Ganze aber bitte nur, wenn sonst nichts anderes auf dem Router los ist...
Gruß
Backslash
dann mußt du halt mal einiges tracen...
- ip-router
- firewall
- ip-masquerading
ebenso könnte ein Blick auf die IPSec-Maskierungstabelle helfen. Die kann unter /Setup/IP-Router/1-N-NAT/IPSec-Table eingesehen werden. Am besten parallel zu den Traces (und wiederholt), also:
trace # ip-router firewall ip-masq
rep 1 dir /se/ip-/1-/ipsec
Das Ganze aber bitte nur, wenn sonst nichts anderes auf dem Router los ist...
Gruß
Backslash
-
froeschi62
- Beiträge: 985
- Registriert: 13 Dez 2004, 10:44
Hallo molbrich,
ich habe es an einem Rechner über einen LC1823 perfekt am laufen. Es muss einiges an Ports freigeschaltet werden.
Stichwort:
1. Firewallregel, TCP/UDP Ports als Zielports: 259,264,2746,18231-18234.
2. Firewallregel: UDP 50.51,108 als IP-Protokolle eintragen.
Gruß
Dietmar
ich habe es an einem Rechner über einen LC1823 perfekt am laufen. Es muss einiges an Ports freigeschaltet werden.
Stichwort:
1. Firewallregel, TCP/UDP Ports als Zielports: 259,264,2746,18231-18234.
2. Firewallregel: UDP 50.51,108 als IP-Protokolle eintragen.
Gruß
Dietmar
Lancom 1823 VOIP
Hallo Dietmar,
danke für Deinen Beitrag, hab von Dir schon mehrere gute Artikel gelesen.
Allerdings hatte ich diese Firewall Freischaltungen bereits eingerichtet,
da die mir durch den EHD genannt wurden. Weiterhin hab ich noch eine Deny All Regel. In den FW Meldungen war nichts Bemerkenswertes zu sehen, außer gelegentlicher etwas seltsamer und nicht reproduzierbarer IntrusionDetections.
Aber: Auch bei komplett deaktivierter Firewall ist das Verhalten identisch, woraus ich mal zu schließen wage, dass es mit der FW nichts zu tun haben kann oder ?
Kann man denn nichts aus dem speziellen immer reproduzierbaren Verhalten ableiten, dass eine erste Verbindung nach Neustart des Routers einwandfrei klappt und lange stabil läuft und jede weitere scheitert ?
Bei jeder weiteren Verbindung kommt der Dialog bis zu "User authenticated by SecurID" und dann steht der Dialog bis er abbricht mit "Gateway not responding", aber die ersten Kommunikationen haben geklappt.
viele Grüße Markus
PS: Dann werd ich mal mit dem Tracen beginnen
danke für Deinen Beitrag, hab von Dir schon mehrere gute Artikel gelesen.
Allerdings hatte ich diese Firewall Freischaltungen bereits eingerichtet,
da die mir durch den EHD genannt wurden. Weiterhin hab ich noch eine Deny All Regel. In den FW Meldungen war nichts Bemerkenswertes zu sehen, außer gelegentlicher etwas seltsamer und nicht reproduzierbarer IntrusionDetections.
Aber: Auch bei komplett deaktivierter Firewall ist das Verhalten identisch, woraus ich mal zu schließen wage, dass es mit der FW nichts zu tun haben kann oder ?
Kann man denn nichts aus dem speziellen immer reproduzierbaren Verhalten ableiten, dass eine erste Verbindung nach Neustart des Routers einwandfrei klappt und lange stabil läuft und jede weitere scheitert ?
Bei jeder weiteren Verbindung kommt der Dialog bis zu "User authenticated by SecurID" und dann steht der Dialog bis er abbricht mit "Gateway not responding", aber die ersten Kommunikationen haben geklappt.
viele Grüße Markus
PS: Dann werd ich mal mit dem Tracen beginnen
trace # ip-router firewall ip-masq
liefert folgende Ausgaben im Sekundentakt: was ist das ?
10.255.255.35 gibts bei mir gar nicht, .40 ist mein PC.
[IP-Router] 2008/03/27 10:14:40,240
IP-Router Rx (intern, RtgTag: 0):
DstIP: 10.255.255.35, SrcIP: 10.255.255.247, Len: 99, DSCP: EF (46), ECT: 0, CE:
0
Prot.: UDP (17), DstPort: 514, SrcPort: 514
Route: LAN Tx (INTRANET):
[IP-Router] 2008/03/27 10:14:40,240
IP-Router Rx (intern, RtgTag: 0):
DstIP: 10.255.255.40, SrcIP: 10.255.255.247, Len: 99, DSCP: EF (46), ECT: 0, CE:
0
Prot.: UDP (17), DstPort: 514, SrcPort: 514
Route: LAN Tx (INTRANET):
liefert folgende Ausgaben im Sekundentakt: was ist das ?
10.255.255.35 gibts bei mir gar nicht, .40 ist mein PC.
[IP-Router] 2008/03/27 10:14:40,240
IP-Router Rx (intern, RtgTag: 0):
DstIP: 10.255.255.35, SrcIP: 10.255.255.247, Len: 99, DSCP: EF (46), ECT: 0, CE:
0
Prot.: UDP (17), DstPort: 514, SrcPort: 514
Route: LAN Tx (INTRANET):
[IP-Router] 2008/03/27 10:14:40,240
IP-Router Rx (intern, RtgTag: 0):
DstIP: 10.255.255.40, SrcIP: 10.255.255.247, Len: 99, DSCP: EF (46), ECT: 0, CE:
0
Prot.: UDP (17), DstPort: 514, SrcPort: 514
Route: LAN Tx (INTRANET):
Hallo backslash,
das bestätigt meine Vermutung mit einer nicht richtig abgebauten Verbindung und einem existierenden Timeout.+
Folgender Eintrag steht nach dem Disconnect im Trace und das Timeout zählt runter. Wie ist das zu verstehen/zu beheben?
remote-Address local-Address rc-hi rc-lo lc-hi lc-lo remote
-SPI local-SPI Timeout CO NL NR DP Flag
--------------------------------------------------------------------------------
-----------------------------------------------------------
193.23.104.131 10.255.255.40 9171bc66 6aa335df a911335e c45f0c04 000000
00 00000000 1632 0 0 0 0 0010
[1 Sec.-REPEAT];
>
remote-Address local-Address rc-hi rc-lo lc-hi lc-lo remote
-SPI local-SPI Timeout CO NL NR DP Flag
--------------------------------------------------------------------------------
-----------------------------------------------------------
193.23.104.131 10.255.255.40 9171bc66 6aa335df a911335e c45f0c04 000000
00 00000000 1631 0 0 0 0 0010
das bestätigt meine Vermutung mit einer nicht richtig abgebauten Verbindung und einem existierenden Timeout.+
Folgender Eintrag steht nach dem Disconnect im Trace und das Timeout zählt runter. Wie ist das zu verstehen/zu beheben?
remote-Address local-Address rc-hi rc-lo lc-hi lc-lo remote
-SPI local-SPI Timeout CO NL NR DP Flag
--------------------------------------------------------------------------------
-----------------------------------------------------------
193.23.104.131 10.255.255.40 9171bc66 6aa335df a911335e c45f0c04 000000
00 00000000 1632 0 0 0 0 0010
[1 Sec.-REPEAT];
>
remote-Address local-Address rc-hi rc-lo lc-hi lc-lo remote
-SPI local-SPI Timeout CO NL NR DP Flag
--------------------------------------------------------------------------------
-----------------------------------------------------------
193.23.104.131 10.255.255.40 9171bc66 6aa335df a911335e c45f0c04 000000
00 00000000 1631 0 0 0 0 0010
Hallo backslash,
ein Deaktivieren und wieder Aktivieren der NW Karte ändert nichts,
nach wie vor ist kein erneutes Connect mgl.
Jedoch wenn man das Timeout abwartet, geht unmittelbar danach die Einwahl wieder.
Bis dahin kommt während der Timeout runterzählt:
[IP-masquerading] 2008/03/27 11:17:19,970
masquerading failed for port 500
viele Grüße Markus
ein Deaktivieren und wieder Aktivieren der NW Karte ändert nichts,
nach wie vor ist kein erneutes Connect mgl.
Jedoch wenn man das Timeout abwartet, geht unmittelbar danach die Einwahl wieder.
Bis dahin kommt während der Timeout runterzählt:
[IP-masquerading] 2008/03/27 11:17:19,970
masquerading failed for port 500
viele Grüße Markus
Hi molbrich
Die Spalten für local und remote SPI sind jeweils auf 0, da der Client NAT-T macht (zu erkennen an den Flags: 0010 = NAT-T).
Das die Zeile in der Tabelle liegen bleibt, liegt einzig daran, daß bei NAT-T die IKE-Verhandlung irgendwann vom Port 500 auf den Port 4500 wechselt und das LANCOM ab diesem Zeitpunkt die Verhandlung nicht mehr verfolgt (wozu auch, es sind ja nun ganz gewöhnliche UDP-Pakete).
Eigentlich könnte das LANCOM den Eintrag auch ganz entfernen, gäbe es da nicht auch proprietäte NAT-T-Varianten, die nur die ESP-Pakete in einen UDP-Stream auf einem anderen Port einpacken, die IKE-Verhandlung aber weiterhin über Port 500 abwickeln.
Hier wäre nun ein Wireshark-Mitschnitt der beiden Verbindungen hilfreich, um zu sehen, was da schief läuft. Denn wenn ich das mit dem LANCOM-Client mache, funktioniert das problemlos...
Gruß
Backslash
Das sind Syslog-Pakete... Wenn das LANCOM die sendet, dann hast du das unter Meldungen -> Syslog -> Syslog-Clients entsprechend konfiguriert.liefert folgende Ausgaben im Sekundentakt: was ist das ?
10.255.255.35 gibts bei mir gar nicht, .40 ist mein PC.
[IP-Router] 2008/03/27 10:14:40,240
IP-Router Rx (intern, RtgTag: 0):
DstIP: 10.255.255.35, SrcIP: 10.255.255.247, Len: 99, DSCP: EF (46), ECT: 0, CE:
0
Prot.: UDP (17), DstPort: 514, SrcPort: 514
Route: LAN Tx (INTRANET):
[IP-Router] 2008/03/27 10:14:40,240
IP-Router Rx (intern, RtgTag: 0):
DstIP: 10.255.255.40, SrcIP: 10.255.255.247, Len: 99, DSCP: EF (46), ECT: 0, CE:
0
Prot.: UDP (17), DstPort: 514, SrcPort: 514
Route: LAN Tx (INTRANET):
Natürlich existiert ein Timeout - und der ist auch mit 2000 Sekunden recht hoch, jedoch verhindert der keinen Neuaufbau der Verbindung - es wird halt einfach nur eine weitere Zeile aufgenommen - mit gleichen Adressen, aber anderen Cookies (rc-hi rc-lo lc-hi lc-lo)...das bestätigt meine Vermutung mit einer nicht richtig abgebauten Verbindung und einem existierenden Timeout.+
Folgender Eintrag steht nach dem Disconnect im Trace und das Timeout zählt runter. Wie ist das zu verstehen/zu beheben?
remote-Address local-Address rc-hi rc-lo lc-hi lc-lo remote
-SPI local-SPI Timeout CO NL NR DP Flag
--------------------------------------------------------------------------------
-----------------------------------------------------------
193.23.104.131 10.255.255.40 9171bc66 6aa335df a911335e c45f0c04 000000
00 00000000 1632 0 0 0 0 0010
[1 Sec.-REPEAT];
>
remote-Address local-Address rc-hi rc-lo lc-hi lc-lo remote
-SPI local-SPI Timeout CO NL NR DP Flag
--------------------------------------------------------------------------------
-----------------------------------------------------------
193.23.104.131 10.255.255.40 9171bc66 6aa335df a911335e c45f0c04 000000
00 00000000 1631 0 0 0 0 0010
Die Spalten für local und remote SPI sind jeweils auf 0, da der Client NAT-T macht (zu erkennen an den Flags: 0010 = NAT-T).
Das die Zeile in der Tabelle liegen bleibt, liegt einzig daran, daß bei NAT-T die IKE-Verhandlung irgendwann vom Port 500 auf den Port 4500 wechselt und das LANCOM ab diesem Zeitpunkt die Verhandlung nicht mehr verfolgt (wozu auch, es sind ja nun ganz gewöhnliche UDP-Pakete).
Eigentlich könnte das LANCOM den Eintrag auch ganz entfernen, gäbe es da nicht auch proprietäte NAT-T-Varianten, die nur die ESP-Pakete in einen UDP-Stream auf einem anderen Port einpacken, die IKE-Verhandlung aber weiterhin über Port 500 abwickeln.
Genau das sollte eigentlich nicht passieren - stattdessen sollte einfach ein neuer Eintrag in der IPSec-Maskierungstabelle aufgenommen werden.beim erneuten Verbindungsversuch nach disconnect innerhalb der Timeout ZEit kommt folgendes im Trace:
[IP-masquerading] 2008/03/27 11:17:19,970
masquerading failed for port 500
Hier wäre nun ein Wireshark-Mitschnitt der beiden Verbindungen hilfreich, um zu sehen, was da schief läuft. Denn wenn ich das mit dem LANCOM-Client mache, funktioniert das problemlos...
Gruß
Backslash
Hallo backslash,
sorry, aber was VPN betrifft bin ich purer Anwender, der mit seinem Laptop über VPN-1 SecureClient und seinem hochwertigen Lancom Router ins Firmennetz möchte. Von den Interna hab ich echt null Ahnung.
1. Das mit dem Funktionieren nach Rechner Neustart muss ich revidieren.
Nach deiner letzten Nachricht hab ich das nochmal mehrfach geprüft und es ging auch nach PC / Laptop Neustart nicht wieder sich zu verbinden. Nur ein Router Kaltstart über Web Oberfläche half (nicht mal ein System boot).
2. Entweder war das vor dem gestrigen Wechsel der FW von 7.26 auf 7.30
noch anders oder es war ein Zufall, dass der Neustart und das Timeout zusammenfielen.
3. Ich hab noch einen anderen Test gemacht. Während der PC (IP = .40) nach einem Disconnect nicht wieder connecten kann, starte ich ein Connect vom Laptop aus (garantiert innerhalb der timeout zeit). Das Connecten mit der IP = .169 klappt auch wie erwartet beim ersten Mal. Dann Disconnect und erneut versuchen. Dann klappt es auch beim Laptop nicht mehr.
D.h. parallel zu den Tabelleneinträgen werden die entsprechenden IP Adressen bis zum Ende des Timeout an einer erneuten Einwahl gehindert.
Wenn das Timeout abgelaufen ist, klappt's wieder.
4. Ein weiterer Test: Ich hab direkt anschließend an 3. die IP Adresse der NW Karte des Laptop von 169 auf 170 geändert und dann klappte das Connecten.
Erneut Disconnect und wieder Connect, geht nicht mehr mit derselben IP.
Also für mich als Laie sieht es wirklich so aus, als sei die Zeile mit dem Timeout und der jeweiligen IP ausschlaggebend bzw. das, was sich dahinter verbirgt.
Gern mach ich noch einen Trace, aber dann mußt Du mir bitte genaue Anweisungen geben.
Danke im Voraus
Markus
sorry, aber was VPN betrifft bin ich purer Anwender, der mit seinem Laptop über VPN-1 SecureClient und seinem hochwertigen Lancom Router ins Firmennetz möchte. Von den Interna hab ich echt null Ahnung.
1. Das mit dem Funktionieren nach Rechner Neustart muss ich revidieren.
Nach deiner letzten Nachricht hab ich das nochmal mehrfach geprüft und es ging auch nach PC / Laptop Neustart nicht wieder sich zu verbinden. Nur ein Router Kaltstart über Web Oberfläche half (nicht mal ein System boot).
2. Entweder war das vor dem gestrigen Wechsel der FW von 7.26 auf 7.30
noch anders oder es war ein Zufall, dass der Neustart und das Timeout zusammenfielen.
3. Ich hab noch einen anderen Test gemacht. Während der PC (IP = .40) nach einem Disconnect nicht wieder connecten kann, starte ich ein Connect vom Laptop aus (garantiert innerhalb der timeout zeit). Das Connecten mit der IP = .169 klappt auch wie erwartet beim ersten Mal. Dann Disconnect und erneut versuchen. Dann klappt es auch beim Laptop nicht mehr.
D.h. parallel zu den Tabelleneinträgen werden die entsprechenden IP Adressen bis zum Ende des Timeout an einer erneuten Einwahl gehindert.
Wenn das Timeout abgelaufen ist, klappt's wieder.
4. Ein weiterer Test: Ich hab direkt anschließend an 3. die IP Adresse der NW Karte des Laptop von 169 auf 170 geändert und dann klappte das Connecten.
Erneut Disconnect und wieder Connect, geht nicht mehr mit derselben IP.
Also für mich als Laie sieht es wirklich so aus, als sei die Zeile mit dem Timeout und der jeweiligen IP ausschlaggebend bzw. das, was sich dahinter verbirgt.
Gern mach ich noch einen Trace, aber dann mußt Du mir bitte genaue Anweisungen geben.
Danke im Voraus
Markus
Hi molbrich
Daher die Frage nach dem Wireshark-Mitschnitt - denn damit kann man halt die IKE-Verhandlung paketweise verfolgen und so ggf. den Fehler eingrenzen...
Als erstes lädst du dir Wireshark von http://www.wireshark.org/download herunter und istallierst es auf dem Rechner, auf dem auch der VPN-Client läuft. (für Windows: http://www.wireshark.org/download/win32 ... 0.99.8.exe)
Dann startest du Wireshark und wählst im Menü Capture den Punkt Interfaces aus.
Im sich öffrnenden Dialog klickst du auf den Button Start der sich rechts neben deiner Netzwerkkarte befindet. Es öffnet sich ein Dialog, der anzeigt, wie viele Pakete bisher mitgeschnitten wurden. Dieser Dialog hat den Titel Capture from Netwerkkarte
Danach startest du den VPN-Client, baust den Tunnel auf, pingst einmal auf die andere Seite, baust den Tunnel wieder ab und startest den zweiten Aufbauversuch...
Danach dürckst du auf dem Stop-Button im Capture from.., Dialog... Nun kannst du den Mitschnitt anschauen und über File -> Save as speichern
Gruß
Backslash
Daß es mit Ändern der IP-Adressen sofort funktioniert ist klar, denn es sind dann ja *eindeutig* neue Einträge in der Tabelle. Es sollte aber auch mit der gleichen IP-Adresse mehrfach hintereinander funktionieren - und mit dem LANCOM-Client funktioniert es ja auch korrekt...Also für mich als Laie sieht es wirklich so aus, als sei die Zeile mit dem Timeout und der jeweiligen IP ausschlaggebend bzw. das, was sich dahinter verbirgt.
Daher die Frage nach dem Wireshark-Mitschnitt - denn damit kann man halt die IKE-Verhandlung paketweise verfolgen und so ggf. den Fehler eingrenzen...
Gern mach ich noch einen Trace, aber dann mußt Du mir bitte genaue Anweisungen geben.
Als erstes lädst du dir Wireshark von http://www.wireshark.org/download herunter und istallierst es auf dem Rechner, auf dem auch der VPN-Client läuft. (für Windows: http://www.wireshark.org/download/win32 ... 0.99.8.exe)
Dann startest du Wireshark und wählst im Menü Capture den Punkt Interfaces aus.
Im sich öffrnenden Dialog klickst du auf den Button Start der sich rechts neben deiner Netzwerkkarte befindet. Es öffnet sich ein Dialog, der anzeigt, wie viele Pakete bisher mitgeschnitten wurden. Dieser Dialog hat den Titel Capture from Netwerkkarte
Danach startest du den VPN-Client, baust den Tunnel auf, pingst einmal auf die andere Seite, baust den Tunnel wieder ab und startest den zweiten Aufbauversuch...
Danach dürckst du auf dem Stop-Button im Capture from.., Dialog... Nun kannst du den Mitschnitt anschauen und über File -> Save as speichern
Gruß
Backslash