13.08.2013, aktualisiert am 15.08.2013

6872

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

Aug 12 14:18:58 [FVS336GV2] [IKE] Ignored attribute 28678_
Aug 12 14:18:58 [FVS336GV2] [IKE] Cannot open "/etc/motd"_
Aug 12 14:18:58 [FVS336GV2] [IKE] 10.10.10.10 IP address is assigned to remote peer 90.CCC.C.CCC[40666]_
Aug 12 14:18:58 [FVS336GV2] [IKE] Received attribute type "ISAKMP_CFG_REQUEST" from 90.CCC.C.CCC[40666]_
Aug 12 14:18:58 [FVS336GV2] [IKE] Login succeeded for user "user"_
Aug 12 14:18:58 [FVS336GV2] [IKE] Received attribute type "ISAKMP_CFG_REPLY" from 90.CCC.C.CCC[40666]_
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_
Aug 12 14:18:57 [FVS336GV2] [IKE] Sending Xauth request to 90.CCC.C.CCC[40666]_
Aug 12 14:18:57 [FVS336GV2] [IKE] NAT detected: Local is behind a NAT device. and alsoPeer is behind a NAT device_
Aug 12 14:18:57 [FVS336GV2] [IKE] NAT-D payload does not match for 90.CCC.C.CCC[40666]_
Aug 12 14:18:57 [FVS336GV2] [IKE] NAT-D payload does not match for YYY.YY.YY.YY[4500]_
Aug 12 14:18:57 [FVS336GV2] [IKE] Floating ports for NAT-T with peer 90.CCC.C.CCC[40666]_
Aug 12 14:18:57 [FVS336GV2] [IKE] Setting DPD Vendor ID_
Aug 12 14:18:57 [FVS336GV2] [IKE] For 90.CCC.C.CCC[61764], Selected NAT-T version: draft-ietf-ipsec-nat-t-ike-02_
Aug 12 14:18:57 [FVS336GV2] [IKE] DPD is Enabled_
Aug 12 14:18:57 [FVS336GV2] [IKE] Received Vendor ID: DPD_
Aug 12 14:18:57 [FVS336GV2] [IKE] Received Vendor ID: CISCO-UNITY_
Aug 12 14:18:57 [FVS336GV2] [IKE] Received Vendor ID: draft-irgtf-ipzra-isakmp-xauth-06.txt_
Aug 12 14:18:57 [FVS336GV2] [IKE] Received unknown Vendor ID_
Aug 12 14:18:57 [FVS336GV2] [IKE] Received Vendor ID: draft-ietf-ipsec-nat-t-ike-02__
                - Last output repeated 2 times -
Aug 12 14:18:57 [FVS336GV2] [IKE] Received unknown Vendor ID_
Aug 12 14:18:56 [FVS336GV2] [IKE] Beginning Aggressive mode._
Aug 12 14:18:56 [FVS336GV2] [IKE] Received request for new phase 1 negotiation: 172.SS.S.SS[500]<=>90.CCC.C.CCC[61764]_
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):

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_
Aug 12 14:19:34 [FVS336GV2] [IKE] Responding to new phase 2 negotiation:YYY.YY.YY.YY<=>90.CCC.C.CCC_
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_
Aug 12 14:19:31 [FVS336GV2] [IKE] Responding to new phase 2 negotiation: YYY.YY.YY.YY<=>90.CCC.C.CCC_
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__
Aug 12 14:19:29 [FVS336GV2] [IKE] Responding to new phase 2 negotiation: YYY.YY.YY.YY<=>90.CCC.C.CCC_
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__
Aug 12 14:19:25 [FVS336GV2] [IKE] Responding to new phase 2 negotiation: YYY.YY.YY.YY<=>90.CCC.C.CCC_
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__
Aug 12 14:19:22 [FVS336GV2] [IKE] Responding to new phase 2 negotiation: YYY.YY.YY.YY<=>90.CCC.C.CCC_
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__
Aug 12 14:19:19 [FVS336GV2] [IKE] Responding to new phase 2 negotiation: YYY.YY.YY.YY<=>90.CCC.C.CCC_
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__
Aug 12 14:19:16 [FVS336GV2] [IKE] Responding to new phase 2 negotiation: YYY.YY.YY.YY<=>90.CCC.C.CCC_
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__
Aug 12 14:19:13 [FVS336GV2] [IKE] Responding to new phase 2 negotiation: YYY.YY.YY.YY<=>90.CCC.C.CCC_
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__
Aug 12 14:19:10 [FVS336GV2] [IKE] Responding to new phase 2 negotiation: YYY.YY.YY.YY<=>90.CCC.C.CCC_
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__
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: 07.11.2024 um 18: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 meinte ich unter "allgemeines zum Netzwerk". Der Router selbst ist Teil eines Firmennetzwerkes. Dieses ist mit dem Internet verbunden, der Zielrouter hat hierzu eine feste IP bekommen, anfragen aus dem WWW auf diese IP werden vom übergeordneten Firmennetzwerk-Router über die Ports 4500 und 500 an den Netgear-Router weitergeleitet.

Hier mal die Routereinstellungen zum VPN:
IKE Policy

