VPN Netgear FVX538 mit Prosafe VPN Client

Hallo Experten,

in verzweifle langsam an der VPN Konfiguration des obigen Routers. In Kürze:

Server im Unternehmen mit dem Netgear:
WAN IP: Dynamisch (über DynDNS)
LAN IP: 192.168.0.1

CLIENT zu Hause:
Router: DLINK 604
WAN IP: Wird vom Provider zugewiesen
LAN IP: 192.168.2.1

Rechner mit Prosafe Client:
LAN IP: 192.168.2.169

Folgende Fehlermeldung erscheint beim Log des Clients:

6-02: 21:24:12.734 My Connections\Aqua - Initiating IKE Phase 1 (Hostname=xxxxx.dyndns.org) (IP ADDR=80.144.41.148)
6-02: 21:24:12.906 My Connections\Aqua - SENDING>>>> ISAKMP OAK AG (SA, KE, NON, ID, VID 6x)
6-02: 21:24:13.109 My Connections\Aqua - RECEIVED<<< ISAKMP OAK AG (SA, KE, NON, ID, HASH, VID, NAT-D 2x, VID 2x)
6-02: 21:24:13.109 My Connections\Aqua - Peer is NAT-T draft-02 capable
6-02: 21:24:13.109 My Connections\Aqua - NAT is detected for Client
6-02: 21:24:13.109 My Connections\Aqua - Floating to IKE non-500 port
6-02: 21:24:13.109 My Connections\Aqua - Peer supports Dead Peer Detection Version 1.0
6-02: 21:24:13.109 My Connections\Aqua - Dead Peer Detection enabled
6-02: 21:24:13.203 My Connections\Aqua - Using cached address. (Hostname=xxxxx.dyndns.org) (IP ADDR=80.144.41.148)
6-02: 21:24:13.218 My Connections\Aqua - SENDING>>>> ISAKMP OAK AG *(HASH, NAT-D 2x, NOTIFY:STATUS_REPLAY_STATUS, NOTIFY:STATUS_INITIAL_CONTACT)
6-02: 21:24:13.218 My Connections\Aqua - Established IKE SA
6-02: 21:24:13.218 MY COOKIE 35 ab 69 f d9 ee 46 9d
6-02: 21:24:13.218 HIS COOKIE ea 5c 79 dc 7 a9 5 4c
6-02: 21:24:13.265
6-02: 21:24:13.265 My Connections\Aqua - Initiating IKE Phase 2 with Client IDs (message id: E4DF10A3)
6-02: 21:24:13.265 My Connections\Aqua - Initiator = IP ADDR=192.168.2.169, prot = 0 port = 0
6-02: 21:24:13.265 My Connections\Aqua - Responder = IP SUBNET/MASK=192.168.0.0/255.255.255.255, prot = 0 port = 0
6-02: 21:24:13.265 My Connections\Aqua - SENDING>>>> ISAKMP OAK QM *(HASH, SA, NON, ID 2x)
6-02: 21:24:28.984 My Connections\Aqua - QM re-keying timed out. Retry count: 1
6-02: 21:24:28.984 My Connections\Aqua - SENDING>>>> ISAKMP OAK QM *(Retransmission)
6-02: 21:24:43.984 My Connections\Aqua - QM re-keying timed out. Retry count: 2
6-02: 21:24:43.984 My Connections\Aqua - SENDING>>>> ISAKMP OAK QM *(Retransmission)
6-02: 21:24:58.984 My Connections\Aqua - QM re-keying timed out. Retry count: 3
6-02: 21:24:58.984 My Connections\Aqua - SENDING>>>> ISAKMP OAK QM *(Retransmission)
6-02: 21:25:13.984 My Connections\Aqua - Exceeded 3 re-keying attempts (message id: E4DF10A3)
6-02: 21:25:13.984 My Connections\Aqua - Disconnecting IKE SA negotiation
6-02: 21:25:13.984 My Connections\Aqua - Deleting IKE SA (IP ADDR=80.144.41.148)
6-02: 21:25:13.984 MY COOKIE 35 ab 69 f d9 ee 46 9d
6-02: 21:25:13.984 HIS COOKIE ea 5c 79 dc 7 a9 5 4c
6-02: 21:25:13.984 My Connections\Aqua - SENDING>>>> ISAKMP OAK INFO *(HASH, DEL)

Was könnte das sein?

Scatman

PS: Sorry für das lange Posting, aber ich wollte keine evtl. wichtige Info weglassen. Wahrscheinlich fehlen eh welche.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 11413

Url: https://administrator.de/contentid/11413

Ausgedruckt am: 23.11.2024 um 05:11 Uhr

11 Kommentare

