VPN Connection Fehler Phase 1 inkl. Error Message

[Matz83]

Hallo liebe Mitinformatiker,

ich hoffe ich bin hier richtig und irgendwer kann mir auf die Sprünge helfen.

Ich habe ein VPN mittels Cisco RV120W VPN Router einrichten sollen.

Konfiguration etc bei mir zu Hause mit einer gleichartigen Umgebung wie im life Arbeitseinsatz getestet und alles hat funktioniert. (als client benutze ich den ShrewSoft VPn Client eingestellt nach einem Cisco Guide den ich im SuppForum gefunden hatte).

Nun wurde der Router von nem Kollegen zu seinem Einsatzort mitgenommen und die Einstellungen angepasst. (sieht ok aus, er hat mir screenshots mitgebracht.)

InternetRouter erreichbar über eine Domain -> unser VPN-Router -> das Netz in das wir rein sollen.

Portforwarding 60443 (Remoteport für den Router), UDP 500 und UDP 4500 werden ebenfalls auf die WAN-seitige IP des VPN routers geleitet. ESP ist laut Aussage der dortigen IT ebenfalls aktiviert.

Nun zum Problem:

Das Connecten schlägt fehl.

bringing up tunnel ...

negotiation timout occurred

tunnel disabled

In unseren VPN-Router logs bekomme ich nun folgende Fehlermeldung (die des vorgeschalteten InternetRouters kann ich leider nicht einsehen, weil Fremd-IT)

2012-01-31 14:31:51: [router266A66] [iKE] INFO: Received Vendor ID: CISCO-UNITY

2012-01-31 14:31:51: [router266A66] [iKE] INFO: For xxx[500], Selected NAT-T version: RFC 39472012-01-31 14:31:56: [router266A66] [iKE] NOTIFY: The packet is retransmitted by xxx[500].

2012-01-31 14:32:01: [router266A66] [iKE] NOTIFY: The packet is retransmitted by xxx[500].

2012-01-31 14:32:06: [router266A66] [iKE] NOTIFY: The packet is retransmitted by xxx[500].

2012-01-31 14:32:12: [router266A66] [iKE] ERROR: Phase 1 negotiation failed due to time up for xxx[500]. c2aa8dc8be5bb5d8:2d87d2291bb8eaf7

Wie gesagt in ner Testumgebung lief alles einwandfrei... Leider verstehe ich nicht wirklich was diese Fehlermeldung bedeutet und daher meine Frage an Euch. Kann mir da jemand vieleicht weiter helfen? (ist ESP vieleicht nicht im InternetRouter "freigeschalten"? oder an was zum Geier liegt es )

Ich bin aktuell mit meinem Latein am Ende und würde mich über einen Anstoss oder Hinweis wirklich sehr sehr freuen.

Liebe Grüße

Matze

Bearbeitet 31. Januar 2012 von Matz83

[Crash2001]

ESP-Traffic muss auf dem vorderen Router natürlich weitergeleitet werden an den Cisco-Router. Wenn das nciht der Fall ist, kriegt man den Tunnel nicht aufgebaut.

Da wirst du wohl mal mit dem für den anderen Router zuständigen Techniker reden müssen, oder alternativ die Einwahl direkt darauf implementieren.

[Matz83]

Hey,

danke für deine schnelle Antwort.

Hab nochmal ne Frage dazu, erkennt man an der Fehlermeldung das ESP nicht eingeschalten ist? Die dortige IT hat uns gerade noch mitgeteilt, das ESP (selbstverständlich für uns freigegeben wurde...).

Vielen Dank für deine Hilfe

[Crash2001]

Da muss ich leider passen.

In meinen Augen deutet es darauf hin, dass die Aushandlung nicht richtig stattfindet, da keine Antwort kommt. Kann natürlich auch einen anderen Grund haben, wie z.B. blockierter Port oder Weiterleitung an einen anderen PC oder so was in der Art.

