3
Problem mit VPN - Netgear ProSafe FVS318v3 und ProSafe VPN Client
In einer einfachen Testumgebung bekomme ich keine Verbindung zu stande.
Hallo Community,
ich habe Probleme mit dem Netgear FVS318v3 in Verbindung mit dem VPN Client von Netgear (ProSafe VPN Client 10.1.1 Build 10). Als erstes eine Beschreibung des Netzwerks:
Es handelt sich hierbei um eine reine Testumgebung. An der WAN-Seite des Routers hängt ein Windows Server 2003 (DC, DHCP) sowie ein Client. Auf der LAN-Seite befindet sich nur ein Windows Server 2003 auf dem ein DNS läuft.
Der Router sowie der Client bekommen auf der WAN Seite vom DHCP eine IP (192.168.0.0/24) zugewiesen. Ich habe nun mithilfe des VPN Wizards des Routers eine VPN Konfiguration erstellt. Nun möchte ich mit dem Clientrechner (WAN-Seite) über eine VPN Verbindung auf die LAN-Seite (192.168.2.0/24, DHCP des Routers) zugreifen zB auf den Windows Server.
Das Problem ist das ich diese VPN-Verbindung nicht zu laufen kriege. Laut ProSafe VPN Client scheitert die Verbindung in Phase 2, Phase 1 durchläuft er ohne Probleme.
Kurzer Überblick der Einstellungen:
Client:
- Secure
- Remote Party Identity: Domain Name
- My Identity: Domain Name (Virtual Adapter: Disabled)
- Negotiation Mode: Aggressive Mode (Replay Detection enabled)
- Authentifizierungsmethode Phase 1 -> Pre-Shared Key
- Encryption über 3DES, Algorhythmus ist SHA-1
- Phase 2: ESP, 3DES, SHA-1, Tunnel
Router:
- Direction Type: Remote Access
- Exchange Mode: Aggressive Mode
- Local und Remote Identity: Fully Qualified Domain Name
- PFS disabled
- Remote VPN Endpoint: IP-Address (Address Data: 0.0.0.0)
- Traffic Selector: Local IP -> Subnet Address (192.168.2.0/24), Remote IP -> Any
- NETBIOS enabled
Client-LOG:
Router-Log:
Hoffe jemand kann mir weiterhelfen bin für jeden Tipp dankbar.
Mit freundlichen Grüßen
zero
ich habe Probleme mit dem Netgear FVS318v3 in Verbindung mit dem VPN Client von Netgear (ProSafe VPN Client 10.1.1 Build 10). Als erstes eine Beschreibung des Netzwerks:
Es handelt sich hierbei um eine reine Testumgebung. An der WAN-Seite des Routers hängt ein Windows Server 2003 (DC, DHCP) sowie ein Client. Auf der LAN-Seite befindet sich nur ein Windows Server 2003 auf dem ein DNS läuft.
Der Router sowie der Client bekommen auf der WAN Seite vom DHCP eine IP (192.168.0.0/24) zugewiesen. Ich habe nun mithilfe des VPN Wizards des Routers eine VPN Konfiguration erstellt. Nun möchte ich mit dem Clientrechner (WAN-Seite) über eine VPN Verbindung auf die LAN-Seite (192.168.2.0/24, DHCP des Routers) zugreifen zB auf den Windows Server.
Das Problem ist das ich diese VPN-Verbindung nicht zu laufen kriege. Laut ProSafe VPN Client scheitert die Verbindung in Phase 2, Phase 1 durchläuft er ohne Probleme.
Kurzer Überblick der Einstellungen:
Client:
- Secure
- Remote Party Identity: Domain Name
- My Identity: Domain Name (Virtual Adapter: Disabled)
- Negotiation Mode: Aggressive Mode (Replay Detection enabled)
- Authentifizierungsmethode Phase 1 -> Pre-Shared Key
- Encryption über 3DES, Algorhythmus ist SHA-1
- Phase 2: ESP, 3DES, SHA-1, Tunnel
Router:
- Direction Type: Remote Access
- Exchange Mode: Aggressive Mode
- Local und Remote Identity: Fully Qualified Domain Name
- PFS disabled
- Remote VPN Endpoint: IP-Address (Address Data: 0.0.0.0)
- Traffic Selector: Local IP -> Subnet Address (192.168.2.0/24), Remote IP -> Any
- NETBIOS enabled
Client-LOG:
1-08: 11:15:37.468
1-08: 11:15:37.468 My Connections\Test - Initiating IKE Phase 1 (IP ADDR=192.168.0.5)
1-08: 11:15:37.703 My Connections\Test - SENDING>>>> ISAKMP OAK AG (SA, KE, NON, ID, VID 5x)
1-08: 11:15:40.656 My Connections\Test - RECEIVED<<< ISAKMP OAK AG (SA, KE, NON, ID, HASH, VID, NAT-D 3x)
1-08: 11:15:40.656 My Connections\Test - Peer is NAT-T draft-01 capable
1-08: 11:15:41.468 My Connections\Test - SENDING>>>> ISAKMP OAK AG *(HASH, NAT-D 2x, NOTIFY:STATUS_INITIAL_CONTACT)
1-08: 11:15:41.468 My Connections\Test - Established IKE SA
1-08: 11:15:41.468 MY COOKIE 13 b3 66 17 ee 7c cb 96
1-08: 11:15:41.468 HIS COOKIE c4 94 7a f9 16 a0 a3 4f
1-08: 11:15:41.734 My Connections\Test - Initiating IKE Phase 2 with Client IDs (message id: 32A95F53)
1-08: 11:15:41.734 Initiator = IP ADDR=192.168.2.200, prot = 0 port = 0
1-08: 11:15:41.734 Responder = IP ADDR=192.168.0.5, prot = 0 port = 0
1-08: 11:15:41.734 My Connections\Test - SENDING>>>> ISAKMP OAK QM *(HASH, SA, NON, ID 2x)
1-08: 11:15:56.734 My Connections\Test - QM re-keying timed out (message id: 32A95F53). Retry count: 1
1-08: 11:15:56.734 My Connections\Test - SENDING>>>> ISAKMP OAK QM *(Retransmission)
1-08: 11:16:11.734 My Connections\Test - QM re-keying timed out (message id: 32A95F53). Retry count: 2
1-08: 11:16:11.734 My Connections\Test - SENDING>>>> ISAKMP OAK QM *(Retransmission)
1-08: 11:16:26.734 My Connections\Test - QM re-keying timed out (message id: 32A95F53). Retry count: 3
1-08: 11:16:26.734 My Connections\Test - SENDING>>>> ISAKMP OAK QM *(Retransmission)
1-08: 11:16:27.390 My Connections\Test - Disconnecting IPSec SA
1-08: 11:16:27.390 My Connections\Test - Disconnecting IKE SA negotiation
1-08: 11:16:27.390 My Connections\Test - Deleting IKE SA (IP ADDR=192.168.0.5)
1-08: 11:16:27.390 MY COOKIE 13 b3 66 17 ee 7c cb 96
1-08: 11:16:27.390 HIS COOKIE c4 94 7a f9 16 a0 a3 4f
1-08: 11:16:27.390 My Connections\Test - SENDING>>>> ISAKMP OAK INFO *(HASH, DEL)Router-Log:
[2000-01-01 04:23:42]**** RECEIVED FIRST MESSAGE OF QUICK MODE ****
[2000-01-01 04:23:42]<POLICY: test> PAYLOADS: HASH,SA,PROP,TRANS,NONCE,ID,ID
[2000-01-01 04:23:42]**** FOUND IDs,EXTRACT ID INFO ****
[2000-01-01 04:23:42]<Initiator IPADDR=192.168.2.200>
[2000-01-01 04:23:42]<Responder IPADDR=192.168.0.5>
[2000-01-01 04:23:57][==== IKE PHASE 2(from 192.168.0.16) START (responder) ====]
[2000-01-01 04:23:57]**** RECEIVED FIRST MESSAGE OF QUICK MODE ****
[2000-01-01 04:23:57]<POLICY: test> PAYLOADS: HASH,SA,PROP,TRANS,NONCE,ID,ID
[2000-01-01 04:23:57]**** FOUND IDs,EXTRACT ID INFO ****
[2000-01-01 04:23:57]<Initiator IPADDR=192.168.2.200>
[2000-01-01 04:23:57]<Responder IPADDR=192.168.0.5>
[2000-01-01 04:35:27]<POLICY: test> PAYLOADS: HASH,DEL
[2000-01-01 04:35:27]**** SENT OUT INFORMATIONAL EXCHANGE MESSAGE ****
[2000-01-01 04:35:27]<POLICY: test> PAYLOADS: HASH,DELHoffe jemand kann mir weiterhelfen bin für jeden Tipp dankbar.
Mit freundlichen Grüßen
zero
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 105476
Url: https://administrator.de/contentid/105476
Printed on: April 25, 2024 at 02:04 o'clock
3 Comments
Latest comment
hallo,
leider haben wir mit netgear + vpn keine guten erfahrungen gemacht (sind komplett auf sonicwall umgestiegen und die tunnel aufen seit monaten ohne störung. 3x klopf auf holz!!!).
insgesamt hatten wir 5 lokationen via netgear eingebunden (der zentrale router war DEIN besagter 318 in den aussenstellen 114 und 124G) und es lief überhaupt nicht stabil. chaos! teilweise traten u.a. auch die negotation fehler auf. oder die tunnel brachen ab und man musste die teile stromlos machen damit alles wieder geht usw. dann liefs mal wieder ein paar tage um dann erneut zusammen zu brechen.
hier also ein paar der schritte, die wir gemacht haben (dann haben wir den schrott nach 4 wochen chaos aus dem fenster geworfen.):
- firmwareupdate auf aktuelle firmware (beide gleich).
- mehrfacher kompletter reset der router
- neueinrichtung aller tunnel (ohne assistent. mach es manuell!) sowie tests verschiedener "sicherheitslevel" in den tunneln.
mein tipp: netgear macht ganz gute switche (die laufen ohne probleme bei uns), aber bei VPN lass es besser. gibt meist dauerhaft nur ärger, vor allem wenn es unternehmenskritisch ist.
kann leider nichts anderes dazu schreiben
viele grüsse
markus
leider haben wir mit netgear + vpn keine guten erfahrungen gemacht (sind komplett auf sonicwall umgestiegen und die tunnel aufen seit monaten ohne störung. 3x klopf auf holz!!!).
insgesamt hatten wir 5 lokationen via netgear eingebunden (der zentrale router war DEIN besagter 318 in den aussenstellen 114 und 124G) und es lief überhaupt nicht stabil. chaos! teilweise traten u.a. auch die negotation fehler auf. oder die tunnel brachen ab und man musste die teile stromlos machen damit alles wieder geht usw. dann liefs mal wieder ein paar tage um dann erneut zusammen zu brechen.
hier also ein paar der schritte, die wir gemacht haben (dann haben wir den schrott nach 4 wochen chaos aus dem fenster geworfen.):
- firmwareupdate auf aktuelle firmware (beide gleich).
- mehrfacher kompletter reset der router
- neueinrichtung aller tunnel (ohne assistent. mach es manuell!) sowie tests verschiedener "sicherheitslevel" in den tunneln.
mein tipp: netgear macht ganz gute switche (die laufen ohne probleme bei uns), aber bei VPN lass es besser. gibt meist dauerhaft nur ärger, vor allem wenn es unternehmenskritisch ist.
kann leider nichts anderes dazu schreiben
viele grüsse
markus
... axo, ganz vergessen ...
FQDN über DynDNS?
auch das war stellenweise ein problem und vor allem brauchen die router teilweise sehr lange um bei neuer IP die aktualsierung des DynDNS hin zu bekommen (teilweise ging auch das erst nach "strom raus, strom rein".
FQDN über DynDNS?
auch das war stellenweise ein problem und vor allem brauchen die router teilweise sehr lange um bei neuer IP die aktualsierung des DynDNS hin zu bekommen (teilweise ging auch das erst nach "strom raus, strom rein".
So, ich arbeite mit dem Threadersteller an dem Projekt zusammen.
Wir haben nun letztlich ne Verbindung herstellen können, allerdings kurioserweise nicht mit dem Netgear ProSafe Client, sondern mit dem Greenbow VPN Client bei gleichen Einstellungen.
Der Datenverkehr ist auch per Wireshark anhand der ESP Pakete nachweisbar, allerdings scheitern Pings weiterhin.
Die Verbindung steht also laut VPN-Router, VPN-Client und Wireshark auf dem Client, weiter geht allerdings nichts kurioserweise ....
Jemand eine Idee?
Wir haben nun letztlich ne Verbindung herstellen können, allerdings kurioserweise nicht mit dem Netgear ProSafe Client, sondern mit dem Greenbow VPN Client bei gleichen Einstellungen.
Der Datenverkehr ist auch per Wireshark anhand der ESP Pakete nachweisbar, allerdings scheitern Pings weiterhin.
Die Verbindung steht also laut VPN-Router, VPN-Client und Wireshark auf dem Client, weiter geht allerdings nichts kurioserweise ....
Jemand eine Idee?