Neuester Kommentar

Hallo,

hast du auf beiden Seiten die Firewall auf Port 500 UDP für IKE auf, scheint nämlich nicht so...

Was sagt denn Netgear ?

mfg
Ritchy

Hallo Ritchy,

für den DLink kann ich Dir das sofort bestätigen. Beim Netgear meine ich das eigentlich auch gemacht zu haben, werde aber erst ab dem 13.06. wieder im Büro sein.
Melde mich dann umgehend mit Ergebnissen.

Erstmal vielen Dank für Deinen Tipp. Hatte gar nicht mit einer so schnellen Antwort gerechnet

MfG
Scatman

Hi,

Habe genau das gleiche problem
die netze sehen folgender maßen aus:

Lokal:
FVX538 in der Firma:
wan: Feste IP
LAN: 192.168.9.1
(Soll VPN Gateway sein)

Remote:
Netgear irgendwass
wan: dynamische ip
LAN: 192.168.10.1
(soll nicht direkt als client fungieren aber ein rechner dahinter mit prosafe VPN client)

Also port 500 ist jeweils weitergeleitet.
Bzw. sollte ja eigendlich nur auf clientseite nötig sein.

hier mal die logfile vom client:
--snipp--
6-15: 16:22:50.859 My Connections\Corpcom-Net - Initiating IKE Phase 2 with
Client IDs (message id: DE948B8C)
6-15: 16:22:50.859 My Connections\Corpcom-Net - Initiator = IP
ADDR=192.168.10.131, prot = 0 port = 0
6-15: 16:22:50.859 My Connections\Corpcom-Net - Responder = IP
SUBNET/MASK=192.168.10.1/255.255.255.0, prot = 0 port = 0
6-15: 16:22:50.859 My Connections\Corpcom-Net - SENDING>>>> ISAKMP OAK QM
*(HASH, SA, NON, KE, ID 2x)
6-15: 16:22:54.953 My Connections\Corpcom-Net - RECEIVED<<< ISAKMP OAK AG
(Retransmission)
6-15: 16:22:59.968 My Connections\Corpcom-Net - RECEIVED<<< ISAKMP OAK AG
(Retransmission)
6-15: 16:23:01.093 My Connections\Corpcom-Net - QM re-keying timed out.
Retry count: 1
--snipp--

und der router sagt:

--snipp--
INFO :: Started phase-I negotiation
INFO :: received NOTIFY PAYLOAD of notify type REPLAY_STATUS
INFO :: received NOTIFY PAYLOAD of notify type INITIAL_CONTACT
INFO :: IKE phase-I started
INFO :: Initiator SPD selectors received: IPADDR, 192.168.10.131, proto
0, port 0
INFO :: Responder SPD selectors received: IP RANGE, 192.168.10.1,
192.168.10.200, proto 0, port 0
INFO :: No matching SPD policy for the selectors received in IKE phase-II
message
INFO :: IKE phase-II with message ID 494efd28 failed
INFO :: Initiator SPD selectors received: IPADDR, 192.168.10.131, proto
0, port 0
INFO :: Responder SPD selectors received: IP RANGE, 192.168.10.1,
192.168.10.200, proto 0, port 0
INFO :: No matching SPD policy for the selectors received in IKE phase-II
message
INFO :: IKE phase-II with message ID 494efd28 failed
INFO :: Initiator SPD selectors received: IPADDR, 192.168.10.131, proto
0, port 0
INFO :: Responder SPD selectors received: IP RANGE, 192.168.10.1,
192.168.10.200, proto 0, port 0
INFO :: No matching SPD policy for the selectors received in IKE phase-II
message
INFO :: IKE phase-II with message ID 494efd28 failed
INFO :: Received delete payload with protocol ISAKMP
INFO :: Deleting the IsakmpSA
--snipp--

is bei mir das erste mal das ich mit vpn rumfummel...
aber es ist schon recht eigenartig...;)

joa thx schonmal im vorraus..

Bin ich froh, daß ich nicht allein mit diesem dusseligen Problem darstehe. Besser wird es dadurch aber auch nicht (-;

Die Logs vom Netgear hat mein Kollege leider gelöscht, werde am Wochende nochmals einen Versuch starten. Merkwürdigerweise komme ich auf unserem Windows 2003 Server. Mit diesem funktioniert das Software VPN wunderbar.

Der Port 500 ist übrigens in der Firewall geöffnet gewesen, so wie ich vermutet hatte. Weiterhin sind 1701 und 1723 geöffnet. Alle Ports verstehen TCP/UDP.

Viele Grüße
Scatman

ich habs immernoch nicht hinbekommen.
wie sieht es bei euch aus?
also ich hab gelesen das es wohl daran liegt das der wizzard falsche eintraege macht und falsche keys generiert.
also soll die loesung heissen alles von hand schritt fuer schritt durch zu gehen..
ja wenn es jemand hinbekommen hat einfach mal bescheid sagen;)

