8
Netgear FVS114 und Shrewsoft Verbindung ja, Ping jain
Die Verbindung steht, aber dann ... vielleicht hat hier ja jemand einen Tipp.
Hallo zusammen,
ich hab mittlerweile fast alles durchgesucht, aber ich habe das passende einfach noch nicht gefunden. Also ich möchte gerne aus meinem eigenen Netzwerk (192.168.1.0) über eine VPN-Verbindung die ich mit Shrewsoft und einem Netgear FVS114 herstelle auf ein anderes Netzwerk (192.168.2.0) zugreifen.
Die VPN-Verbindung baut sich auch auf, so zumindest sagt es der Shrewsoft-Client erstmal. Wenn ich aber einen Ping auf einen Rechner im anderen Netz (192.168.2.250) absetzen will, führt das zu einer Zeitüberschreitung. Auch ein Ping auf den Netgear (hat die 192.168.2.2) führt zur Zeitüberschreitung. Ich habe dann mal den Netzwerkdrucker (192.168.2.200) im anderen Netz angepingt. Und siehe da, es kam eine Antwort. Das klappt allerdings auch nicht immer, und wenn es funktioniert, dann ist es auch nur der Drucker, bei dem ich eine Antwort auf den Ping erhalte. Die Namensauflösung scheint aber immer ohne Probleme zu funktionieren. Probiere ich einen tracert auf den anderen Rechner oder den Drucker, gibt er auch den Namen an.
Ich habe so das dumpfe Gefühl, dass irgendetwas mit der Route nicht so ganz hinhaut.
Vielleicht kann mir ja hier jemand noch weiterhelfen. Wenn Ihr weitere Information dafür braucht, sagt mir einfach, was ich hier noch posten soll.
Vielen Dank schon mal im vorraus.
Mark
ich hab mittlerweile fast alles durchgesucht, aber ich habe das passende einfach noch nicht gefunden. Also ich möchte gerne aus meinem eigenen Netzwerk (192.168.1.0) über eine VPN-Verbindung die ich mit Shrewsoft und einem Netgear FVS114 herstelle auf ein anderes Netzwerk (192.168.2.0) zugreifen.
Die VPN-Verbindung baut sich auch auf, so zumindest sagt es der Shrewsoft-Client erstmal. Wenn ich aber einen Ping auf einen Rechner im anderen Netz (192.168.2.250) absetzen will, führt das zu einer Zeitüberschreitung. Auch ein Ping auf den Netgear (hat die 192.168.2.2) führt zur Zeitüberschreitung. Ich habe dann mal den Netzwerkdrucker (192.168.2.200) im anderen Netz angepingt. Und siehe da, es kam eine Antwort. Das klappt allerdings auch nicht immer, und wenn es funktioniert, dann ist es auch nur der Drucker, bei dem ich eine Antwort auf den Ping erhalte. Die Namensauflösung scheint aber immer ohne Probleme zu funktionieren. Probiere ich einen tracert auf den anderen Rechner oder den Drucker, gibt er auch den Namen an.
Ich habe so das dumpfe Gefühl, dass irgendetwas mit der Route nicht so ganz hinhaut.
Vielleicht kann mir ja hier jemand noch weiterhelfen. Wenn Ihr weitere Information dafür braucht, sagt mir einfach, was ich hier noch posten soll.
Vielen Dank schon mal im vorraus.
Mark
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: 116655
Url: https://administrator.de/contentid/116655
Printed on: April 16, 2024 at 22:04 o'clock
8 Comments
Latest comment
Leider ist die Beschreibung deiner Topologie etwas oberflächlich 
Insbesondere dies:
Das solltest du erstmal klären bevor man ins Eingemachte geht !!
Insbesondere dies:
- Wo wählt sich der Client ein ?? Ist das ein IPsec Router direkt mit einer öffentlichen IP oder ein IOPsec VPN Server hinter einem NAT Router ?
- Ist der Client ebenfalls hinter einem NAT Router oder nicht ?
- Befinden sich VPN Client und Server hinter einem NAT Router hast du dann entsprechend die Ports in der Weiterleitung eingetragen ?? (UDP 500, UDP 4500 und ESP Protokoll ) ???
Das solltest du erstmal klären bevor man ins Eingemachte geht !!
Also der Client wählt sich direkt auf dem Router (FVS114) ein. Auf Grund einer wechselnden IP habe ich bei dyndns einen Account eingerichtet. Ich verbinde mich also mit der Adresse xxx.dyndns.org:500.
Der Client sitzt hinter einem NAT Router, ich habe ihn aber zu Testzwecken erstmal in die DMZ geschoben.
Auf dem Router, auf dem ich mich einwähle, habe ich folgende Ports auf die IP des Routers geleitet:
500 UDP
4500 UDP
47 TCP/UDP
50 TCP/UDP
51 TCP/UDP
Der Client sitzt hinter einem NAT Router, ich habe ihn aber zu Testzwecken erstmal in die DMZ geschoben.
Auf dem Router, auf dem ich mich einwähle, habe ich folgende Ports auf die IP des Routers geleitet:
500 UDP
4500 UDP
47 TCP/UDP
50 TCP/UDP
51 TCP/UDP
Die 3 Ports 47, 50 und 51 ist kompletter Unsinn, denn das kannst du selber sehen mit einer schnellen Google Abfrage das die mit IPsec VPN rein gar ncihts zu tun haben:
ni-ftp 47/tcp NI FTP
ni-ftp 47/udp NI FTP
re-mail-ck 50/tcp Remote Mail Checking Protocol
re-mail-ck 50/udp Remote Mail Checking Protocol
la-maint 51/tcp IMP Logical Address Maintenance
la-maint 51/udp IMP Logical Address Maintenance
Die kannst du also besser gleich wieder löschen !!
Shrewsoft nutzt IPsec im ESP Modus und das benutzt die Ports
IKE, UDP 500
Nat Traversal, UDP 4500
ESP Protokoll mit der IP Protokollnummer 50
(Achtung nicht TCP oder UDP 50 ESP ist ein eigenständiges IP Protokoll !!)
Diese musst du also auf beiden Enden in der Port Weiterleitung auf die interne IP Adresse vom Client weitergeben.
Beim NetGear musst du nichts machen, denn da ist kein NAT vorhanden du wählst dich direkt auf die öffentliche IP ein !!
Dein Clientaufruf xxx.dyndns.org:500 ist natürlich Blödsinn, denn damit würdest du einen Port 500 erzwingen was bei IPsec gar nicht möglich ist da das festgelegt Ports hat.
Im VPN Client steht also einzig und allein xxx.dyndns.org nicht mehr !!!
Der NetGear hat doch sicher ein Log oder einen optinalen Syslog ?!
Was gibt der denn als Systemmeldung raus wenn ein eingehender IPsec Connect Versuch vom Client kommt ??
Weitere Infos zum Thema IPsec und ESP findest du hier:
IPSEC Protokoll - Einsatz, Aufbau, benötigte Ports und Begriffserläuterungen
Ein Blick in das NetGear HowTo von Shrewsoft solltest du auch riskieren !!!
http://www.shrew.net/support/wiki/HowtoNetgear
...und das dein NetGear die neueste Firmware intus haben sollte sollte dir auch klar sein !!
http://www.netgear.de/de/Support/download.html?func=Detail&id=12268
ni-ftp 47/tcp NI FTP
ni-ftp 47/udp NI FTP
re-mail-ck 50/tcp Remote Mail Checking Protocol
re-mail-ck 50/udp Remote Mail Checking Protocol
la-maint 51/tcp IMP Logical Address Maintenance
la-maint 51/udp IMP Logical Address Maintenance
Die kannst du also besser gleich wieder löschen !!
Shrewsoft nutzt IPsec im ESP Modus und das benutzt die Ports
IKE, UDP 500
Nat Traversal, UDP 4500
ESP Protokoll mit der IP Protokollnummer 50
(Achtung nicht TCP oder UDP 50 ESP ist ein eigenständiges IP Protokoll !!)
Diese musst du also auf beiden Enden in der Port Weiterleitung auf die interne IP Adresse vom Client weitergeben.
Beim NetGear musst du nichts machen, denn da ist kein NAT vorhanden du wählst dich direkt auf die öffentliche IP ein !!
Dein Clientaufruf xxx.dyndns.org:500 ist natürlich Blödsinn, denn damit würdest du einen Port 500 erzwingen was bei IPsec gar nicht möglich ist da das festgelegt Ports hat.
Im VPN Client steht also einzig und allein xxx.dyndns.org nicht mehr !!!
Der NetGear hat doch sicher ein Log oder einen optinalen Syslog ?!
Was gibt der denn als Systemmeldung raus wenn ein eingehender IPsec Connect Versuch vom Client kommt ??
Weitere Infos zum Thema IPsec und ESP findest du hier:
IPSEC Protokoll - Einsatz, Aufbau, benötigte Ports und Begriffserläuterungen
Ein Blick in das NetGear HowTo von Shrewsoft solltest du auch riskieren !!!
http://www.shrew.net/support/wiki/HowtoNetgear
...und das dein NetGear die neueste Firmware intus haben sollte sollte dir auch klar sein !!
http://www.netgear.de/de/Support/download.html?func=Detail&id=12268
Danke schon einmal für Deine Hilfe.
Also ich habe die von Dir genannten Ports 47,50 und 51 rausgeworfen. Die Firmware ist natürlich auf dem neuesten Stand.
Die Anleitung von Shrewsoft habe ich mir natürlich angeguckt. Leider passt das nicht so auf meinen Router. Ich habe wohl ein kleineres Modell mit einem anderen Menü, da gleicht sich leider nichts.
Für die Einrichtung des Clients hab ich mich mal daran orientiert: http://blog.edv-helferlein.de/2009/01/21/shrewsoft-netgear-fvs338-vpn-v ...
Hier auch nochmal das VPN-Log vom Netgear:
[2009-05-24 20:30:24][==== IKE PHASE 1(from xxx.xxx.179.147) START (responder) ====]
[2009-05-24 20:30:24] RECEIVED FIRST MESSAGE OF AGGR MODE
[2009-05-24 20:30:24]<POLICY: > PAYLOADS: SA,PROP,TRANS,KE,NONCE,ID,VID,VID,VID,VID,VID,VID,VID,VID,VID,VID,VID
[2009-05-24 20:30:24]<LocalRID> Type=ID_FQDN,ID Data=fvs_remote
[2009-05-24 20:30:24]<RemoteLID> Type=ID_FQDN,ID Data=fvs_remote
[2009-05-24 20:30:24]<POLICY: KS> PAYLOADS: SA,PROP,TRANS,KE,NONCE,ID,HASH
[2009-05-24 20:30:24] SENT OUT SECOND MESSAGE OF AGGR MODE
[2009-05-24 20:30:24] RECEIVED THIRD MESSAGE OF AGGR MODE
[2009-05-24 20:30:24]<POLICY: KS> PAYLOADS: HASH
[2009-05-24 20:30:24] AGGR MODE COMPLETED
[2009-05-24 20:30:24][==== IKE PHASE 1 ESTABLISHED====]
[2009-05-24 20:30:29][==== IKE PHASE 2(from xxx.xxx.179.147) START (responder) ====]
[2009-05-24 20:30:29] RECEIVED FIRST MESSAGE OF QUICK MODE
[2009-05-24 20:30:29] FOUND IDs,EXTRACE ID INFO
[2009-05-24 20:30:29]<Initiator IPADDR=192.168.2.32>
[2009-05-24 20:30:29]<Responder IPADDR=192.168.2.0 MASK=255.255.255.0>
[2009-05-24 20:30:29] SENT OUT SECOND MESSAGE OF QUICK MODE
[2009-05-24 20:30:29] RECEIVED THIRD MESSAGE OF QUICK MODE
[2009-05-24 20:30:29]<POLICY: KS> PAYLOADS: HASH
[2009-05-24 20:30:29] QUICK MODE COMPLETED
[2009-05-24 20:30:29][==== IKE PHASE 2 ESTABLISHED====]
Also für mich sieht das aus, als würde die Verbindung ja prinzipiell stehen, oder? Ich meine, ab und an antwortet mir ja auch der Netzwerkdrucker auf einen ping.
Also bei mir im Router daheim habe ich die Ports auf die IP von meinem Rechner umgeleitet. Aber auf dem VPN-Router muss ich das doch wohl nicht machen, oder?
Also ich habe die von Dir genannten Ports 47,50 und 51 rausgeworfen. Die Firmware ist natürlich auf dem neuesten Stand.
Die Anleitung von Shrewsoft habe ich mir natürlich angeguckt. Leider passt das nicht so auf meinen Router. Ich habe wohl ein kleineres Modell mit einem anderen Menü, da gleicht sich leider nichts.
Für die Einrichtung des Clients hab ich mich mal daran orientiert: http://blog.edv-helferlein.de/2009/01/21/shrewsoft-netgear-fvs338-vpn-v ...
Hier auch nochmal das VPN-Log vom Netgear:
[2009-05-24 20:30:24][==== IKE PHASE 1(from xxx.xxx.179.147) START (responder) ====]
[2009-05-24 20:30:24] RECEIVED FIRST MESSAGE OF AGGR MODE
[2009-05-24 20:30:24]<POLICY: > PAYLOADS: SA,PROP,TRANS,KE,NONCE,ID,VID,VID,VID,VID,VID,VID,VID,VID,VID,VID,VID
[2009-05-24 20:30:24]<LocalRID> Type=ID_FQDN,ID Data=fvs_remote
[2009-05-24 20:30:24]<RemoteLID> Type=ID_FQDN,ID Data=fvs_remote
[2009-05-24 20:30:24]<POLICY: KS> PAYLOADS: SA,PROP,TRANS,KE,NONCE,ID,HASH
[2009-05-24 20:30:24] SENT OUT SECOND MESSAGE OF AGGR MODE
[2009-05-24 20:30:24] RECEIVED THIRD MESSAGE OF AGGR MODE
[2009-05-24 20:30:24]<POLICY: KS> PAYLOADS: HASH
[2009-05-24 20:30:24] AGGR MODE COMPLETED
[2009-05-24 20:30:24][==== IKE PHASE 1 ESTABLISHED====]
[2009-05-24 20:30:29][==== IKE PHASE 2(from xxx.xxx.179.147) START (responder) ====]
[2009-05-24 20:30:29] RECEIVED FIRST MESSAGE OF QUICK MODE
[2009-05-24 20:30:29] FOUND IDs,EXTRACE ID INFO
[2009-05-24 20:30:29]<Initiator IPADDR=192.168.2.32>
[2009-05-24 20:30:29]<Responder IPADDR=192.168.2.0 MASK=255.255.255.0>
[2009-05-24 20:30:29] SENT OUT SECOND MESSAGE OF QUICK MODE
[2009-05-24 20:30:29] RECEIVED THIRD MESSAGE OF QUICK MODE
[2009-05-24 20:30:29]<POLICY: KS> PAYLOADS: HASH
[2009-05-24 20:30:29] QUICK MODE COMPLETED
[2009-05-24 20:30:29][==== IKE PHASE 2 ESTABLISHED====]
Also für mich sieht das aus, als würde die Verbindung ja prinzipiell stehen, oder? Ich meine, ab und an antwortet mir ja auch der Netzwerkdrucker auf einen ping.
Diese musst du also auf beiden Enden in der Port Weiterleitung auf die interne IP Adresse vom Client weitergeben.
Also bei mir im Router daheim habe ich die Ports auf die IP von meinem Rechner umgeleitet. Aber auf dem VPN-Router muss ich das doch wohl nicht machen, oder?
Ja, das sieht sauber aus !! Die IPsec Session kommt sauber zustande !
Vermutlich ist der intermittierende Fehler nun ein MTU Problem da du 2 mal encapsulierst (VPN und DSL mit PPPoE).
Billige Router wie die von NetGear haben das Problem das sie kein MTU Path discovery machen und wenn die primäre MTU zu klein ist auf dem DSL Inteface dann kann die max. Framesize überschritten werden und solche Pakete werden gedropt.
Das erklärt das mal gehts und mal gehts nicht. Warum das so ist steht z.B. hier:
http://www.cisco.com/en/US/tech/tk175/tk15/technologies_tech_note09186a ...
Vermutlich fixt du das problem wenn du die MTU auf dem DSL Interface des NetGear einfach einmal auf 1440 oder kleiner stellst !
Vermutlich ist der intermittierende Fehler nun ein MTU Problem da du 2 mal encapsulierst (VPN und DSL mit PPPoE).
Billige Router wie die von NetGear haben das Problem das sie kein MTU Path discovery machen und wenn die primäre MTU zu klein ist auf dem DSL Inteface dann kann die max. Framesize überschritten werden und solche Pakete werden gedropt.
Das erklärt das mal gehts und mal gehts nicht. Warum das so ist steht z.B. hier:
http://www.cisco.com/en/US/tech/tk175/tk15/technologies_tech_note09186a ...
Vermutlich fixt du das problem wenn du die MTU auf dem DSL Interface des NetGear einfach einmal auf 1440 oder kleiner stellst !
Hallo!
Entschuldige, dass ich so lange nicht geantwortet habe, aber ich war leider viel unterwegs. Also ich habe mal auf dem Netgear, wo ich mich ja einwähle, die MTU auf 1440 gesetzt. Dann allerdings kommt gar keine VPN-Verbindung mehr zu Stande. Das Signal kommt dann anscheinend gar nicht mehr an, denn die Logfiles zeigen auch nicht an, dass da ein Einwahlversuch stattfindet.
Ich nutze allerdings einen Telekomrouter als Modem. Muss ich da die MTU auch entsprechend verändern?
Entschuldige, dass ich so lange nicht geantwortet habe, aber ich war leider viel unterwegs. Also ich habe mal auf dem Netgear, wo ich mich ja einwähle, die MTU auf 1440 gesetzt. Dann allerdings kommt gar keine VPN-Verbindung mehr zu Stande. Das Signal kommt dann anscheinend gar nicht mehr an, denn die Logfiles zeigen auch nicht an, dass da ein Einwahlversuch stattfindet.
Ich nutze allerdings einen Telekomrouter als Modem. Muss ich da die MTU auch entsprechend verändern?
Nein, ein Modem hat mit der IP MTU Patch Discovery nichts zu tun, das ist nur noch ein Medienwandler !
Das gilt aber NUR wenn du das Modem auch WIRKLICH als Modem betreibst (VPN Passthrough) und nicht noch als Router davorgeschaltet hast !!!
Das bei 1440 gar nichts ankommt ist höchst ungewöhnlich ! Den VPN Connect Versuch musst du in jedem Falle sehen im Log !!!
Da stimmt vermutlich generell was nicht ??!!
Das gilt aber NUR wenn du das Modem auch WIRKLICH als Modem betreibst (VPN Passthrough) und nicht noch als Router davorgeschaltet hast !!!
Das bei 1440 gar nichts ankommt ist höchst ungewöhnlich ! Den VPN Connect Versuch musst du in jedem Falle sehen im Log !!!
Da stimmt vermutlich generell was nicht ??!!
Ja, der Router läuft nur als Modem. Ich habe gerade noch einmal kontrolliert, ob der Haken bei VPN Passthrough gesetzt ist. Ich habe jetzt einfach alle Geräte noch einmal neu gestartet und probiere es heute Abend noch einmal aus. Aber beim letzten Mal, kam bei einer MTU von 1440 tatsächlich gar nichts an. Ich habe auch nicht schlecht gestaunt, als in den Routerlogs nichts auftauchte. Aber ich versuche es nochmal. Vielleicht lag es an diesem Abend ja auch an etwas anderem.