MODE Config

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.

Hallo Goscho,

da ich die Variante aus der Anleitung "UDP Port 500 und UDP Port 4500 (Wenn ESP via NAT-T in UDP gekapselt wird)" verwende, genügen die beiden bsiher freigeschalteten Ports doch, oder?

Kann es sein, das für diese Methode NetBios aktiviert sein muss? Das kann ich im Router nur einstellen, wenn ich statt MODE-Config eine VPN-Policy verwende. Allerdings bekomme ich dann im Router-Protokoll die Fehlermeldung, das keine MODE-Config gefunden wurde.

Testen konnte ich bisher leider nur mit dem Android-integrierten VPN-Client, der lässt nicht viel Spielraum für einstellungen, scheint nur mit MODE-Config zu funktionieren.

EDIT:
Ich habe es jetzt aus einem parallelen Netzwerk innerhalb des übergeordneten Netzwerkes probiert, gleicher Fehler. Die Port-Weiterleitung ist also nicht die Ursache für dieses Problem.

Nach weiterer Recherche scheint bis dato die Verbindung zwischen Android und Netgear mit den Android-integrierten VPN-Lösungen nicht möglich.
Ich muss es also mit einem anderen Client testen und gebe dann Feedback.

2013 Aug 12 14:18:57 [FVS336GV2] [IKE] NAT detected: Local is behind a NAT device. and alsoPeer is behind a NAT device_ 

Hier steht ja auch dass die FVS336Gv2 hinter einem anderen Router steht

2013 Aug 12 14:18:57 [FVS336GV2] [IKE] NAT-D payload does not match for YYY.YY.YY.YY[4500]_ 

Das ist dann wohl der Port 4500

 2013 Aug 12 14:18:57 [FVS336GV2] [IKE] NAT-D payload does not match for 90.CCC.C.CCC[40666]_ 

Das hier ist aber nicht der Port 500, sondern der 40666, also da könnte man noch einmal gucken finde ich.

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

Ich habe zwischenzeitlich auch noch mit dem Administrator des übergeordneten Netzes gesprochen, er meinte zumindest er hätte es prinzipiell schon mit Netgear-Geräten hinbekommen. Und gab mir noch den Hinweis, NAT auf meinem Router zu deaktivieren. Das brachte leider auch keinen Erfolg.

Getestet habe ich auch den Zugriff aus einem "parallelen" Netz, also einem anderen Firmennetz innerhalb des "übergeordneten Netzes", gleiche Probleme.

Was den Port 40666 angeht so war das ein Zugriff aus dem Mobilfunknetz, entweder Android verwendet hier keine Standardports, oder es ist der Mobilfunkanbieter.
Allerdings habe ich es ebenso mit Shrewsoft und dem Netgear-VPN-Client getestet, ebenfalls erfolglos.

Mit Shrew bekomme ich auch die Meldung, der Tunnel sei aufgebaut, habe sogar Netzzugriff, aber der Traffic läuft nicht durchs VPN und ich habe auch keinen Zugriff auf das interne LAN-Netz. Im Log erscheinen hier auch die Meldungen, das IPSec SA Configuration fehlschlug.

Hast du keine Möglichkeit, den FVS ohne Router-Kaskade zu nutzen?

Beim Einsatz von Shrew musste ich bisher immer genau auf die Version achten.
Es funktioniert aber definitiv mit der Version 2.2.0 beta 2 des Shrew-Clienten.

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):

- 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)
- Router: Mode-Config, WINS/DNS Server nicht oder falsach definiert (muss der internen Router-IP entsprechen)
- Router/Client: Phase 2 (Mode Config) PFS-Gruppe ist jetzt deaktiviert, war vorher aktiv
- Router/Client: IKE-Policy und Mode-Config hatten die selben timeouts, jetzt sind sie unterschiedlich

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.

Ich vermute, ich hatte einen der folgenden Fehler gemacht, oder eine Kombination aus mehreren (mit abfallender
Wahrscheinlichkeit):

Mal sehen?

- 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)

- 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.

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.

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.
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.

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.

Android gibt erst ab Version 4.0 externen Entwicklern Zugriff auf die internen VPN-Mechanismen, daher funktioniert es erst ab V4 ohne die Geräte zu rooten.
So funktioniert auch der Cisco Anyconnect erst ab Android 4.0 (Ausnahme bilden ältere Samsung-Geräte, dafür gab es eine spezielle App von Samsung/Cisco)

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.
Schau mal auf diese Seite in das Datenblatt (unter Ressourcen), dort ist das aufgelistet.
Für mich ist auch der Standard-Client ausreichend.

gelöst Frage Netzwerke Router, Routing

Mehr von ZappBrannigen

Windows Server CAD-Workstation + RemoteFXZappBrannigen - 2 Kommentare

LAN-to-LAN VPN (Draytec Vigor 2960, Fritzbox 7590)ZappBrannigen - 14 Kommentare

VPN: kein Zugriff auf LAN-Geräte, wenn eine statische Route aktivZappBrannigen - 3 Kommentare

Kaufberatung Drucker für BüroZappBrannigen - 12 Kommentare

Heiß diskutiert