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
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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 116655
Url: https://administrator.de/forum/netgear-fvs114-und-shrewsoft-verbindung-ja-ping-jain-116655.html
Ausgedruckt am: 29.04.2025 um 07:04 Uhr
8 Kommentare
Neuester Kommentar
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 !!
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
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 !
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 ??!!