3
VPN Verbindung Phase 1
Verfendete HW / SW: ZyWALL 5, ZyXEL P660HW, Greenbow VPN Client
Hallo zusammen
Ich hoffe mir kann jemand bei diesem relativ komplizierten Problem helfen:
Es wird versucht, eine VPN-Verbindung zwischen meiner Arbeitsstation im Geschäft und einem Netzwerk im Feld herzustellen. Genauer gesagt verwende ich den Greenbow-VPN-Client und versuche mit diesem das Subnet der ausenstelle zu verbinden.
Der Fehler: Peer unreachable beim Greenbow VPN-Client.
Nun könnte man sagen, ja kein Problem, ich habe einen Schreibfehler im Client bei der Eingabe der fixen IP der Aussenstelle geamcht. Leider eben nicht!
Wies aussieht:
Internet der Ausenstelle funktioniert, kann ebenfalls auch auf den Webserver hinter der ZyWALL 5 zugreifen.
Ausenstelle hat eine Fixe IP-Adresse
Einstellungen:
ZyXEL P660HW ist auf Bridge gestellt, DHCP off, Firewall off
ZyWALL 5 hat alle Interneteinstellungen. Die Firewall ist für VPN entsprechend konfiguriert.
Lösungsversuche:
1. Alle Einstellungen überprüft. Gleiches Problem
2. Alle Geräte druch Updates, Austauschen etc. überprüft. Gleiches Problem
3. Verbindung von meinem Client zu anderen VPN's hergestellt: Funktioniert
4. Das ganze über einen DynDNS Account versucht: Gleiches Problem
5. Mit Studerus (ZyXEL Importeur CH) telefoniert und sämtliche Einstellungen überprüft: Gleiches Problem
6. Mit dem ISP kommuniziert und auf Fehler / eventuelle aktive FW etc. überprüft.
Was ausgeschlossen werden kann:
1. Fehler bei Client, weil dieser auf andere VPN's funktioniet
2. Konfigurationsfehler auf ZyWALL und Router, da die Einstellungen doppelt und dreifach überprüft und abgesprochen wurden
3. Gerätefehler
4. ISP-Fehler*
Sonstiges
- Die ZyWALL logt nichts, wenn ich einen Verbindungsversuch unternehme. Das sagt mir, dass das Signal nicht einmal so weit kommt
Also, man sieht, ich habe schon einiges versucht und ausgeschlossen. Komme nun einfach nicht mehr weiter.
Noch ein letztes:
Interessant ist, dass wenn ich den Befehl TRACERT von der CMD aus starte habe ich bei zwei weitgehend identischen Aussenstellen verschiedene Rückmeldungen:
Bei der funktioniertenden Aussenstelle mit Fixer IP läuft alles sauber durch.
Bei der nichtfunktionierenden Aussenstelle leider nicht.
Laut ISP (haben denselben Provider) dürfte es bei der funktionierenden Aussenstelle nicht durchlaufen. Also sie sehen das als einen unbedeutenden Fehler das es bei der einten Aussenstelle durchläuft und bei der anderen nicht. Also laut ISP müsste es so oder so funktionieren.
So, dass ist alles was ich weiss. Hoffe auf einige Ideen!
Vielen Dank und Grüsse
Relesys
Hallo zusammen
Ich hoffe mir kann jemand bei diesem relativ komplizierten Problem helfen:
Es wird versucht, eine VPN-Verbindung zwischen meiner Arbeitsstation im Geschäft und einem Netzwerk im Feld herzustellen. Genauer gesagt verwende ich den Greenbow-VPN-Client und versuche mit diesem das Subnet der ausenstelle zu verbinden.
Der Fehler: Peer unreachable beim Greenbow VPN-Client.
Nun könnte man sagen, ja kein Problem, ich habe einen Schreibfehler im Client bei der Eingabe der fixen IP der Aussenstelle geamcht. Leider eben nicht!
Wies aussieht:
Internet der Ausenstelle funktioniert, kann ebenfalls auch auf den Webserver hinter der ZyWALL 5 zugreifen.
Ausenstelle hat eine Fixe IP-Adresse
Einstellungen:
ZyXEL P660HW ist auf Bridge gestellt, DHCP off, Firewall off
ZyWALL 5 hat alle Interneteinstellungen. Die Firewall ist für VPN entsprechend konfiguriert.
Lösungsversuche:
1. Alle Einstellungen überprüft. Gleiches Problem
2. Alle Geräte druch Updates, Austauschen etc. überprüft. Gleiches Problem
3. Verbindung von meinem Client zu anderen VPN's hergestellt: Funktioniert
4. Das ganze über einen DynDNS Account versucht: Gleiches Problem
5. Mit Studerus (ZyXEL Importeur CH) telefoniert und sämtliche Einstellungen überprüft: Gleiches Problem
6. Mit dem ISP kommuniziert und auf Fehler / eventuelle aktive FW etc. überprüft.
Was ausgeschlossen werden kann:
1. Fehler bei Client, weil dieser auf andere VPN's funktioniet
2. Konfigurationsfehler auf ZyWALL und Router, da die Einstellungen doppelt und dreifach überprüft und abgesprochen wurden
3. Gerätefehler
4. ISP-Fehler*
- Nach Aussage ISP
Sonstiges
- Die ZyWALL logt nichts, wenn ich einen Verbindungsversuch unternehme. Das sagt mir, dass das Signal nicht einmal so weit kommt
Also, man sieht, ich habe schon einiges versucht und ausgeschlossen. Komme nun einfach nicht mehr weiter.
Noch ein letztes:
Interessant ist, dass wenn ich den Befehl TRACERT von der CMD aus starte habe ich bei zwei weitgehend identischen Aussenstellen verschiedene Rückmeldungen:
Bei der funktioniertenden Aussenstelle mit Fixer IP läuft alles sauber durch.
Bei der nichtfunktionierenden Aussenstelle leider nicht.
Laut ISP (haben denselben Provider) dürfte es bei der funktionierenden Aussenstelle nicht durchlaufen. Also sie sehen das als einen unbedeutenden Fehler das es bei der einten Aussenstelle durchläuft und bei der anderen nicht. Also laut ISP müsste es so oder so funktionieren.
So, dass ist alles was ich weiss. Hoffe auf einige Ideen!
Vielen Dank und Grüsse
Relesys
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 80713
Url: https://administrator.de/contentid/80713
Ausgedruckt am: 13.11.2024 um 07:11 Uhr
3 Kommentare
Neuester Kommentar
Salut
Du hast ja ein Benutzerlogin inkl. Passwort für die Firewall erhalten.
Es soll sich doch jemand bei DEINEM Gerät mit einem anderen VPN-Benutzerlogin anmelden und prüfen, ob der Fehler beim Benutzerlogin der Firewall liegt oder an Deinen Einstellungen. Wenn es mit seinem Benutzer auch nicht geht, dann MUSS es an Deiner lokalen Konfiguration liegen (VPN, OS, Firewall), wenn es jedoch mit seinem geht, dann muss Dein Benutzerprofil der Firewall neu analysiert werden.
Wir haben eine Sonicwall, bei der immer wieder vergessen wird, die eröffneten Benutzer für die VPN-Verbindung manuell zu aktivieren. Tut man das nicht, funktioniert die Phase 1 nicht.
Weiss jedoch nicht, ob Du es bereits mit einem funktionierenden, anderen Login getestet hast.
Du hast geschrieben Du hättest es mit anderen VPN-Verbindungen versucht, jedoch nicht, ob ein anderer bei Deinem PC mit seinem Login dasselbe versucht hat.
Du hast ja ein Benutzerlogin inkl. Passwort für die Firewall erhalten.
Es soll sich doch jemand bei DEINEM Gerät mit einem anderen VPN-Benutzerlogin anmelden und prüfen, ob der Fehler beim Benutzerlogin der Firewall liegt oder an Deinen Einstellungen. Wenn es mit seinem Benutzer auch nicht geht, dann MUSS es an Deiner lokalen Konfiguration liegen (VPN, OS, Firewall), wenn es jedoch mit seinem geht, dann muss Dein Benutzerprofil der Firewall neu analysiert werden.
Wir haben eine Sonicwall, bei der immer wieder vergessen wird, die eröffneten Benutzer für die VPN-Verbindung manuell zu aktivieren. Tut man das nicht, funktioniert die Phase 1 nicht.
Weiss jedoch nicht, ob Du es bereits mit einem funktionierenden, anderen Login getestet hast.
Du hast geschrieben Du hättest es mit anderen VPN-Verbindungen versucht, jedoch nicht, ob ein anderer bei Deinem PC mit seinem Login dasselbe versucht hat.
Verdächtig ist das die Firewall rein gar nichts mitloggt. Das ist sehr ungewöhnlich und legt die Vermutung nahe das die VPN Packete gar nicht erst bei ihr ankommen, denn es müsste in jedem Falle ein incoming xyz VON Session im Log stehen.
Leider verschweigst du uns ja WAS für ein VPN Protokoll du benutzt (IPsec AH, IPsec ESP, PPTP, L2TP, SSL oder was auch immer) so das eine detailierte Hilfe nicht einfach ist.
Traceroute oder Windows Pathping benutzen meist ICMP für die Hop Discovery. Es ist gut möglich das der Carrier diese ICMP Typen per Accessliste filtert. Ein Ping auf die Aussenstelle sollte aber immer und in jedem Falle möglich sein, sofern du einen externen Ping in der Firewall erlaubst. Zum Debugging solltest du das in jedem Falle erstmal machen um die Erreichbarkeit sicherzustellen.
Um ICMP Filterungen zu umgehen solltest du ein Traceroute Tool benutzen was auf Basis von UDP oder TCP arbeitet. Fast alle Unix Derivate arbeiten mit einem UDP traceroute. Eine Linux Live Boot CD ist hier sehr hilfreich. TCP benutzt z.B. tcptraceroute.
Wenn alle Stricke reissen hilft dir nur einen Packetsniffer wie den www.WIRESHARK.org zwischen das Modem und die Firewall zu klemmen und die eingehenden Packete explizit mitzusniffern. Hier kannst du dann ganz genau sehen ob deine gesendeten VPN Packete die Firewall überhaupt erreichen.
Vermutlich (laut Log) ist aber genau das nicht der Fall.... Oder sie kommen an und werden dann in der Firewall selber geblockt.
Ein Sniffer Trace sollte da sehr schnell Klarheit schaffen !
Leider verschweigst du uns ja WAS für ein VPN Protokoll du benutzt (IPsec AH, IPsec ESP, PPTP, L2TP, SSL oder was auch immer) so das eine detailierte Hilfe nicht einfach ist.
Traceroute oder Windows Pathping benutzen meist ICMP für die Hop Discovery. Es ist gut möglich das der Carrier diese ICMP Typen per Accessliste filtert. Ein Ping auf die Aussenstelle sollte aber immer und in jedem Falle möglich sein, sofern du einen externen Ping in der Firewall erlaubst. Zum Debugging solltest du das in jedem Falle erstmal machen um die Erreichbarkeit sicherzustellen.
Um ICMP Filterungen zu umgehen solltest du ein Traceroute Tool benutzen was auf Basis von UDP oder TCP arbeitet. Fast alle Unix Derivate arbeiten mit einem UDP traceroute. Eine Linux Live Boot CD ist hier sehr hilfreich. TCP benutzt z.B. tcptraceroute.
Wenn alle Stricke reissen hilft dir nur einen Packetsniffer wie den www.WIRESHARK.org zwischen das Modem und die Firewall zu klemmen und die eingehenden Packete explizit mitzusniffern. Hier kannst du dann ganz genau sehen ob deine gesendeten VPN Packete die Firewall überhaupt erreichen.
Vermutlich (laut Log) ist aber genau das nicht der Fall.... Oder sie kommen an und werden dann in der Firewall selber geblockt.
Ein Sniffer Trace sollte da sehr schnell Klarheit schaffen !
Hey
Vielen Dank für die Lösungsansätze und Geduld...
Also, die Lösung ist:
Infach unter NAT --> Portforwarding den Defaultserver mit 0.0.0.0 definieren. Sonst funktionierts nicht...
Viele Grüsse
Relesys
Vielen Dank für die Lösungsansätze und Geduld...
Also, die Lösung ist:
Infach unter NAT --> Portforwarding den Defaultserver mit 0.0.0.0 definieren. Sonst funktionierts nicht...
Viele Grüsse
Relesys
