Cisco RV180 über VPN nicht erreichbar
Hallo Profis,
habe ein kleines Problem mit meinem VPN-Router.
Habe hier einen Cisco RV180 VPN Router und habe die VPN-Funktion eingerichtet.
Leider scheint der Router keine Anfragen von außen zu beantworten(?).
Über einen DynDNS-Anbieter habe ich meine öffentliche IP-Adresse gespeichert.
Der Router wurde mit einer voreingestellten IP-Sec-Richtlinie und nach Benutzerhandbuch konfiguriert.
Leider kann ich mittels eines IP-Sec Clients keine Verbindung aufbauen.
Benutze als IPSec-Client VPNSwan.
Dieser gibt mir immer "Gateway ist nicht erreichbar " als Fehlermeldung zurück.
Habe es mit folgenden Gateway-Adressen probiert:
WAN-IP Adresse.
DynDNS Hostname(mit WAN-IP Adresse)
Von zuhause aus im Lan, mit der lokalen IP-Adresse des Routers.
Immer das selbe Ergebnis.
Log Des VPN-Clients(Von außen mit Handy):
Oct 19 16:59:39 00[DMN] Starting IKE charon daemon (strongSwan 5.1.1dr4, Linux 3.0.31-889555, armv7l)
Oct 19 16:59:39 00[KNL] kernel-netlink plugin might require CAP_NET_ADMIN capability
Oct 19 16:59:39 00[LIB] loaded plugins: androidbridge charon android-log openssl fips-prf random nonce pubkey pkcs1 pkcs8 pem xcbc hmac socket-default kernel-netlink eap-identity eap-mschapv2 eap-md5 eap-gtc
Oct 19 16:59:39 00[LIB] unable to load 9 plugin features (9 due to unmet dependencies)
Oct 19 16:59:39 00[JOB] spawning 16 worker threads
Oct 19 16:59:39 15[IKE] initiating IKE_SA android[4] to xxxxxxxxxxx
Oct 19 16:59:39 15[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
Oct 19 16:59:39 15[NET] sending packet: from xxxxxxxxxxx[42500] to xxxxxxxxxxx[500] (756 bytes)
Oct 19 16:59:41 03[IKE] retransmit 1 of request with message ID 0
Oct 19 16:59:41 03[NET] sending packet: from xxxxxxxxxxx[42500] to xxxxxxxxxxx[500] (756 bytes)
Oct 19 16:59:44 01[IKE] retransmit 2 of request with message ID 0
Oct 19 16:59:44 01[NET] sending packet: from xxxxxxxxxxx[42500] to xxxxxxxxxxx[500] (756 bytes)
Oct 19 16:59:48 12[IKE] retransmit 3 of request with message ID 0
Oct 19 16:59:48 12[NET] sending packet: from xxxxxxxxxxx[42500] to xxxxxxxxxxx[500] (756 bytes)
Oct 19 16:59:54 09[IKE] giving up after 3 retransmits
Oct 19 16:59:54 09[IKE] peer not responding, trying again (2/0)
Oct 19 16:59:54 09[IKE] initiating IKE_SA android[4] to xxxxxxxxxxx
Oct 19 16:59:54 09[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
Oct 19 16:59:54 09[NET] sending packet: from xxxxxxxxxxx[42500] to xxxxxxxxxxx[500] (756 bytes)
Oct 19 16:59:54 00[IKE] destroying IKE_SA in state CONNECTING without notification
Ich habe den Verdacht das es an der Firewall des Routers liegt. Hat jemand eine Idee?
habe ein kleines Problem mit meinem VPN-Router.
Habe hier einen Cisco RV180 VPN Router und habe die VPN-Funktion eingerichtet.
Leider scheint der Router keine Anfragen von außen zu beantworten(?).
Über einen DynDNS-Anbieter habe ich meine öffentliche IP-Adresse gespeichert.
Der Router wurde mit einer voreingestellten IP-Sec-Richtlinie und nach Benutzerhandbuch konfiguriert.
Leider kann ich mittels eines IP-Sec Clients keine Verbindung aufbauen.
Benutze als IPSec-Client VPNSwan.
Dieser gibt mir immer "Gateway ist nicht erreichbar " als Fehlermeldung zurück.
Habe es mit folgenden Gateway-Adressen probiert:
WAN-IP Adresse.
DynDNS Hostname(mit WAN-IP Adresse)
Von zuhause aus im Lan, mit der lokalen IP-Adresse des Routers.
Immer das selbe Ergebnis.
Log Des VPN-Clients(Von außen mit Handy):
Oct 19 16:59:39 00[DMN] Starting IKE charon daemon (strongSwan 5.1.1dr4, Linux 3.0.31-889555, armv7l)
Oct 19 16:59:39 00[KNL] kernel-netlink plugin might require CAP_NET_ADMIN capability
Oct 19 16:59:39 00[LIB] loaded plugins: androidbridge charon android-log openssl fips-prf random nonce pubkey pkcs1 pkcs8 pem xcbc hmac socket-default kernel-netlink eap-identity eap-mschapv2 eap-md5 eap-gtc
Oct 19 16:59:39 00[LIB] unable to load 9 plugin features (9 due to unmet dependencies)
Oct 19 16:59:39 00[JOB] spawning 16 worker threads
Oct 19 16:59:39 15[IKE] initiating IKE_SA android[4] to xxxxxxxxxxx
Oct 19 16:59:39 15[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
Oct 19 16:59:39 15[NET] sending packet: from xxxxxxxxxxx[42500] to xxxxxxxxxxx[500] (756 bytes)
Oct 19 16:59:41 03[IKE] retransmit 1 of request with message ID 0
Oct 19 16:59:41 03[NET] sending packet: from xxxxxxxxxxx[42500] to xxxxxxxxxxx[500] (756 bytes)
Oct 19 16:59:44 01[IKE] retransmit 2 of request with message ID 0
Oct 19 16:59:44 01[NET] sending packet: from xxxxxxxxxxx[42500] to xxxxxxxxxxx[500] (756 bytes)
Oct 19 16:59:48 12[IKE] retransmit 3 of request with message ID 0
Oct 19 16:59:48 12[NET] sending packet: from xxxxxxxxxxx[42500] to xxxxxxxxxxx[500] (756 bytes)
Oct 19 16:59:54 09[IKE] giving up after 3 retransmits
Oct 19 16:59:54 09[IKE] peer not responding, trying again (2/0)
Oct 19 16:59:54 09[IKE] initiating IKE_SA android[4] to xxxxxxxxxxx
Oct 19 16:59:54 09[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
Oct 19 16:59:54 09[NET] sending packet: from xxxxxxxxxxx[42500] to xxxxxxxxxxx[500] (756 bytes)
Oct 19 16:59:54 00[IKE] destroying IKE_SA in state CONNECTING without notification
Ich habe den Verdacht das es an der Firewall des Routers liegt. Hat jemand eine Idee?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 219872
Url: https://administrator.de/forum/cisco-rv180-ueber-vpn-nicht-erreichbar-219872.html
Ausgedruckt am: 23.12.2024 um 14:12 Uhr
8 Kommentare
Neuester Kommentar
Ja, laut dem Log Auszug ist das eindeutig ! Der Client hat gar keine IP Connectivity zum Router selber und da schlägt natürlich dann das VPN fehl...klar !
Ein besserer Client als der Cisco Client ist übrigens der freie Shrew Client:
https://www.shrew.net/download
Leider schreibst du recht wenig zu deinem Netzdesign so das du uns nun hier wieder zum Nachfragen und Raten zwingst...
Gemäß Datenblatt:
http://www.cisco.com/en/US/prod/collateral/routers/ps10907/ps9923/ps119 ...
hat der Router kein integriertes DSL oder Kabel Modem deshalb solltest du folgende Fragen wasserdicht beantworten für eine zielführende Hilfe:
Ein Zugriff mit dem VPN Client aus dem lokalen LAN des Routers schlägt generell immer fehl, denn diese Router supporten KEIN Hairpin NAT !!
Was das ist und warum es fehlschlägt kannst du hier nachlesen:
http://wiki.mikrotik.com/wiki/Hairpin_NAT
Einen wasserdichten Test kannst du ganz einfach fahren indem du dem WAN Port im Cisco Router Setup mal eine statische IP gibst.
Dann schliesst du den VPN Client PC mit einem Kabel am Cisco WAN Port an und gibst dem ebenfalls eine statische IP Adresse.
Damit hast du den Client dann direkt am Router und ein VPN Aufbau sollte fehlerlos funktionieren !
Grundlagen zum IPsec VPN findest du zusätzlich noch in diesen Forumstutorials:
IPSEC Protokoll - Einsatz, Aufbau, benötigte Ports und Begriffserläuterungen
und
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Da der Router ein VPN Router ist sind die IPsec Ports am WAN Port in seiner Firewall generell frei. Daran sollte es also nicht liegen. Eher an den o.g. Punkten.
Ein besserer Client als der Cisco Client ist übrigens der freie Shrew Client:
https://www.shrew.net/download
Leider schreibst du recht wenig zu deinem Netzdesign so das du uns nun hier wieder zum Nachfragen und Raten zwingst...
Gemäß Datenblatt:
http://www.cisco.com/en/US/prod/collateral/routers/ps10907/ps9923/ps119 ...
hat der Router kein integriertes DSL oder Kabel Modem deshalb solltest du folgende Fragen wasserdicht beantworten für eine zielführende Hilfe:
- WIE ist dieser Router ans Internet angebunden ?? Mit einem reinen DSL oder TV Kabel Modem (kein Router !) davor oder mit einem NAT Router (also einer Router Kaskade) davor ?
- Falls es letzteres ist, hast du dann auf dem davorliegenden NAT Router die IPsec Ports UDP 500, UDP 4500 und das ESP Protokoll (IP Nummer 50) entsprechend im Port Forwarding freigegeben auf den WAN Port des Cisco ??
- Benutzt der Cisco oder der evtl. davorliegende Router eine öffentliche IP Adresse am WAN / Providerport oder arbeitet der Provider mit privaten RFC 1918 IP Adressen. Wichtig ! Das kannst du im Router Setup nachsehen in den Statistiken zum WAN Port.
- WIE machst du den Client Zugriff ?? Ist der wirklich remote oder versuchst du aus dem internen Netz auf dem WAN IP des Routers zuzugreifen ?
Ein Zugriff mit dem VPN Client aus dem lokalen LAN des Routers schlägt generell immer fehl, denn diese Router supporten KEIN Hairpin NAT !!
Was das ist und warum es fehlschlägt kannst du hier nachlesen:
http://wiki.mikrotik.com/wiki/Hairpin_NAT
Einen wasserdichten Test kannst du ganz einfach fahren indem du dem WAN Port im Cisco Router Setup mal eine statische IP gibst.
Dann schliesst du den VPN Client PC mit einem Kabel am Cisco WAN Port an und gibst dem ebenfalls eine statische IP Adresse.
Damit hast du den Client dann direkt am Router und ein VPN Aufbau sollte fehlerlos funktionieren !
Grundlagen zum IPsec VPN findest du zusätzlich noch in diesen Forumstutorials:
IPSEC Protokoll - Einsatz, Aufbau, benötigte Ports und Begriffserläuterungen
und
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Da der Router ein VPN Router ist sind die IPsec Ports am WAN Port in seiner Firewall generell frei. Daran sollte es also nicht liegen. Eher an den o.g. Punkten.
Das "Kabelmodem" arbeitet also nicht als Modem sondern als NAT Router, richtig ??
Das IPsec Passthrough aktiviert ist nützt dir in deinem Szenario rein gar nichts, denn das bedeutet nur das IPsec Verbindungen von innen nach außen durchkommen.
Bei dir ist es ja genau umgedreht, du musst die Verbindungen von außen nach innen durchlassen !!
Deshalb musst du auf dem davorliegenden Kabelrouter zwingend die 3 oben genannten Ports bzw. Protokolle freigeben sonnst klappt das niemals, denn IPsec Anfragen von außen könnten ohne das Port Forwarding niemals die interne NAT Firewall dieses Routers überwinden !!
Du betreibst damit eine Router Kaskade wie sie hier in der "Alternative 2" beschrieben ist !
Kopplung von 2 Routern am DSL Port
Da ist dann auch die o.a. Fehlermeldung vollkommen klar, denn daran kannst du schon sehen das diese NAT Firewall deine Verbindung vollkommen blockiert: "Oct 19 16:59:54 09[IKE] peer not responding, trying again (2/0)"
...der VPN Router antwortet also gar nicht !!
Mit keinem IPsec Client egal ob auf iPhone, Android oder PC kannst du den VPN Router dann erreichen !!
Solange du das Port Forwarding der o.a. 3 Ports auf dem Kabel Router auf den danach folgenden Cisco 180V nicht korrekt einstellst wird sich daran auch nix ändern !!
Da liegt dein fataler Setup Fehler !! Wenn das richtig eingestellt ist funktioniert das fehlerfrei !
Das IPsec Passthrough aktiviert ist nützt dir in deinem Szenario rein gar nichts, denn das bedeutet nur das IPsec Verbindungen von innen nach außen durchkommen.
Bei dir ist es ja genau umgedreht, du musst die Verbindungen von außen nach innen durchlassen !!
Deshalb musst du auf dem davorliegenden Kabelrouter zwingend die 3 oben genannten Ports bzw. Protokolle freigeben sonnst klappt das niemals, denn IPsec Anfragen von außen könnten ohne das Port Forwarding niemals die interne NAT Firewall dieses Routers überwinden !!
Du betreibst damit eine Router Kaskade wie sie hier in der "Alternative 2" beschrieben ist !
Kopplung von 2 Routern am DSL Port
Da ist dann auch die o.a. Fehlermeldung vollkommen klar, denn daran kannst du schon sehen das diese NAT Firewall deine Verbindung vollkommen blockiert: "Oct 19 16:59:54 09[IKE] peer not responding, trying again (2/0)"
...der VPN Router antwortet also gar nicht !!
Mit keinem IPsec Client egal ob auf iPhone, Android oder PC kannst du den VPN Router dann erreichen !!
Solange du das Port Forwarding der o.a. 3 Ports auf dem Kabel Router auf den danach folgenden Cisco 180V nicht korrekt einstellst wird sich daran auch nix ändern !!
Da liegt dein fataler Setup Fehler !! Wenn das richtig eingestellt ist funktioniert das fehlerfrei !
OK, dann hast du keinerlei Chance ein laufendes VPN damit herzustellen. Das gilt für alle VPN Protokolle dann.
Das ist leider das Los derer die sich an einen Provider mit Zwangsroutern verkaufen. Weiss man als Netzwerker aber ja vorher.
Als Rettung kann man aber sagen das du wie immer bei solcherlei Threads hier das Handbuch nicht richtig gelesen hast !! (Sorry, aber wie soll man sonst "ärgern" ausdrücken ?)
http://www.kabelbw.de/kabelbw/cms/downloads/kabel-bw-handbuch-kabel-gat ...
Auf Seite 63 unten steht ganz genau WIE diese Portweiterleitung im Kabelrouter zu machen ist !
Wenn es schon an solchen banalen Basics scheitert wie Handbuch lesen macht ein Troubleshooting auch ohne "!" (wieder sorry, das musste jetzt da rein) nicht wirklich Spaß wie du dir sicher selber denken kann...auch wenn heute Sonntag ist.
Eine Minimalchance hast du noch (solltest du ein anderes Setup GUI haben als das obige) wenn du den Kabelrouter im Setup als reines Modem konfigurieren kannst und das eigentliche Routing dann mit dem Cisco 180V machst.
Das würde dein Problem auch lösen.
Klappt das auch nicht ist dein Anschluss eben nicht VPN fähig...so einfach ist das.
Das ist leider das Los derer die sich an einen Provider mit Zwangsroutern verkaufen. Weiss man als Netzwerker aber ja vorher.
Als Rettung kann man aber sagen das du wie immer bei solcherlei Threads hier das Handbuch nicht richtig gelesen hast !! (Sorry, aber wie soll man sonst "ärgern" ausdrücken ?)
http://www.kabelbw.de/kabelbw/cms/downloads/kabel-bw-handbuch-kabel-gat ...
Auf Seite 63 unten steht ganz genau WIE diese Portweiterleitung im Kabelrouter zu machen ist !
Wenn es schon an solchen banalen Basics scheitert wie Handbuch lesen macht ein Troubleshooting auch ohne "!" (wieder sorry, das musste jetzt da rein) nicht wirklich Spaß wie du dir sicher selber denken kann...auch wenn heute Sonntag ist.
Eine Minimalchance hast du noch (solltest du ein anderes Setup GUI haben als das obige) wenn du den Kabelrouter im Setup als reines Modem konfigurieren kannst und das eigentliche Routing dann mit dem Cisco 180V machst.
Das würde dein Problem auch lösen.
Klappt das auch nicht ist dein Anschluss eben nicht VPN fähig...so einfach ist das.