Veröffentlicht 29. März 201411 j Mahlzeit, ich habe gerade bei einem Kunden einen Linksys RV042 IP-adressenmäßig umgestellt. Dieser hatte vorher intern eine öffentliche IP-Adresse (200.1.4.152) mit Class C-Subnetzmaske (nicht fragen, deswegen haben wir ja umgestellt...), jetzt besitzt der intern eine private IP-Adresse (192.168.216.1). Extern hat sich nichts geändert. Dieser Router steht in einer Außenstelle des Kunden, die per IPsec Site-to-Site-VPN an den Hauptstandort angebunden ist (Subnetz: 192.168.214.0/24). Die VPN-Verbindung funktioniert auch wunderbar, man kann vom Hauptstandort die interne IP-Adresse des RV042 anpingen. Jetzt kommt aber die Merkwürdigkeit: die Geräte hinter dem RV042 können nicht erreicht werden (weder per Ping noch über das Webinterface z.B. eines Druckers), ebenso kommen die nicht ins Internet oder können auf Geräte im Hauptstandort zugreifen. Die beiden Router, die das IPsec-VPN aufbauen, besitzen keine Filtermöglichkeiten, d.h. jeglicher Verkehr vom einen ins andere Subnetz wird durchgelassen. Man kann sich die Routingtabellen anzeigen lassen, die sind genauso aufgebaut wie die unseres eigenen RV042, der funktionert. Auszug: Destination IP Subnet Mask Default Gateway Hop Count Interface 192.168.214.0 255.255.255.0 (ext. IP Hauptstandort) 10 ipsec1 192.168.216.0 255.255.255.0 * 50 ixp0 ixp0 ist das interne Interface, der DHCP-Server im Router verteilt auch fleißig IP-Adressen in der richtigen Range (192.168.216.x) mit dem richtigen Gateway an die beiden PCs, die angeschlossen sind. Im RV042 gibt es die Möglichkeit, einen Ping auf benutzerdefinierte Ziele zu setzen - externe IP-Adressen sowie IP-Adressen aus dem Subnetz des Hauptstandortes funktionieren wunderbar, die internen Geräte aber nicht, selbst die, bei denen der Router selbst die IP-Adressen per DHCP verteilt hat. In meiner Verzweiflung habe ich auch die Firmware von der 1.3.2.6 auf die 1.3.2.19 aktualisiert, die auf unserem internen Router problemlos funktioniert. Ich hatte gedacht, dass evtl. noch alte Routingtabelleneinträge dadurch ebenfalls gelöscht würden, aber wie es aussieht war das nicht das Problem. Neu gestartet wurde der Router natürlich auch schon öfter, das letzte Mal eben nach dem Firmware-Update. Hat irgendjemand da noch eine Idee, die mich davor retten würde, am Montag nach Sylt zu fahren? Bearbeitet 29. März 201411 j von Eye-Q
30. März 201411 j Könnten evtl Filterregeln, die zwischen dem ixp0 und ipsec1 Interface greifen existieren? Existieren entsprechende Routing-Regeln zwischen den beiden Netzen? So wie ich Dich ja verstehe kann der umkonfigurierte Router sowohl über das VPN Interface mit dem Hauptstandort kommunizieren, sowie der Hauptstandort mit dem Router, nur die Geräte die hinter dem Router liegen können nicht kommunizieren.
30. März 201411 j Autor Das Problem ist ja, dass noch nicht mal die interne Diagnose-Funktion des RV042 im Außenstandort die dort angeschlossenen (und eingeschalteten) Geräte pingen kann, Firewalls sind natürlich deaktiviert. Deswegen sehe ich da keine Filterregeln zwischen ixp0 und ipsec1, die ein Problem darstellen.
31. März 201411 j Autor Das Problem hat sich anderweitig erledigt: da ein neuer Router günstiger kommt als wenn ich da noch Stunden in die Fehlersuche investiere, habe ich jetzt einen neuen Router konfiguriert, der heute in die Außenstelle geschickt wird... Trotzdem danke für den Hilfeversuch.
Erstelle ein Konto oder melde dich an, um einen Kommentar zu schreiben.