cya

Auch hier leider keine guten Neuigkeiten (Netgear FVS 338 + Pro Safe Client).
Ich glaube aber nicht, das es an falsch erzeugten Keys liegt (hab das auch beim googlen gelesen) sondern eher, das evtl. irgendwelche routen nicht korrekt gesetzt werden o.ä.

Wenn ich nämlich z.B. im Pro Safe Client als "ID Type" direkt die IP-Adresse des VPN-Gateways angebe, bekomme ich keinerlei timeouts und das Handshake klappt perfekt. Dafür wird aber (natürlich) auch kein Paket für ein dahinterliegendes Netz weitergeleitet (wohin auch, die Ziel ID ist ja das Gateway selbst)

Ich bin hier langsam echt am verzweifeln. Was mich allerdings auch wundert ist, das Netgear dieses Problem in keiner FAQ behandelt, obwohl (lt. Google) in ca. 80% aller Problemfälle ein Netgear-Router beteiligt ist.

Any hint is highly appreciated...

Gruss
blafasel

jop das stimmt das mit den routen macht der netgear nicht so wirklich.
Also bei dem fvs318 ging es noch..
aber bei dem fvx538 routet der nichtmal zwischen 2 internen netzen ordentlich.
du kannst die routen aber alle per hand ueber das telnet interface eintrage..
is zwar nicht gerade das tollste.. wenn man schon nen nettes webinterface hat aber besser als nichts..
ich habe mich aber inzwischen entschieden intern ein openvpn auf zu setzen..
und siehe da so doof bin ich ja nicht..
nun klappt alles wunderbar..
ich forwarde das vpn zeuchs einfach auf eine interne linux kiste und gut ist!
tja ich bin leier sehr enttäuscht von dem ganzen netgear zeuchs.. da kauf ich mir lieber für 300? nen billigrechner der nicht wirklich viel leistung braucht 3 NIC's rein linux drauf und fertig ist die geschichte...
dauert zwar etwas länger bis es erstmal configuriert ist aber es ist mir lieber volle kontrolle zu haben als mich durch dieses webinterface zu klicken und dann funktioniert es eh nicht..
also mein fazit zu der ganzen geschichte:

'NETGEAR FVX538'--

tja.. schade.. aber nächstes mal kauf ich mir wirklich lieber nen rechner.. als nochmal netgear zeuchs!

MfG
t3c0

1. Im FVX538v2 der Policy name sollte klein geschrieben werden z.B. abacus
2. Im FVX538v2 > VPN > VPN Policies > ändere VPN Client policies und gebe ein im Remote VPN Endpoint: abacus.fvx_remote.com, statt fvx_remote.com (der Policy Name muss unbedingt angehängt werden)
3. Im ProSafe VPN Clientsoftware, der Name sollte sein abacus#.fvx_remote.com. Die Zahl könnte z.B. 1 sein (abacus1.fvx_remote.com). Aufgepasst: schreibe aber nicht abacus01.fvx_remote.com. Der Syntax erlaubt kein 0 (null).

Hallo,

ich hatte ein ähnliches Problem.
Netgear VPN Client zu Netgear FVS338 -> Abrruch der Verbindung nach kürzester Zeit mit den selben Meldungen im Log wie bei Dir:

Beim googlen habe ich folgendes gefunden
-> hat bei mir sofort!! geholfen. Achte darauf, daß ALLE Policies in der Benennung klein geschrieben sind, auch da gibt es einige Probleme....

Known Issues

Notes on VPN client policy changes in v1.6.40
Users are not added to the User Database automatically.
You must add VPN client users in the User Database menu whether or not XAUTH is to be used. In addition, each user entry must be assigned to a group named after the VPN policy. For example:
If the VPN client "boston15.fvs_remote.com" will be connecting, using the VPN policy "boston", then a User Database entry must be created for:

User Name: boston15
Password: (will be ignored unless XAUTH is enabled)
Group: boston
ModeConfig and XAUTH users must be assigned to DefaultGroup.
Due to these User Database menu modifications, we recommend starting from factory defaults. Alternatively, you may try the following steps after upgrading to avoid factory defaults configuration:
Delete all Client VPN policies.
Reboot the router.
Configure Client VPN policies.
You may need to toggle Daylight Savings Time setting after upgrade.
If you were having problems with reserved IP addresses in Groups and Hosts, you may need to perform a factory default reset after upgrading to the newer version.

