Problem beim Routing zweier Standorte über Zentrale
Hallo,
Mehrer Standorte sind per Site-to-Site-VPN an die Zentrale (192.168.10.0/255.255.255.0/Cisco RV320) angeschlossen. Verbindung klappt wunderbar und alle Dienste in der Zentrale sind erreichbar. Aufgrund baulicher Gegebenheiten ist ein Standort mit 2 VPN Verbindungen verbunden. Jetzt muss ein PC (192.168.18.0/255.255.255.0) mit dem Drucker im anderen Subnetz (192.168.15.0/255.255.255.0) verbunden werden.
Ich habe am PC folgende Route hinzugefügt:
route add 192.168.15.0 mask 255.255.255.0 192.168.10.1
Allerdings klappt es nicht, obwohl doch dem Cisco RV320 (192.168.10.1) die Route ins 15er Netz bekannt sein dürfte. Oder funktioniert dies dann doch nicht so einfach.
Gruß
Mehrer Standorte sind per Site-to-Site-VPN an die Zentrale (192.168.10.0/255.255.255.0/Cisco RV320) angeschlossen. Verbindung klappt wunderbar und alle Dienste in der Zentrale sind erreichbar. Aufgrund baulicher Gegebenheiten ist ein Standort mit 2 VPN Verbindungen verbunden. Jetzt muss ein PC (192.168.18.0/255.255.255.0) mit dem Drucker im anderen Subnetz (192.168.15.0/255.255.255.0) verbunden werden.
Ich habe am PC folgende Route hinzugefügt:
route add 192.168.15.0 mask 255.255.255.0 192.168.10.1
Allerdings klappt es nicht, obwohl doch dem Cisco RV320 (192.168.10.1) die Route ins 15er Netz bekannt sein dürfte. Oder funktioniert dies dann doch nicht so einfach.
Gruß
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 250571
Url: https://administrator.de/contentid/250571
Ausgedruckt am: 22.11.2024 um 09:11 Uhr
15 Kommentare
Neuester Kommentar
Das sollte eigentlich gar nicht notwendig sein.
Allerdings klappt es nicht, obwohl doch dem Cisco RV320 (192.168.10.1) die Route ins 15er Netz bekannt sein dürfte. Oder
funktioniert dies dann doch nicht so einfach.
Der muß den Weg kennen. prüf nach, ob da die Route korrekt drin ist, Wenn ja kann es sein, daß irgendeine ACl verhindert, daß die Kisten der Standorte miteinander reden.
lks
Zitat von @opalka:
Die Access Rule der FW Cisco lautet erlaube immer allen Verkehr aus dem LAN von jedem nach jedem.
Ist Site-to-Site VPN LAN oder WAN?
Ich werde mal eine Regel für die beiden Netzwerke einrichten, mal schauen, ob es dann klappt
Die Access Rule der FW Cisco lautet erlaube immer allen Verkehr aus dem LAN von jedem nach jedem.
Ist Site-to-Site VPN LAN oder WAN?
Ich werde mal eine Regel für die beiden Netzwerke einrichten, mal schauen, ob es dann klappt
Wie weit komtm denn ein traceroute?
lks
Hallo,
Aber wie wird der Drucker denn nun angesprochen? Mittels der IP Adresse oder mittels
\Pfad\Drucker?
Gruß
Dobby
Mehrer Standorte sind per Site-to-Site-VPN an die Zentrale (192.168.10.0/255.255.255.0/Cisco
RV320) angeschlossen.
Und erfahren wir auch noch welche VPN Methode benutzt wird?RV320) angeschlossen.
Aufgrund baulicher Gegebenheiten ist ein Standort mit 2 VPN Verbindungen verbunden.
Kannst Du uns mal dazu etwas mehr erzählen?Jetzt muss ein PC (192.168.18.0/255.255.255.0) mit dem Drucker im anderen
Subnetz (192.168.15.0/255.255.255.0) verbunden werden.
Das sollte ja nicht das Problem sein und eine extra Route braucht es dafür auch nicht!Subnetz (192.168.15.0/255.255.255.0) verbunden werden.
Aber wie wird der Drucker denn nun angesprochen? Mittels der IP Adresse oder mittels
\Pfad\Drucker?
Gruß
Dobby
Zitat von @opalka:
Der springt vom Gateway gleich auf eine öffentliche IP-Adresse und verläuft dann im Sand.
Der springt vom Gateway gleich auf eine öffentliche IP-Adresse und verläuft dann im Sand.
Dann stimmt das routing nicht. Prüf mal die Routen, ob der jeweils ander Standort in den Tunnel hinein geroutet wird.
lks
obwohl doch dem Cisco RV320 (192.168.10.1) die Route ins 15er Netz bekannt sein dürfte.
1. Frage:Dürfte ?? Warum rätst du und siehst nicht ganz einfach mal in die Routing Tabelle des fraglichen Routers ob sie wirklich drinsteht ?
Das klärt diese Frage dann doch in Sekunden auch ohne Forum Thread.
2.Frage:
Wenn der Router die Route kennt warum machst du dann diesen zusätzlichen Blödsinn und konfigurierst dem PC Endgerät nochmals ein statische Route odendrauf obwohl dieser ja so oder so den Router als Default Gateway hat ?? Zum Gürtel noch den Hosenträger.... ? Hört sich etwas nach plan- und wissenlosen Trial and Error an als Routing ?
Das wäre ja überflüssiger Quatsch oder was sollte der tiefere Sinn sein wenn du nicht planlos einfach rumprobierst ?!
Router sollen routen aber niemals Endgeräte. Lernt übrigens jeder Netzwerker in der ersten Klasse !
Wenn also dann bitte die Route statisch auf dem Router einragen, denn DER muss ja wissen das er das 2te Teilnetz auch über den VPN Tunnel erreichen muss. Das Endgerät kennt ja nur diesen Default Router als default Gateway. Ob du dann da zusätzlich noch ne dedizierte Route einträgst oder in China kippt ein Sack Reis ist doch Latte und natürlich Unsinn, denn bei VPN Routern routen ja diese.
Entweder du aktivierst also ein dynamsiche Routing protokoll wie RIPv2 oder OSPF oder trägst auf ALLEN beteiligten Routern statische Routen ein...fertisch !
Nebenbei: Traceroute und Pathping sind wie immer deine besten Freunde zum Troubleshooting....
Ja, das tut es natürlich wie alle anderen dynamischen Route Protokolle auch. Wenn möglich solltest du RIPv2 verwenden und nicht mehr das olle RIP.
Ein dynmaische protokoll hat halt den Vorteil das man sich die ganze Hop für Hop Konfiguration statischer Routen spart und bei redundanten Links, sofern vorhanden, gleich automatisch umschaltet.
Spart also so ne Menge Konfig Arbeit...
Ein dynmaische protokoll hat halt den Vorteil das man sich die ganze Hop für Hop Konfiguration statischer Routen spart und bei redundanten Links, sofern vorhanden, gleich automatisch umschaltet.
Spart also so ne Menge Konfig Arbeit...