12
VPN-problem mit Checkpoint Secureclient R60 und TP-Link 941ND
Hallo Kollegen,
Mal wieder ein VPN-Problem
Vorgeschichte:
VPN funktionierte bisher einwandfrei (und funktioniert weiterhin) mit einem Speedport (genaues Modell muß ich erst erfragen)
Problem:
Mit einem TP-Link 941ND bekommt er keine Verbindung zur zentrale, Meldung lautet: Keine Antwort von host (o.ä.).
Ich bekam einen Anruf von einem Außendienstmitarbeiter, daß er keine VPN-verbindung zur Zentrale bekommt. Die Verbindung wird mit dem Secureclient R60 zu einer CP FW-1 NG aufgebaut. Genauen Release-Stand kann ich leider nicht nachschauen, da diese von einem anderen Dienstleister betreut wird.
Solange er üebr Kabel mit den Speedport sich verbindet, funktioniert die VPN-verbindung.
Nimmt er den TP-Link mit einem DSL-Modem (oder den Speedport mit PPPoE-Passtrough), um auch über WLAN Internet zu haben, funktioniert die VPN-verbindung nicht. Es kommen keine Antworten von der Firewall zurück. Internet (auch andere Dienste als http/https) funktioniert einwandfrei.
Der TP-Link ist auf dem neusten Firmware-Stand (frisch vom hersteller gezogen), die Einstellunge für SPI-Firewall, PPTP, L2TP und IPsec sind auf enabled (wobei es keine Unterschied macht ob man die auf disabled setzt (alle 16 Kombinationen durchprobiert).
Es kommen auf jeden Fall keine antworten von der Firewall zurück. Da ich leider keine Kotrolle üebr die Checkpoitn habe, kann ich nicht per sniffer nachschauen,. ob die Pakete dort ankommen und nicht beantwortet werden oder der TP-link der "böse" ist. Der Kunde hat leider keinen zweiten Rechner, mit dem er die PPPoE-Verbindung sniffen könnte.
Ich weiß, daß die Informationen etwas dürftig sind, aber vielleicht ist ja schon mal jemand von Euch über ein ähnliches Problem gestolpert. und kann mir einen Hinweis geben, in welcher Richtung ich weitersuchen könnte. Google war da leider etwas unergiebig.
Nachtrag: Könnte es ein MTU-Problem mit T-Online sein? Ich habe im Moment leider keine Möglichkeit das zu verifizieren.
Mal wieder ein VPN-Problem
Vorgeschichte:
VPN funktionierte bisher einwandfrei (und funktioniert weiterhin) mit einem Speedport (genaues Modell muß ich erst erfragen)
Problem:
Mit einem TP-Link 941ND bekommt er keine Verbindung zur zentrale, Meldung lautet: Keine Antwort von host (o.ä.).
Ich bekam einen Anruf von einem Außendienstmitarbeiter, daß er keine VPN-verbindung zur Zentrale bekommt. Die Verbindung wird mit dem Secureclient R60 zu einer CP FW-1 NG aufgebaut. Genauen Release-Stand kann ich leider nicht nachschauen, da diese von einem anderen Dienstleister betreut wird.
Solange er üebr Kabel mit den Speedport sich verbindet, funktioniert die VPN-verbindung.
Nimmt er den TP-Link mit einem DSL-Modem (oder den Speedport mit PPPoE-Passtrough), um auch über WLAN Internet zu haben, funktioniert die VPN-verbindung nicht. Es kommen keine Antworten von der Firewall zurück. Internet (auch andere Dienste als http/https) funktioniert einwandfrei.
Der TP-Link ist auf dem neusten Firmware-Stand (frisch vom hersteller gezogen), die Einstellunge für SPI-Firewall, PPTP, L2TP und IPsec sind auf enabled (wobei es keine Unterschied macht ob man die auf disabled setzt (alle 16 Kombinationen durchprobiert).
Es kommen auf jeden Fall keine antworten von der Firewall zurück. Da ich leider keine Kotrolle üebr die Checkpoitn habe, kann ich nicht per sniffer nachschauen,. ob die Pakete dort ankommen und nicht beantwortet werden oder der TP-link der "böse" ist. Der Kunde hat leider keinen zweiten Rechner, mit dem er die PPPoE-Verbindung sniffen könnte.
Ich weiß, daß die Informationen etwas dürftig sind, aber vielleicht ist ja schon mal jemand von Euch über ein ähnliches Problem gestolpert. und kann mir einen Hinweis geben, in welcher Richtung ich weitersuchen könnte. Google war da leider etwas unergiebig.
Nachtrag: Könnte es ein MTU-Problem mit T-Online sein? Ich habe im Moment leider keine Möglichkeit das zu verifizieren.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 168628
Url: https://administrator.de/forum/vpn-problem-mit-checkpoint-secureclient-r60-und-tp-link-941nd-168628.html
Ausgedruckt am: 05.04.2025 um 21:04 Uhr
12 Kommentare
Neuester Kommentar
Na ja TP Links bewegt sich am untersten Ende der Preisskala. Unverständlich warum man im einem Firmenumfeld auf Consumer China Billigsthardware setzen muss und da auch noch den allerletzen Euro spart...aber das ist ja bekannt lich ein anders Thema....Denn es gibt ja nun wahrlich bessere Alternativen bei denen es gar nicht erst zu solchen Problemen kommen muss, wenn sogar ein dümmlicher Speedport das korrekt behandeln kann !!
Bugs muss man also hier einkalkulieren. Vermutlich macht der TP Link wirklich kein ESP Passthroug (...oder welches VPN Protokoll der Client auch immer benutzt was du uns ja leider auch nicht mitteilst
)
Testweise solltest du also besser statisch UDP 500, UDP 4500 und das ESP Protokoll (Achtung: nur wenn IPsec verwendet wird !) auf die lokale IP Adresse des Cliets in den Router eintragen. Ggf. löst das schon das Problem.
Bei PPTP bentzt du dann statt der o.a. ports eben TCP 1723 und das GRE Protokoll...wie immer.
Ein MTU Problem ist es sicher nicht, jedenfalls nicht beimTunnelverbindungsaufbau, da dort keine Pakete größer 256 Byte verwendet werden. Der Tunnel solllte also immer zustande kommen !
Bugs muss man also hier einkalkulieren. Vermutlich macht der TP Link wirklich kein ESP Passthroug (...oder welches VPN Protokoll der Client auch immer benutzt was du uns ja leider auch nicht mitteilst
)Testweise solltest du also besser statisch UDP 500, UDP 4500 und das ESP Protokoll (Achtung: nur wenn IPsec verwendet wird !) auf die lokale IP Adresse des Cliets in den Router eintragen. Ggf. löst das schon das Problem.
Bei PPTP bentzt du dann statt der o.a. ports eben TCP 1723 und das GRE Protokoll...wie immer.
Ein MTU Problem ist es sicher nicht, jedenfalls nicht beimTunnelverbindungsaufbau, da dort keine Pakete größer 256 Byte verwendet werden. Der Tunnel solllte also immer zustande kommen !
Hallo aqui,
Danke für deine Antwort.
Die Außendienstmitarbeiter sind für Ihre "Büroinfrastruktur" weitgehend selbst zuständig. Die bekommen einen funktionierenden Anschluß (T-Home mit Speedport) und ein Notebook gestellt, Alles andere ist meist Eigeninitiative der Außendienstmitarbeiter.
Der TP-Link ist anscheinend von einem anderen Internetanschluß "übriggeblieben" und der Mitarbeiter wollte damit "drahtlos" ins Internet, was zwar klappt, aber er kann damit nicht mehr VPN-Nutzen. Im Moment habe ich ihn dazu verdonnert wieder den Speedport zu nutzen.
Ich persönlich bevorzuge Linksys/Cisco und wenns "billig" sein muß AVM.
Aber als neugiereiger Mensch würde es mich schon interessieren, warum der TP-Link nicht will, obwohl der Speedport das kann. das VPN ist leider die Baustelle eines anderen Dienstleisters, daher komme ich im Moment nicht an Details heran. Das einzige was ich auf die Schnelle herausfinden konnte, war, daß der Client UDP-Encapsulation benutzt. "IKE over TCP" wird anscheinend unterstützt, aber nicht bentutzt.
Nunja, ich werde beim nächsten Kontakt mit dem Kunden mal die passenden Ports/Protokolle "aufmachen" um zu schauen, ob das dem Problem abhilft.
Danke für deine Antwort.
Die Außendienstmitarbeiter sind für Ihre "Büroinfrastruktur" weitgehend selbst zuständig. Die bekommen einen funktionierenden Anschluß (T-Home mit Speedport) und ein Notebook gestellt, Alles andere ist meist Eigeninitiative der Außendienstmitarbeiter.
Der TP-Link ist anscheinend von einem anderen Internetanschluß "übriggeblieben" und der Mitarbeiter wollte damit "drahtlos" ins Internet, was zwar klappt, aber er kann damit nicht mehr VPN-Nutzen. Im Moment habe ich ihn dazu verdonnert wieder den Speedport zu nutzen.
Ich persönlich bevorzuge Linksys/Cisco und wenns "billig" sein muß AVM.
Aber als neugiereiger Mensch würde es mich schon interessieren, warum der TP-Link nicht will, obwohl der Speedport das kann. das VPN ist leider die Baustelle eines anderen Dienstleisters, daher komme ich im Moment nicht an Details heran. Das einzige was ich auf die Schnelle herausfinden konnte, war, daß der Client UDP-Encapsulation benutzt. "IKE over TCP" wird anscheinend unterstützt, aber nicht bentutzt.
Nunja, ich werde beim nächsten Kontakt mit dem Kunden mal die passenden Ports/Protokolle "aufmachen" um zu schauen, ob das dem Problem abhilft.
Warum macht ihr es nicht ganz einfach und benutzt den TP-Link nur als WLAN AP?
Problem gelöst.
Problem gelöst.
Zitat von @dog:
Warum macht ihr es nicht ganz einfach und benutzt den TP-Link nur als WLAN AP?
Problem gelöst.
Warum macht ihr es nicht ganz einfach und benutzt den TP-Link nur als WLAN AP?
Problem gelöst.
Das wäre zu einfach
Im Ernst, das war mein allererster Vorschlag, und als Alternative einen WLAN-Router zu nehmen, mit dem das funktioniert, z.B. einen Speedport mit WLAN oder eine Fritzbox. Irgendwie wollte der Außendienstmitarbeiter das nicht. Nunja, im Moment ist er dazu verdonnert halt den Speedport ohne WLAN zu nutzen. -> Problem gelöst.
Worum es mir aber ging, wie ich oben schon sagte: Ich bin ein neugiereiger Mensch und wüßte halt gerne, warum der TP-Link Probleme macht, damit ich dann handfeste Argumente habe, den Kunden in Zukunft die TP-Links auszureden. Ein einfaches "geht nicht!" genügt manchmal leider nicht, weil derjenige irgendwo bei irgendeinem gesehen hat, daß es doch ging (auch wenn es ein Riesenaufwand war, was der Kunde aber meist nicht weiß.).
Hi !
Also ich habe mittlerweile (preislich gezwungenermassen) einige Erfahrung mit den Teilen. Bei den Dingern gibt es mindestens zwei Fallen:
1.
Firmware aktuell?
2.
Auch das popligste Ding (unter 10 Euro) von denen hat oftmals einen (ausgehenden) Minipaketfilter. Wenn der aktiv gesetzt ist und der User da auch noch selbst herumgefummelt hat, dann musst Du dich nicht wundern. Oftmals (also je nach Modell) gibt es einen einzigen Schalter (nennt sich meist klangvoll "Firewall" oder oftmals auch "Parental-Control"), der ist meist unter der Rubrik "Security" im WebGui zu finden, dort darf kein Haken drin sein. Und natürlich hat der Schalter nix mit NAT zu tun, das wird dadurch nicht beeinflusst...
mrtux
Also ich habe mittlerweile (preislich gezwungenermassen) einige Erfahrung mit den Teilen. Bei den Dingern gibt es mindestens zwei Fallen:
1.
Firmware aktuell?
2.
Auch das popligste Ding (unter 10 Euro) von denen hat oftmals einen (ausgehenden) Minipaketfilter. Wenn der aktiv gesetzt ist und der User da auch noch selbst herumgefummelt hat, dann musst Du dich nicht wundern. Oftmals (also je nach Modell) gibt es einen einzigen Schalter (nennt sich meist klangvoll "Firewall" oder oftmals auch "Parental-Control"), der ist meist unter der Rubrik "Security" im WebGui zu finden, dort darf kein Haken drin sein. Und natürlich hat der Schalter nix mit NAT zu tun, das wird dadurch nicht beeinflusst...
mrtux
"als neugiereiger Mensch würde es mich schon interessieren, warum der TP-Link nicht will, obwohl der Speedport das kann. .."
Dann befriedige doch ganz einfach mal deine Neugier und sniffer den VPN Traffic am Client mal mit, dann weisst du doch ob die VPN Pakete ankommen oder nicht und ob der TP Link saber forwardet oder nicht !! Mit oder ohne Port Forwarding.
Übrigens: Ganz ohne gehts nicht. Der benutzer muss zwingend die Ports UDP 500 und UDP 4500 eintragen. ESP (Protokoll 50) sollte dann per VPN Passthrough geforwardet werden.
Das hast du ja vermutlich noch nichtmal konfiguriert auf dem TP-Link und auch kein Feedback diesbezüglich gegeben..? Was sollen wir dir also noch antworten hier ??
Wenn nicht ist der TP Link der böse Buhmann weil er kein ESP forwardet...eine typische Krankheit bei Billigsthardware !
Hast du denn wenigstens das statische Port Forwarding schon mal ausprobiert ??
Dann befriedige doch ganz einfach mal deine Neugier und sniffer den VPN Traffic am Client mal mit, dann weisst du doch ob die VPN Pakete ankommen oder nicht und ob der TP Link saber forwardet oder nicht !! Mit oder ohne Port Forwarding.
Übrigens: Ganz ohne gehts nicht. Der benutzer muss zwingend die Ports UDP 500 und UDP 4500 eintragen. ESP (Protokoll 50) sollte dann per VPN Passthrough geforwardet werden.
Das hast du ja vermutlich noch nichtmal konfiguriert auf dem TP-Link und auch kein Feedback diesbezüglich gegeben..? Was sollen wir dir also noch antworten hier ??
Wenn nicht ist der TP Link der böse Buhmann weil er kein ESP forwardet...eine typische Krankheit bei Billigsthardware !
Hast du denn wenigstens das statische Port Forwarding schon mal ausprobiert ??
Da die Kiste nicht direkt in meinem Zugriff ist (ca 400 km entfernt) bin ich darauf angewiesen wann der Außendienstler wieder Zeit hat. Der soll ja nicht nur sich mit dem Router beschäftigen sondern Aufträge generieren, damit der Kunde dann genug Geld hat, um mich dann damit zu bezahlen.
Ich werde also warten müssen, bis ich wieder Gelegenheit habe, auf seiner Kiste per Remote-Zugriff rumwerkeln zu dürfen.
Ich werde also warten müssen, bis ich wieder Gelegenheit habe, auf seiner Kiste per Remote-Zugriff rumwerkeln zu dürfen.
Hi !
Ähmm reden wir hier von einer eingehenden oder ausgehenden VPN Verbindung? So wie ich das verstanden habe, will der Kunde durch den TP-Link auf das Firmennetz oder?
Gerade habe ich (nur testweise) einen 10 Euro TP-Link vor einem WRT-54gl und durch beide geht IPsec VPN problemlos auf einen Bintec R1200 ....
Das sieht so aus:
WinXP Pro (Shewsoft) -> WRT54gl (Tomato) -> TP-Link (R480) -> Teledat300 -> Telekom DSL 768 -> Business DSL16000 -> Speedport 701 (nur Modem) -> Bintec R1200 (eigeb. IPsec VPN Daemon)....funtzt absolut stabil und problemlos....Umgekehrt würde ich das nicht aufbauen (wollen).... :-P
mrtux
Zitat von @aqui:
Übrigens: Ganz ohne gehts nicht. Der benutzer muss zwingend die Ports UDP 500 und UDP 4500 eintragen. ESP (Protokoll 50)
Übrigens: Ganz ohne gehts nicht. Der benutzer muss zwingend die Ports UDP 500 und UDP 4500 eintragen. ESP (Protokoll 50)
Ähmm reden wir hier von einer eingehenden oder ausgehenden VPN Verbindung? So wie ich das verstanden habe, will der Kunde durch den TP-Link auf das Firmennetz oder?
Gerade habe ich (nur testweise) einen 10 Euro TP-Link vor einem WRT-54gl und durch beide geht IPsec VPN problemlos auf einen Bintec R1200 ....
Das sieht so aus:
WinXP Pro (Shewsoft) -> WRT54gl (Tomato) -> TP-Link (R480) -> Teledat300 -> Telekom DSL 768 -> Business DSL16000 -> Speedport 701 (nur Modem) -> Bintec R1200 (eigeb. IPsec VPN Daemon)....funtzt absolut stabil und problemlos....Umgekehrt würde ich das nicht aufbauen (wollen).... :-P
mrtux
Zitat von @mrtux:
Hi !
> Zitat von @aqui:
> ----
> Übrigens: Ganz ohne gehts nicht. Der benutzer muss zwingend die Ports UDP 500 und UDP 4500 eintragen. ESP (Protokoll
50)
Ähmm reden wir hier von einer eingehenden oder ausgehenden VPN Verbindung? So wie ich das verstanden habe, will der Kunde
durch seinen TP-Link auf das Firmennetz oder?
Hi !
> Zitat von @aqui:
> ----
> Übrigens: Ganz ohne gehts nicht. Der benutzer muss zwingend die Ports UDP 500 und UDP 4500 eintragen. ESP (Protokoll
50)
Ähmm reden wir hier von einer eingehenden oder ausgehenden VPN Verbindung? So wie ich das verstanden habe, will der Kunde
durch seinen TP-Link auf das Firmennetz oder?
Ausgehend:
In der Zentrale sitzt eine CP-FW1-NG hinter einem Cisco-Router.
Die Clients haben (je nach Alter des Systems) den SecuRemote/Scureclient von Checkpoint und bauen damit eine VPN-Verbindung über ihren jeweils gerade verfügbaren Internetanschluß, meist Ttelekom-DSL zur Zentrale auf. Die meisten "kostenlos" vom provider mitgelieferten Router funktionierten enwandfrei, solage der Provider bei der Voreinstellung nicht zufällig das gleiche RFC-1918-Netz getroffen hat wie in der Zentrale.
Es muß über den TP-Link nur eine Verbindug "raus" aufgebaut werden, Ich hatte schon früher mal mit einem TP-Link zu tun (weiß nicht mehr welches Modell) und da lief es auf Anhieb. Bis zu diesem Fall ist mir auch kein "Billigrouter" begegnet, der nicht spätestens nach einen FW-Update IPSec durchgelassen hat (NAT-Traversal mit UDP) und ein Portforwarding brauchte.
PS: Der Außendienstmitarbeiter ist momentan viel unterwegs, da habe ich in den nächsten Tagen verutlich keine Gelegenheit, danach zu schauen.
Ich habe gerade nachricht bekommen, daß das Problem gelöst und kein weiterre Handlungsbedarf mehr vorhanden wäre.
Ich versuche noch herauszufinden wie der AD-Mitarbeiter das Problem "gelöst" hat. und poste es hier.
Ich versuche noch herauszufinden wie der AD-Mitarbeiter das Problem "gelöst" hat. und poste es hier.
Update:
Die Lösung des AD-Mitarbeiters bestand darin, wie ich ihm als (erste) alternative schon vorgeschlagen hatte. den TP-Link als reinen AP zu betreiben.
Da er glücklich und zufrieden ist, werde ich leider nie erfahren, warum der TP-Link im Gegensatz zu anderen Modellen aus seiner Familie, mit dem Checkpoint Secureclient nicht zusammenarbeiten wollte.
Hallo,
ich habe das selbe Problem mit TP-Link.
Unzwar kann ich mich im Firmenintranet über WLAN ohne Probleme über Global Remote einwählen. Wenn ich mich von zuhause einwählen will über Global Remote geht es nicht. Er verbindet zwar mit einem Server aber wenn das Zertifikat übrprüft wird, bleibt er stehen (stundenlang ohne Fehlermeldung).
Beim Router habe ich Port 4500 und 500 unter Port Triggering freigeschaltet (beide UDP). Habe ebenfalls zwei Virtuelle Server mit den beiden Protseingerichtet. Firewall auch schonm komplett deaktiviert und es bringt nichts.
Ich lese die ganze Zeit bei TP-Link , dass man angeblich das ESP Protokoll einstellen kann aber ich finde es nicht. Ich kann ledlich zwischen UDP und TCP entscheiden. Ich habe zwei TP-Link Router. Der Hauptrouter ist ein TL-R860 und dann habe ich einen WLAN-Router als Subnetz eingerichtet (TL-WR642G). Beide sollten eigentlich VPN Pass-Through PPTP, L2TP, IPSec (ESP) unterstützen.
Weiß jemand an was das liegen kann? Ich komme nicht mal mit dem Hauptrouter über Kabel raus auch wenn ich Pass through aktiviert habe.
Vielen Dank im Voraus
mfg Corner
ich habe das selbe Problem mit TP-Link.
Unzwar kann ich mich im Firmenintranet über WLAN ohne Probleme über Global Remote einwählen. Wenn ich mich von zuhause einwählen will über Global Remote geht es nicht. Er verbindet zwar mit einem Server aber wenn das Zertifikat übrprüft wird, bleibt er stehen (stundenlang ohne Fehlermeldung).
Beim Router habe ich Port 4500 und 500 unter Port Triggering freigeschaltet (beide UDP). Habe ebenfalls zwei Virtuelle Server mit den beiden Protseingerichtet. Firewall auch schonm komplett deaktiviert und es bringt nichts.
Ich lese die ganze Zeit bei TP-Link , dass man angeblich das ESP Protokoll einstellen kann aber ich finde es nicht. Ich kann ledlich zwischen UDP und TCP entscheiden. Ich habe zwei TP-Link Router. Der Hauptrouter ist ein TL-R860 und dann habe ich einen WLAN-Router als Subnetz eingerichtet (TL-WR642G). Beide sollten eigentlich VPN Pass-Through PPTP, L2TP, IPSec (ESP) unterstützen.
Weiß jemand an was das liegen kann? Ich komme nicht mal mit dem Hauptrouter über Kabel raus auch wenn ich Pass through aktiviert habe.
Vielen Dank im Voraus
mfg Corner