ich hoffe das hilft

Peter

Firmware is seit Ende Juni 2006 v1.6.50. Die Version 2.xx.xx ist in Entwicklung (beta). Es wird meines Erachtens noch einige Zeit dauern bevor all Bugs raus sind.

hallo leute bin auch am verzweifeln,

bin auch im besitz das fvx538 mit der 2.3.17 FW der Netgear Client ist der 10.7.2 build12
das problem an der geschichte ist. die vpn geht nur wenn sie will. wenn der rechner neu gestartet wird geht sie manchmal und dann auch wieder nicht. es wurde an der config nix geändert.
die police ist über nen ike schlüssel und dem FQDN eingerichtet. arbeite am client und am fvx mit dyndns.

der log schmeißt mir folgendes raus. ich hoffe ihr könnt mir weiterhelfen. mfg digger

2007 Oct 21 21:31:55 [FVX538] [IKE] Remote configuration for identifier "xxx.homeip.net" found_
2007 Oct 21 21:31:55 [FVX538] [IKE] Policy Update to the kernel succeeded for xxx.homeip.net _
2007 Oct 21 21:31:55 [FVX538] [IKE] Received request for new phase 1 negotiation: 84.183.241.86[500]<=>89.57.81.65[500]_
2007 Oct 21 21:31:55 [FVX538] [IKE] Beginning Aggressive mode._
2007 Oct 21 21:31:55 [FVX538] [IKE] Received unknown Vendor ID_
- Last output repeated 2 times -
2007 Oct 21 21:31:55 [FVX538] [IKE] Received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt_
2007 Oct 21 21:31:55 [FVX538] [IKE] Received unknown Vendor ID_
2007 Oct 21 21:31:55 [FVX538] [IKE] Received Vendor ID: draft-ietf-ipsec-nat-t-ike-02__
2007 Oct 21 21:31:55 [FVX538] [IKE] For 89.57.81.65[500], Selected NAT-T version: draft-ietf-ipsec-nat-t-ike-02_
2007 Oct 21 21:31:56 [FVX538] [IKE] Floating ports for NAT-T with peer 89.57.81.65[4500]_
2007 Oct 21 21:31:56 [FVX538] [IKE] NAT-D payload matches for 84.183.241.86[4500]_
2007 Oct 21 21:31:56 [FVX538] [IKE] NAT-D payload does not match for 89.57.81.65[4500]_
2007 Oct 21 21:31:56 [FVX538] [IKE] Ignore REPLAY-STATUS notification from 89.57.81.65[4500]._
2007 Oct 21 21:31:56 [FVX538] [IKE] Ignore INITIAL-CONTACT notification from 89.57.81.65[4500] because it is only accepted after phase1._
2007 Oct 21 21:31:56 [FVX538] [IKE] NAT detected: Peer is behind a NAT device_
2007 Oct 21 21:31:56 [FVX538] [IKE] ISAKMP-SA established for 84.183.241.86[4500]-89.57.81.65[4500] with spi:a56b6e8755ef7587:1b87e3f38a36cbe4_
2007 Oct 21 21:31:56 [FVX538] [IKE] Sending Informational Exchange: notify payload[INITIAL-CONTACT]_
2007 Oct 21 21:31:56 [FVX538] [IKE] Responding to new phase 2 negotiation: 84.183.241.86<=>89.57.81.65_
2007 Oct 21 21:31:56 [FVX538] [IKE] Using IPsec SA configuration: 192.168.160.0/24<->192.168.161.1/24_
2007 Oct 21 21:31:56 [FVX538] [IKE] Adjusting peer's encmode 61443(61443)->Tunnel(1)_
2007 Oct 21 21:32:11 [FVX538] [IKE] The packet is retransmitted by 89.57.81.65[4500]._
- Last output repeated twice -
2007 Oct 21 21:32:26 [FVX538] [IKE] Giving up on 89.57.81.65 to set up IPsec-SA due to time up_
2007 Oct 21 21:32:26 [FVX538] [IKE] an undead schedule has been deleted: 'isakmp_ph2resend'._
2007 Oct 21 21:32:41 [FVX538] [IKE] The packet is retransmitted by 89.57.81.65[4500]._
2007 Oct 21 21:32:56 [FVX538] [IKE] Purged ISAKMP-SA with proto_id=ISAKMP and spi=a56b6e8755ef7587:1b87e3f38a36cbe4._
2007 Oct 21 21:32:57 [FVX538] [IKE] ISAKMP-SA deleted for 84.183.241.86[4500]-89.57.81.65[4500] with spi:a56b6e8755ef7587:1b87e3f38a36cbe4_

Frage Netzwerke Router, Routing

Heiß diskutiert