VPN-Problem mit NETGEAR ProSafe FVS336GV2
Hallo,
ich habe ein Problem mit der IPSEC-VPN-Verbindung zwischen einem Client und einem Netgear-Router (NETGEAR ProSafe VPN Firewall FVS336GV2), der selbst nochmals in einem Netzwerk steckt. Zwar kommunizieren beide Geräte und der Client sagt auch, die Verbindung wäre aufgebaut, aber der Router ist anderer Meinung und Netzzugriff funktioniert auch nicht.
(Hinweis: Meine Logs sind leider von unten nach oben zu lesen, wie sie aus dem Router kommen).
Allgemeines zum Netzwerk:
- Client (90.CC...) --> Übergeordnetes Netz (YYY.YY...) --> Router mit eigenem internen Netz (Local: 172.S.S.1)
- WAN des eigenen Routers: YYY.YY.YY.YY
- "Übergeordnetes Netz" leitet Ports weiter (4500, 500)
Beim Verbindungsaufbau passiert Folgendes:
- Client (Android-Gerät) zeigt eine stehende Verbindung an
- im Router wird keine bestehende Verbindung angezeigt und das Android-Gerät wird auch nicht als verbundenes Gerät mit IP angezeigt
Dies passiert, wenn der Client auf die Verbindung zugreifen will (egal ob externe WEB-Adresse oder interne Router-IP):
Wo genau liegt denn nun mein Problem? Am wahrscheinlichsten ist wohl eine falsche Konfiguration im Client. Aber kan nes auch sein, dass ich im Router noch eine Weiterleitung konfigurieren muss?
Muss explizit in der Router-Firewall noch etwas angepasst oder Ports freigeschaltet werden?
Vielen Dank im Voraus!
ich habe ein Problem mit der IPSEC-VPN-Verbindung zwischen einem Client und einem Netgear-Router (NETGEAR ProSafe VPN Firewall FVS336GV2), der selbst nochmals in einem Netzwerk steckt. Zwar kommunizieren beide Geräte und der Client sagt auch, die Verbindung wäre aufgebaut, aber der Router ist anderer Meinung und Netzzugriff funktioniert auch nicht.
(Hinweis: Meine Logs sind leider von unten nach oben zu lesen, wie sie aus dem Router kommen).
Allgemeines zum Netzwerk:
- Client (90.CC...) --> Übergeordnetes Netz (YYY.YY...) --> Router mit eigenem internen Netz (Local: 172.S.S.1)
- WAN des eigenen Routers: YYY.YY.YY.YY
- "Übergeordnetes Netz" leitet Ports weiter (4500, 500)
Beim Verbindungsaufbau passiert Folgendes:
- Client (Android-Gerät) zeigt eine stehende Verbindung an
- im Router wird keine bestehende Verbindung angezeigt und das Android-Gerät wird auch nicht als verbundenes Gerät mit IP angezeigt
2013 Aug 12 14:18:58 [FVS336GV2] [IKE] Ignored attribute 28678_
2013 Aug 12 14:18:58 [FVS336GV2] [IKE] Cannot open "/etc/motd"_
2013 Aug 12 14:18:58 [FVS336GV2] [IKE] 10.10.10.10 IP address is assigned to remote peer 90.CCC.C.CCC[40666]_
2013 Aug 12 14:18:58 [FVS336GV2] [IKE] Received attribute type "ISAKMP_CFG_REQUEST" from 90.CCC.C.CCC[40666]_
2013 Aug 12 14:18:58 [FVS336GV2] [IKE] Login succeeded for user "user"_
2013 Aug 12 14:18:58 [FVS336GV2] [IKE] Received attribute type "ISAKMP_CFG_REPLY" from 90.CCC.C.CCC[40666]_
2013 Aug 12 14:18:57 [FVS336GV2] [IKE] ISAKMP-SA established for YYY.YY.YY.YY[4500]-90.CCC.C.CCC[40666] with spi:0f4ccd70c5995409:bc7cgsdbs83_
2013 Aug 12 14:18:57 [FVS336GV2] [IKE] Sending Xauth request to 90.CCC.C.CCC[40666]_
2013 Aug 12 14:18:57 [FVS336GV2] [IKE] NAT detected: Local is behind a NAT device. and alsoPeer is behind a NAT device_
2013 Aug 12 14:18:57 [FVS336GV2] [IKE] NAT-D payload does not match for 90.CCC.C.CCC[40666]_
2013 Aug 12 14:18:57 [FVS336GV2] [IKE] NAT-D payload does not match for YYY.YY.YY.YY[4500]_
2013 Aug 12 14:18:57 [FVS336GV2] [IKE] Floating ports for NAT-T with peer 90.CCC.C.CCC[40666]_
2013 Aug 12 14:18:57 [FVS336GV2] [IKE] Setting DPD Vendor ID_
2013 Aug 12 14:18:57 [FVS336GV2] [IKE] For 90.CCC.C.CCC[61764], Selected NAT-T version: draft-ietf-ipsec-nat-t-ike-02_
2013 Aug 12 14:18:57 [FVS336GV2] [IKE] DPD is Enabled_
2013 Aug 12 14:18:57 [FVS336GV2] [IKE] Received Vendor ID: DPD_
2013 Aug 12 14:18:57 [FVS336GV2] [IKE] Received Vendor ID: CISCO-UNITY_
2013 Aug 12 14:18:57 [FVS336GV2] [IKE] Received Vendor ID: draft-irgtf-ipzra-isakmp-xauth-06.txt_
2013 Aug 12 14:18:57 [FVS336GV2] [IKE] Received unknown Vendor ID_
2013 Aug 12 14:18:57 [FVS336GV2] [IKE] Received Vendor ID: draft-ietf-ipsec-nat-t-ike-02__
- Last output repeated 2 times -
2013 Aug 12 14:18:57 [FVS336GV2] [IKE] Received unknown Vendor ID_
2013 Aug 12 14:18:56 [FVS336GV2] [IKE] Beginning Aggressive mode._
2013 Aug 12 14:18:56 [FVS336GV2] [IKE] Received request for new phase 1 negotiation: 172.SS.S.SS[500]<=>90.CCC.C.CCC[61764]_
2013 Aug 12 14:18:56 [FVS336GV2] [IKE] Remote configuration for identifier "XXX_XXX.XXX_" found_
Dies passiert, wenn der Client auf die Verbindung zugreifen will (egal ob externe WEB-Adresse oder interne Router-IP):
2013 Aug 12 14:19:34 [FVS336GV2] [IKE] Failed to get IPsec SA configuration for: 0.0.0.0/0<->10.10.10.10/32 from XXX_XXX.XXX_
2013 Aug 12 14:19:34 [FVS336GV2] [IKE] Responding to new phase 2 negotiation:YYY.YY.YY.YY<=>90.CCC.C.CCC_
2013 Aug 12 14:19:31 [FVS336GV2] [IKE] Failed to get IPsec SA configuration for: 0.0.0.0/0<->10.10.10.10/32 from XXX_XXX.XXX_
2013 Aug 12 14:19:31 [FVS336GV2] [IKE] Responding to new phase 2 negotiation: YYY.YY.YY.YY<=>90.CCC.C.CCC_
2013 Aug 12 14:19:29 [FVS336GV2] [IKE] Failed to get IPsec SA configuration for: 0.0.0.0/0<->10.10.10.10/32 from XXX_XXX.XXX__
2013 Aug 12 14:19:29 [FVS336GV2] [IKE] Responding to new phase 2 negotiation: YYY.YY.YY.YY<=>90.CCC.C.CCC_
2013 Aug 12 14:19:25 [FVS336GV2] [IKE] Failed to get IPsec SA configuration for: 0.0.0.0/0<->10.10.10.10/32 from XXX_XXX.XXX__
2013 Aug 12 14:19:25 [FVS336GV2] [IKE] Responding to new phase 2 negotiation: YYY.YY.YY.YY<=>90.CCC.C.CCC_
2013 Aug 12 14:19:22 [FVS336GV2] [IKE] Failed to get IPsec SA configuration for: 0.0.0.0/0<->10.10.10.10/32 from XXX_XXX.XXX__
2013 Aug 12 14:19:22 [FVS336GV2] [IKE] Responding to new phase 2 negotiation: YYY.YY.YY.YY<=>90.CCC.C.CCC_
2013 Aug 12 14:19:19 [FVS336GV2] [IKE] Failed to get IPsec SA configuration for: 0.0.0.0/0<->10.10.10.10/32 from XXX_XXX.XXX__
2013 Aug 12 14:19:19 [FVS336GV2] [IKE] Responding to new phase 2 negotiation: YYY.YY.YY.YY<=>90.CCC.C.CCC_
2013 Aug 12 14:19:16 [FVS336GV2] [IKE] Failed to get IPsec SA configuration for: 0.0.0.0/0<->10.10.10.10/32 from XXX_XXX.XXX__
2013 Aug 12 14:19:16 [FVS336GV2] [IKE] Responding to new phase 2 negotiation: YYY.YY.YY.YY<=>90.CCC.C.CCC_
2013 Aug 12 14:19:13 [FVS336GV2] [IKE] Failed to get IPsec SA configuration for: 0.0.0.0/0<->10.10.10.10/32 from XXX_XXX.XXX__
2013 Aug 12 14:19:13 [FVS336GV2] [IKE] Responding to new phase 2 negotiation: YYY.YY.YY.YY<=>90.CCC.C.CCC_
2013 Aug 12 14:19:10 [FVS336GV2] [IKE] Failed to get IPsec SA configuration for: 0.0.0.0/0<->10.10.10.10/32 from XXX_XXX.XXX__
2013 Aug 12 14:19:10 [FVS336GV2] [IKE] Responding to new phase 2 negotiation: YYY.YY.YY.YY<=>90.CCC.C.CCC_
2013 Aug 12 14:19:08 [FVS336GV2] [IKE] Failed to get IPsec SA configuration for: 0.0.0.0/0<->10.10.10.10/32 from XXX_XXX.XXX__
2013 Aug 12 14:19:08 [FVS336GV2] [IKE] Responding to new phase 2 negotiation: YYY.YY.YY.YY<=>90.CCC.C.CCC_
Wo genau liegt denn nun mein Problem? Am wahrscheinlichsten ist wohl eine falsche Konfiguration im Client. Aber kan nes auch sein, dass ich im Router noch eine Weiterleitung konfigurieren muss?
Muss explizit in der Router-Firewall noch etwas angepasst oder Ports freigeschaltet werden?
Vielen Dank im Voraus!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 214131
Url: https://administrator.de/contentid/214131
Ausgedruckt am: 22.11.2024 um 15:11 Uhr
15 Kommentare
Neuester Kommentar
Was bitte meinst du gena mit der Formulierung "...der selbst nochmals in einem Netzwerk steckt" ??
Das ist ziemlich schwammig und könnte auch das Problem sein wenn VOR der NetGear Gurke noch ein NAT Router oder ne NAT Firewall liegt !! Also einen Router Kaskade wie hier in der Alternative 2 beschrieben:
Kopplung von 2 Routern am DSL Port
Dann musst du dort zwingend Port Forwarding für IPsec auf den NetGear WAN Port machen.
Beschreibe also bitte die Infrastruktur damit wir dir zielführend helfen können ! Sonst wird das nix !
Weitere Hilfe zu den Grundlagen von IPsec VPNs findest du hier:
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
Das ist ziemlich schwammig und könnte auch das Problem sein wenn VOR der NetGear Gurke noch ein NAT Router oder ne NAT Firewall liegt !! Also einen Router Kaskade wie hier in der Alternative 2 beschrieben:
Kopplung von 2 Routern am DSL Port
Dann musst du dort zwingend Port Forwarding für IPsec auf den NetGear WAN Port machen.
Beschreibe also bitte die Infrastruktur damit wir dir zielführend helfen können ! Sonst wird das nix !
Weitere Hilfe zu den Grundlagen von IPsec VPNs findest du hier:
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
Hi Zapp-Brannigen,
hast du auch das ESP-Protokoll auf deinen FVS weitergeleitet?
Hast du den VPN-Zugriff über einen PC mit bspw. dem Shrew-Client schon erfolgreich hergestellt?
Setz auch mal die Encryption von AES-256 herunter auf AES-128 oder 3DES und schau, ob es dann klappt.
Wenn es denn überhaupt nicht klappt, würde ich zuerst testen, ob das VPN steht, wenn kein Router vor dem FVS steht.
hast du auch das ESP-Protokoll auf deinen FVS weitergeleitet?
Hast du den VPN-Zugriff über einen PC mit bspw. dem Shrew-Client schon erfolgreich hergestellt?
Setz auch mal die Encryption von AES-256 herunter auf AES-128 oder 3DES und schau, ob es dann klappt.
Wenn es denn überhaupt nicht klappt, würde ich zuerst testen, ob das VPN steht, wenn kein Router vor dem FVS steht.
2013 Aug 12 14:18:57 [FVS336GV2] [IKE] NAT detected: Local is behind a NAT device. and alsoPeer is behind a NAT device_
2013 Aug 12 14:18:57 [FVS336GV2] [IKE] NAT-D payload does not match for YYY.YY.YY.YY[4500]_
2013 Aug 12 14:18:57 [FVS336GV2] [IKE] NAT-D payload does not match for 90.CCC.C.CCC[40666]_
Also bei einer Doppel NAT, Bastion Host, dual homed firewall oder wie man sie auch noch nennt, einer Router Kaskade,
terminiert man eigentlich immer an dem ersten Gerät, hier im Szenario also immer an dem Router (Cisco) vor der
FVS336Gv2, ansonsten ist es immer besser bzw., ratsam dass das Gerät was via VPN erreicht werden soll in
einer DMZ hinter der ersten Stelle im Netzwerk (Cisco Router) gestellt wird.
Ansonsten macht die Router Kaskade ja eigentlich auch gar keinen Sinn, das ist eben so.
Man hat Geräte in einer DMZ die zum ersten Router gehört und der zweite Router oder die Firewall schützt das
restliche Netzwerk, fertig. Ansonsten ist die nämlich gar nicht mehr von Nöten und man fährt mit einem
guten LAN Switch erheblich besser, denn dort kann man noch über die Switch ACLs oder Port Security Einstellungen
mehr regeln.
Gruß
Dobby
Zitat von @ZappBrannigen:
Mit dieser Anleitung konnte ich das Problem lösen, der Zugriff funktioniert jetzt aus jedem Netz heraus in das Zielnetz mit
Shrew VPN Client:
https://www.shrew.net/support/Howto_Netgear
Schön, dass es jetzt funktioniert.Mit dieser Anleitung konnte ich das Problem lösen, der Zugriff funktioniert jetzt aus jedem Netz heraus in das Zielnetz mit
Shrew VPN Client:
https://www.shrew.net/support/Howto_Netgear
Ich vermute, ich hatte einen der folgenden Fehler gemacht, oder eine Kombination aus mehreren (mit abfallender
Wahrscheinlichkeit):
Mal sehen?Wahrscheinlichkeit):
- Client: unter Policy muss das Zielnetz definiert werden, vorher hatte ich das Subnetz angegeben, dass die VPN-Clients bekommen,
es muss aber das eigentliche interne Subnetz des Routers sein (am wahrscheinlichsten die Ursache)
Ja, dort muss definitiv das Zielnetz stehen ("Remote Network Ressource" sagt es ja aus)es muss aber das eigentliche interne Subnetz des Routers sein (am wahrscheinlichsten die Ursache)
- Router: Mode-Config, WINS/DNS Server nicht oder falsach definiert (muss der internen Router-IP entsprechen)
Der DNS-Server sollte hier eingetragen sein, das muss aber nicht der Router sein, sondernd dein verantwortlicher DNS-Server.In sehr vielen Fällen ist das ein Windows-DC.
Einen WINS-Server trägst du nur ein, wenn du einen aktiven WINS-Server im Netzwerk hast.
- Router/Client: Phase 2 (Mode Config) PFS-Gruppe ist jetzt deaktiviert, war vorher aktiv
Nein, muss nur identisch auf Router/Client konfiguriert sein.- Router/Client: IKE-Policy und Mode-Config hatten die selben timeouts, jetzt sind sie unterschiedlich
Nein, die können auch identisch sein. Wichtig ist die gleiche Einstellung bei Router/Client.Zitat von @ZappBrannigen:
Noch ein Hinweis zum Thema: mit der App "NCP VPN Client" ist auch eine VPN-Verbindung mittels Android (ohne root, ab
Android Version 4.0) möglich.
Ob die mit diesem Clienten vorher möglich war, kann ich nicht sagen, aber mit den 4.x Androiden klappt es perfekt.Noch ein Hinweis zum Thema: mit der App "NCP VPN Client" ist auch eine VPN-Verbindung mittels Android (ohne root, ab
Android Version 4.0) möglich.
Unsere Androide haben zwischen 3 und 12 VPNs zu diversen IPSEC-Gegenstellen konfiguriert, die sehr bequem per Drop-Down-Liste ausgewählt werden können.
Zitat von @ZappBrannigen:
Richtig, die Konfiguration ist wirklich recht komfortabel bei dieser App, grad ebei mehreren Zugangspunkten. Ebenso die
Import/Export-Funktion.
Ich nutze die Standardversion für 2,99 Euro, eine lohende Investition. Es gibt noch eine Pro-Version für knapp 30 Euro,
aber ich kann spontan nicht sagen, für was speziell man diese dann zwingend braucht.
Der Premium Client beherrscht bspw. IKEv2, Autoreconnect und FIPS.Richtig, die Konfiguration ist wirklich recht komfortabel bei dieser App, grad ebei mehreren Zugangspunkten. Ebenso die
Import/Export-Funktion.
Ich nutze die Standardversion für 2,99 Euro, eine lohende Investition. Es gibt noch eine Pro-Version für knapp 30 Euro,
aber ich kann spontan nicht sagen, für was speziell man diese dann zwingend braucht.
Schau mal auf diese Seite in das Datenblatt (unter Ressourcen), dort ist das aufgelistet.
Für mich ist auch der Standard-Client ausreichend.