13
Problem mit VPN-Verbindung - IPSec und Shrew-Client
Hallo zusammen,
irgendwie komme ich bei meinem Problem nicht so recht weiter.
Am Standort A, zu dem eine VPN-Verbindung aufgebaut werden soll, steht ein Linksys WRV210 Router, IP 192.168.178.1 / Subnet 255.255.255.0, Dynamische WAN-IP / Dyndns.
Am Standort B steht ein WinXP Client, IP 172.20.10.133 / Subnet 255.255.0.0, ebenfalls dynamische WAN-IP, mit dem Shrew-VPN-Client möchte ich eine Verbindung aufbauen.
Soweit die kurze Zusammenfassung, hier die Router-VPN Einstellungen von Standort A:
Hier alle Client Einstellungen
Verbindungsaufbau:
attached to key daemon ...
peer configured
iskamp proposal configured
esp proposal configured
client configured
pre-shared key configured
bringing up tunnel ...
network device configured
tunnel enabled
Soweit so gut. Den Router 192.168.178.1 kann ich anpingen, jedoch keines der Geräte in dem Netzwerk von Standort A. Windows-Firewalls auf den PCs sind alle ausgeschaltet, Pass-Through auf dem Router aktiviert.
Woran kann das liegen? Habt ihr Ideen?
irgendwie komme ich bei meinem Problem nicht so recht weiter.
Am Standort A, zu dem eine VPN-Verbindung aufgebaut werden soll, steht ein Linksys WRV210 Router, IP 192.168.178.1 / Subnet 255.255.255.0, Dynamische WAN-IP / Dyndns.
Am Standort B steht ein WinXP Client, IP 172.20.10.133 / Subnet 255.255.0.0, ebenfalls dynamische WAN-IP, mit dem Shrew-VPN-Client möchte ich eine Verbindung aufbauen.
Soweit die kurze Zusammenfassung, hier die Router-VPN Einstellungen von Standort A:
Hier alle Client Einstellungen
Verbindungsaufbau:
attached to key daemon ...
peer configured
iskamp proposal configured
esp proposal configured
client configured
pre-shared key configured
bringing up tunnel ...
network device configured
tunnel enabled
Soweit so gut. Den Router 192.168.178.1 kann ich anpingen, jedoch keines der Geräte in dem Netzwerk von Standort A. Windows-Firewalls auf den PCs sind alle ausgeschaltet, Pass-Through auf dem Router aktiviert.
Woran kann das liegen? Habt ihr Ideen?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 126636
Url: https://administrator.de/forum/problem-mit-vpn-verbindung-ipsec-und-shrew-client-126636.html
Ausgedruckt am: 22.12.2024 um 17:12 Uhr
13 Kommentare
Neuester Kommentar
Hallo,
gibts es in deinem Router irgentwo sowas wie "entfernte Netze über Proxy-ARP einbinden"?
mfg corpse2001
gibts es in deinem Router irgentwo sowas wie "entfernte Netze über Proxy-ARP einbinden"?
mfg corpse2001
Hm... meinst Du sowas?
Das versteckt sich hinter dem Advanced-Button auf der IPSec Seite. Ansonsten kann ich noch statische Routen eintragen im Router.
das ist die Routingtabelle im Router
Destination LAN IP Subnet Mask Gateway Interface
217.0.118.103 255.255.255.255 0.0.0.0 WAN
192.168.178.0 255.255.255.0 0.0.0.0 LAN&Wireless
Default Route (*) 0.0.0.0 217.0.118.103 WAN
127.0.0.1 0.0.0.0 127.0.0.1 LOOPBACK
Das versteckt sich hinter dem Advanced-Button auf der IPSec Seite. Ansonsten kann ich noch statische Routen eintragen im Router.
das ist die Routingtabelle im Router
Destination LAN IP Subnet Mask Gateway Interface
217.0.118.103 255.255.255.255 0.0.0.0 WAN
192.168.178.0 255.255.255.0 0.0.0.0 LAN&Wireless
Default Route (*) 0.0.0.0 217.0.118.103 WAN
127.0.0.1 0.0.0.0 127.0.0.1 LOOPBACK
Haben die Rechner im 192.168.178.0er Netzwerk die du anpingen willst:
Erst wenn du diese 3 Dinge entsprechend geprüft hast sollte ein Ping auch problemlos funktionieren !!
- Den Default Gateway Eintrag auch auf den 192.168.178.1 er Router ?? (.178.0 sieht verdächtig nach einem Fritzbox Netz aus !!)
- ICMP aktiviert in der Firewall ?? (In den erweiterten Eigenschaften der Firewall den Haken bei ICMP und dort "Auf eingehende Echo Anforderungen antworten" gesetzt !)
- Ist die lokale Windows Firewall der zu pingenden Rechner entsprechend customized ?? Die Windows Firewall blockt normalerweise wenn du nichts machst alle Zugriffe die NICHT aus dem lokalen Netzwerk kommen, also folglich auch deinen VPN Ping ! Hier musst du die Windows Firewall entsprechend anpassen !!
Erst wenn du diese 3 Dinge entsprechend geprüft hast sollte ein Ping auch problemlos funktionieren !!
Zitat von @aqui:
Haben die Rechner im 192.168.178.0er Netzwerk die du anpingen willst:
Haben die Rechner im 192.168.178.0er Netzwerk die du anpingen willst:
- Den Default Gateway Eintrag auch auf den 192.168.178.1 er Router ??
Es ist ein ehemaliges Fritzbox-Netz, daher noch die typische IP Adresse. Aber die Fritzbox wurde jetzt eben durch den Linksys Router ersetzt.
Der Gateway-Eintrag ist gesetzt.
* ICMP aktiviert in der Firewall ?? (In den erweiterten Eigenschaften
der Firewall den Haken bei ICMP und dort "Auf eingehende Echo
Anforderungen antworten" gesetzt !)
der Firewall den Haken bei ICMP und dort "Auf eingehende Echo
Anforderungen antworten" gesetzt !)
Vielleicht bin ich blind, aber die Einstellung finde ich irgendwie nicht....
-Block Anonymous Internet Requests
-Block Multicast
habe ich beides deaktiviert. ich kann den router auch ohne vpn anpingen, kein problem. auch durch den vpn tunnel kann ich ihn über die lokale ip 192.168.178.1 anpingen. Nur das netzwerk dahinter halt nicht...
* Ist die lokale Windows Firewall der zu pingenden Rechner
entsprechend customized ?? Die Windows Firewall blockt normalerweise
wenn du nichts machst alle Zugriffe die NICHT aus dem lokalen
Netzwerk kommen, also folglich auch deinen VPN Ping ! Hier musst du
die Windows Firewall entsprechend anpassen !!
entsprechend customized ?? Die Windows Firewall blockt normalerweise
wenn du nichts machst alle Zugriffe die NICHT aus dem lokalen
Netzwerk kommen, also folglich auch deinen VPN Ping ! Hier musst du
die Windows Firewall entsprechend anpassen !!
Die XP Firewalls sind komplett deaktiviert.
.
"...ich kann den router auch ohne vpn anpingen, kein problem. " Das ist Unsinn und technisch gar nicht möglich, sofern du die 192.168.178.1 IP Adresse damit meinst !!!
Das ist ein RFC_1918 IP Netzwerk was im Internet NICHT geroutet und bei jedem Provider weggefiltert wird !
Wenn überhaupt, dann kannst du nur die WAN/DSL IP des Routers pingen, was man aber aus Sicherheitsgründen immer deaktivieren sollte im Betrieb später. Testweise ist es ok.
ICMP (Ping) aktiviert man unter den erweiterten Eigenschaften der LAN Verbindung -> Einstellung (Firewall) -> Erweitert -> Einstellung (ICMP) !
Hier den Haken bei "Eingehende Echoanforderungen zulassen" setzen.
Wer suchet der findet... !!
"...ich kann den router auch ohne vpn anpingen, kein problem. " Das ist Unsinn und technisch gar nicht möglich, sofern du die 192.168.178.1 IP Adresse damit meinst !!!
Das ist ein RFC_1918 IP Netzwerk was im Internet NICHT geroutet und bei jedem Provider weggefiltert wird !
Wenn überhaupt, dann kannst du nur die WAN/DSL IP des Routers pingen, was man aber aus Sicherheitsgründen immer deaktivieren sollte im Betrieb später. Testweise ist es ok.
ICMP (Ping) aktiviert man unter den erweiterten Eigenschaften der LAN Verbindung -> Einstellung (Firewall) -> Erweitert -> Einstellung (ICMP) !
Hier den Haken bei "Eingehende Echoanforderungen zulassen" setzen.
Wer suchet der findet... !!
Sorry, hatte mich ungenau ausgedrückt. Gemeint war, dass ich (ohne aktive VPN Verbindung) den Router über die WAN IP anpingen kann (zu Testzwecken) . Bei aktiver VPN Verbindung funktioniert ping 192.168.178.1 auch problemlos. Aber die Client-PCs oder das NAS-System kann ich nicht anpingen. Auch aufs Webinterface vom NAS komme ich nicht.
Die ICMP Einstellungen ist bei allen Clients aktiviert. Daran liegt es also auch nicht...
Die ICMP Einstellungen ist bei allen Clients aktiviert. Daran liegt es also auch nicht...
Hat das NAS sicher einen default Gateway Eintrag auf die 192.168.178.1 ???
Das NAS sollte immer einen statischen IP und gateway Eintrag haben keinen per DHCP !
Ansonste wäre das Verhalten nicht zu erklären ??
Was sagt denn ein Traceroute (tracert) oder pathping auf die IP des NAS von remote ??
Das NAS sollte immer einen statischen IP und gateway Eintrag haben keinen per DHCP !
Ansonste wäre das Verhalten nicht zu erklären ??
Was sagt denn ein Traceroute (tracert) oder pathping auf die IP des NAS von remote ??
Ich habe es gerade noch mal kontrolliert - NAS hat als Gateway die 192.168.178.1 eingetragen und hat natürlich eine statische IP...
IP der NAS 192.168.178.19
IP des VPN Clients im Remote-Netzwerk 192.168.178.45
Routenverfolgung zu 192.168.178.19 über maximal 30 Abschnitte
0 ms-vm-05 [192.168.178.45]
1 * * *
Berechnung der Statistiken dauert ca. 25 Sekunden...
Quelle zum Abs. Knoten/Verbindung
Abs. Zeit Verl./Ges.= % Verl./Ges.= % Adresse
0 ms-vm-05 [192.168.178.45]
100/ 100 =100% |
1 --- 100/ 100 =100% 0/ 100 = 0% ms-vm-05 [0.0.0.0]
Ablaufverfolgung beendet.
Beim tracert zur NAS (192.168.178.19) sieht man nur " 1 * * * Zeitüberschreitung der Anforderung." über alle 30 Abschnitte.
Als vergleich pathping und tracert zum Router 192.168.178.1
Routenverfolgung zu 192.168.178.1 über maximal 30 Abschnitte
1 96 ms 101 ms 97 ms 192.168.178.1
Ablaufverfolgung beendet.
Routenverfolgung zu 192.168.178.1 über maximal 30 Abschnitte
0 ms-vm-05 [192.168.178.45]
1 192.168.178.1
Berechnung der Statistiken dauert ca. 25 Sekunden...
Quelle zum Abs. Knoten/Verbindung
Abs. Zeit Verl./Ges.= % Verl./Ges.= % Adresse
0 ms-vm-05 [192.168.178.45]
0/ 100 = 0% |
1 95ms 0/ 100 = 0% 0/ 100 = 0% 192.168.178.1
Ablaufverfolgung beendet.
IP der NAS 192.168.178.19
IP des VPN Clients im Remote-Netzwerk 192.168.178.45
pathping 192.168.178.19
Routenverfolgung zu 192.168.178.19 über maximal 30 Abschnitte
0 ms-vm-05 [192.168.178.45]
1 * * *
Berechnung der Statistiken dauert ca. 25 Sekunden...
Quelle zum Abs. Knoten/Verbindung
Abs. Zeit Verl./Ges.= % Verl./Ges.= % Adresse
0 ms-vm-05 [192.168.178.45]
100/ 100 =100% |
1 --- 100/ 100 =100% 0/ 100 = 0% ms-vm-05 [0.0.0.0]
Ablaufverfolgung beendet.
Beim tracert zur NAS (192.168.178.19) sieht man nur " 1 * * * Zeitüberschreitung der Anforderung." über alle 30 Abschnitte.
Als vergleich pathping und tracert zum Router 192.168.178.1
tracert 192.168.178.1
Routenverfolgung zu 192.168.178.1 über maximal 30 Abschnitte
1 96 ms 101 ms 97 ms 192.168.178.1
Ablaufverfolgung beendet.
pathping 192.168.178.1
Routenverfolgung zu 192.168.178.1 über maximal 30 Abschnitte
0 ms-vm-05 [192.168.178.45]
1 192.168.178.1
Berechnung der Statistiken dauert ca. 25 Sekunden...
Quelle zum Abs. Knoten/Verbindung
Abs. Zeit Verl./Ges.= % Verl./Ges.= % Adresse
0 ms-vm-05 [192.168.178.45]
0/ 100 = 0% |
1 95ms 0/ 100 = 0% 0/ 100 = 0% 192.168.178.1
Ablaufverfolgung beendet.
Das ist in der Tat verwunderlich ! Interessant wäre nochmal ein route print vom VPN Client bei aktiviertem VPN.
Du solltest mal einen Sniffer an den WRV LAN Port hängen und checken ob die Pakete vom VPN Client überhaupt vom Router an das NAS geforwardet werden.
Alternativ ist es einfacher statt des NAS einen PC im Netz zu nehmen und den Sniffer darauf laufen zu lassen und dann diesen PC anzupingen ob hier überhaupt ICMP Pakete ankommen ??
Es ist auch möglich das der VPN Tunnel nicht sauber aufgebaut ist.
Bekommst du vom WRV irgendwelche Logs bzw. Logeinträge beim VPN Aufbau ??
Du solltest mal einen Sniffer an den WRV LAN Port hängen und checken ob die Pakete vom VPN Client überhaupt vom Router an das NAS geforwardet werden.
Alternativ ist es einfacher statt des NAS einen PC im Netz zu nehmen und den Sniffer darauf laufen zu lassen und dann diesen PC anzupingen ob hier überhaupt ICMP Pakete ankommen ??
Es ist auch möglich das der VPN Tunnel nicht sauber aufgebaut ist.
Bekommst du vom WRV irgendwelche Logs bzw. Logeinträge beim VPN Aufbau ??
Das Ergebnis von route print als Grafik, damit man das noch vernünftig lesen kann:
Die Theorie, dass die Pakete garnicht am LAN Port ankommen, scheint mir recht plausibel. prüfen kann ich das leider erst in ca. einer Woche, wenn ich wieder an die Rechner dran komme.
Mit dem Linksys Quick VPN Tool funktioniert das ganze übrigens einwandfrei, aber der Client läuft ja nicht unter 64bit Systemen... daher dieser Weg.
Der WRV Router hat leider nur ein sehr abgespecktes Konfigurationsmenü, Log-Einträge kann man nur mit einem externen Viewer aufzeichnen. Auch diese Infos kann ich erst in ca. einer Woche liefern...
Ist es denkbar, dass die Probleme mit Shrew dadurch entstehen, dass ich für solche Fernwartungsaufgaben eine virtuelle Maschine nutze? (Netzwerkkarte im Bridge-Modus, virtualisiert mit Vmware-Server 2). Das könnte ich morgen mal noch auf einem WinXP x64 Rechner testen. Mit PPTP-VPNs und eben dem Linksys Tool läuft aber alles prima...
Die Theorie, dass die Pakete garnicht am LAN Port ankommen, scheint mir recht plausibel. prüfen kann ich das leider erst in ca. einer Woche, wenn ich wieder an die Rechner dran komme.
Mit dem Linksys Quick VPN Tool funktioniert das ganze übrigens einwandfrei, aber der Client läuft ja nicht unter 64bit Systemen... daher dieser Weg.
Der WRV Router hat leider nur ein sehr abgespecktes Konfigurationsmenü, Log-Einträge kann man nur mit einem externen Viewer aufzeichnen. Auch diese Infos kann ich erst in ca. einer Woche liefern...
Ist es denkbar, dass die Probleme mit Shrew dadurch entstehen, dass ich für solche Fernwartungsaufgaben eine virtuelle Maschine nutze? (Netzwerkkarte im Bridge-Modus, virtualisiert mit Vmware-Server 2). Das könnte ich morgen mal noch auf einem WinXP x64 Rechner testen. Mit PPTP-VPNs und eben dem Linksys Tool läuft aber alles prima...
Nein, eine Bridge stört nicht, denn da wird im Layer 3 nichts beeinflusst. Schlimmer wäre es wenn du NAT machen würdest in der VM. Da das aber nicht der Fall ist ist das kein Thema !
Was höchstens sein kann ist das sich 2 VPN Clients stören sofern du beide auf einer Maschine installiert hast. Es ist also immer besser eine komplett zu deinstallieren und nur mit einer Client SW zur Zeit zu testen.
Hast du mal etwas mit den Verschlüsselungs Algorhytmen rumgetestet ?? Ältere Linlsys VPN Systeme supporten nur DES und 3DES. Der Client darf also kein AES oder sowas machen.
Es hilft nix, ohne Logs kommt man schwer weiter.....
Installier den Kiwi Syslog und schreib alles mit..dannshen wir in einer Woche mal weiter !
Was höchstens sein kann ist das sich 2 VPN Clients stören sofern du beide auf einer Maschine installiert hast. Es ist also immer besser eine komplett zu deinstallieren und nur mit einer Client SW zur Zeit zu testen.
Hast du mal etwas mit den Verschlüsselungs Algorhytmen rumgetestet ?? Ältere Linlsys VPN Systeme supporten nur DES und 3DES. Der Client darf also kein AES oder sowas machen.
Es hilft nix, ohne Logs kommt man schwer weiter.....
Installier den Kiwi Syslog und schreib alles mit..dannshen wir in einer Woche mal weiter !
Andere Verschlüsselungsverfahren habe ich probiert, in zig verschiedenen Kombinationen...
Hatte gerade doch kurz die Möglichkeit, auf den Rechner zuzugreifen. Kiwi zeigt im Zeitraum des Aufbaus der VPN Verbindung und auch bei Ping Befehlen keine Informationen an.
Dann habe ich Wireshark mal installiert und geschaut, ob die ping-Befehle auch ankommen - scheint so!
die 192.168.178.19 hat das NAS, 100 der Client (lokal), 45 ist im VPN Client hinterlegt.
Hatte gerade doch kurz die Möglichkeit, auf den Rechner zuzugreifen. Kiwi zeigt im Zeitraum des Aufbaus der VPN Verbindung und auch bei Ping Befehlen keine Informationen an.
Dann habe ich Wireshark mal installiert und geschaut, ob die ping-Befehle auch ankommen - scheint so!
die 192.168.178.19 hat das NAS, 100 der Client (lokal), 45 ist im VPN Client hinterlegt.
Nein scheinbar nicht... denn die .45 pingt die .100 (ICMP request) es kommt aber keinerlei Antwort (ICMP echo reply) von der .100 zurück !!
Das zeigt wenigstens dein o.a. Sniffer Trace !
Das zeigt wenigstens dein o.a. Sniffer Trace !