2012-01-31 14:32:12: [router266A66] [iKE] ERROR: Phase 1 negotiation failed due to time up for xxx[500]. c2aa8dc8be5bb5d8:2d87d2291bb8eaf7

deutet darauf hin, dass die Aushandlung schon fehl schlägt mit einem timeout, was dann dafür sprechen würde, dass die IT die Wahrheit sagen könnte. Wenn gar nicht erst ausgehandelt wird, was genommen werden soll, dann "fliesst" auch noch kein ESP-Traffic.

Wird denn überhaupt ESP verwendet, oder doch AH?

Hier kannst du sehen, wie das ganze abläuft.

Hier noch paar Seiten, die dir weiterhelfen könnten:

klick1

klick2

[Matz83]

Vielen Dank für deine Hilfe

Ich gehe davon aus das ESP benutzt wird, auch wenn ich jetzt "keine Einstellung dazu finde",

aber korrigier mich bitte wenn ich falsch liege, AH würde ja nur funktionieren, wenn NAT-T nicht benutzt wird. Da ich die selbe Verbindung aber testweise in einer nachgebauten Umgebung ohne Probleme zum Laufen gebracht habe, gehe ich mal davon aus das ESP erfolgreich verwandt wurde.

Das Phase 1 Problem deutet ja generell darauf hin, dass schon beim aushandeln auf port 500 keine Antwort zurück kommt...... was dann ja eigentlich (bei nicht geänderten Einstellungen im VPN Router) darauf schliessen lässt, das irgendwas mit den Portweiterleitungen nicht hinhaut ESP etc dürfte ja erst in den späteren Phasen von Bedeutung werden oder?

Was mich halt echt in den Wahnsinn treibt, ist dass der ganze kram ohne probs bei mir funktioniert hat.....

so long und big thx

matze

[Crash2001]

Es sollten die Ports UDP500, UDP4500 und TCP10.000 weitergeleitet werden.

Frag doch mal nach, was auf dem ersten Router alles weitergeleitet ist, bzw. ob diese Ports für dich weitergeleitet werden können.

IKE nutzt Port 500 UDP.

Wenn NAT Traversal genutzt wird, wird Port 4500 UDP benötigt.

IPSEC-over-TCP benötigt nur Port 10000 TCP.

Was genau du also an geöffneten Ports benötigst, musst du schon selber raussuchen, anhand der möglichen Aushandlungen.

[Matz83]

Hey,

joa vieleicht hab ich das nicht so ganz klar rausgestellt

laut it wird esp durchgelassen

port 60443 für den remote zugriff auf vpn geleitet

udp 500 auf vpn router geleitet für IKE

udp 4500 auf vpn geleitet fürs NAT-T

genau die selben Einstellungen wie in meiner Testumgebung -.- nur das ich

keine antwort auf meine phase 1 requests bekomme.

Naja ich werd mal den IT-Menschen vor Ort bitten mir die Logs für nen Verbindungsversuch unsererseits zur Verfügung zu stellen.

Vielen Dank bis hier her

Gruß matze

[Crash2001]

Sitzt der andere Router evtl auch noch hinter irgendetwas, wo noch Freigaben / Portweiterleitungen eingerichtet werden müssen? Du hast leider bisher nur die eine Seite beschrieben afaik. Wie die ganze Situation auf der anderen Seite aussieht, ist dann die andere Frage.

[Matz83]

Hey ,

na ja wenn ich das richtig im Kopf habe, sollte bei einem Client - to - Gateway VPN die Clientseite relativ egal sein?

Zumal das Verbinden auf die Testumgebung von diversen Orten und verschiedenen Netzen funktioniert hat. Korrigier mich bitte wenn ich da falsch liege.

Im Ziel-Netz selber steht nur der

1. )Firewall/Nat-Router->

->2.)

irgend nen switch für nen anderes Netz an Lan Port 1

->2.)

unser VPN Router an Lan Port 2

->3.

das Netz ich das ich will.

Jetzt kann ich versuchen mich zu verbinden von wo und welchem Netz auch immer und der Phase 1 Error tritt auf.

Da sollte ich doch eigentlich keinen Denkfehler haben, wenn ich davon ausgehe das die obingen Port Weiterleitungen reichen sollten...?

WIe gesagt ich hoffe das die dortige IT mir die Verbindungsversuchs-Logs zu kommen lässt und ich so (auch mit deiner Hilfe ) den Fehler weiter eingrenzen kann...

VIelen vielen Dank auf jedenfall für deine bisherige Hilfe und Denkanstöße auch wenns vieleicht so klingt bin ich eigentlich kein Dummie

Gruß

Matze

Bearbeitet 2. Februar 2012 von Matz83

[Crash2001]

[...]

na ja wenn ich das richtig im Kopf habe, sollte bei einem Client - to - Gateway VPN die Clientseite relativ egal sein? [...]

Solange ausgehende Pakete nicht gefiltert werden, ist das richtig. Vor allem bei Firmen kann man sich die Aussage jedoch nicht so einfach machen. Es gibt genug Firewalls, in denen ein entsprechender Filter konfiguriert ist, damit keine VPN Verbindungen über die Standardports aufgebaut werden können problemlos, da VPN-Verbindungen auch zur Kopplung von zwei Netzwerken verwendet werden können und somit ein Sicherheitsrisiko bestehen könnte. ZUdem könnten so sensible Daten aus der Firma raus gebracht werden...

Es ist nicht immer alles so einfach, wie zu Hause.

[Matz83]

Nu werd ick aber langsam unsicher .

Also prinzipiel ist mir das alles bewusst.

Leider warte ich immernoch auf die Logs -.- ....

Ich kann doch aber davon ausgehen, dass wenn ich aus dem Netzwerk der Arbeitsstelle in der Lage war in das TestVPN zu connecten (und auch von diversen anderen Standorten, die natürlich keine Firewalleinstellungen für den ausgehenden Verkehr haben^^, hier auf Arbeit schon) Clientseitig keine Probleme mit der "Blockierung" auftreten können bzw sind. Es wurde in der Zeit bei uns ja nix geändert. Wenn ich nun nicht auf die Gegenstelle connecten kann, muss das doch an Einstellungen bei der Gegenseite liegen? Richtig?

Wenn es von Netzwerk B in Netz A funktionierte und nun von Netzwerk B in Netzwerk C nicht, sollte der Fehler doch eigentlich nicht im Netzwerk B liegen können. Oder steh ich schon wieder aufm Schlauch?

Das diverse Einstellungen und Sicherheitsvorkehrungen vorgenommen werden können und teilweise sollten ist gar keine Frage. Scheint ja aber nicht so zu sein.

Das nicht alles so easy ist wie in der Testumgebung ist schon klar

Danke und nen schönes We wünsche ich.

Gruß

Matze

[Crash2001]

Achso, der Test war vom gleichen Standort und es wurde auch versucht, sich wo anders einzuwählen. Ich war jetzt davon ausgegangen, dass es umgekehrt war. Leider sind deine Aussagen oft recht schwammig, weshalb immer Nachfragen kommen.

Wenn es von Standort B nach A ging, sollte es nach C auch gehen, wenn die gleichen Einstellungen verwendet werden.

Wünsche auch ein schönes WE.

[Matz83]

Hey,

ich danke für deine Geduld , da muss ich aber mal an meiner Fähigkeit für klare Antworten arbeiten.

Jo der Test war Clientseitig von unserer Arbeitsstelle (

VPN Router hinter NAT/Firewall bei mir zu Hause (A).

B -> A ging

Neuer Standort mit "selber" Infrasturktur des VPN Routers ©

B -> C geht nicht

ergo gehe ich wie du ja nun auch sagst, davon aus das die NAT/Firewall bei © zu viel filtert, da alle Einstellungen "seitens" der IT vorgenommen worden seien sollen, wie sie auch in der Testumgebung (A) waren.

Ich warte nach wie vor auf die Log- Files vom NAT/Firewall ©, um zu sehen was mit meinem Request passiert...

nochmal tausend dank