Route über Route routen

zonk90

Cadet 3rd Year
Registriert
Aug. 2008
Beiträge
45
Hallo zusammen, bitte entschuldigt, dass ich mein Thema mit einem derart verwirrenden Titel versehe, aber die Situation beschreibt es denke ich ganz gut. Ich schildere mal mein Problem bzw. Vorhaben und aktuelles Netzwerk-Setup:

LAN bei mir: 192.168.1.0
Router bei mir: 192.168.1.254
Ein Gerät mit der IP 19.168.1.245 baut eine Client-to-Site-VPN-Verbindung zu einem externen Anbieter auf.
Über diesen VPN-Tunnel werden gewisse Anfragen in ein "sicheres Netz" geroutet.

Zusätzlich existiert ein Cloudserver.

LAN dort: 192.168.5.0
Router dort: 192.168.5.254
Server dort: 192.168.5.200

Zwischen den beiden Routern / Firewalls steht eine Site-to-Site-VPN-Verbindung.
Der Server mit der IP 192.168.5.200 kann also alle Geräte im LAN 192.168.0.1 erreichen und umgekehrt.

Die Adresskreise / Subnetze 188.144.0.0/16 und 188.145.0.0/16 sollen durch das "sichere Netz", sprich über die IP 192.168.1.245 geroutet werden. Dazu habe ich auf der 192.168.1.254, sprich dem Router, zwei statische Routen hinterlegt.
Der Zugriff aus dem lokalen LAN auf die genannten Subnetze bzw. darin enthaltene IPs funktioniert problemlos.

Problem:
Der Zugriff aus dem entfernten LAN des Cloudservers soll nun auch Zugriff auf die Subnetze 188.144.0.0/16 und 188.145.0.0/16 bekommen und bei einer Anfrage auf eine dieser Adressen ebenfalls über die 192.168.1.245 gehen.
Leider funktioniert das nicht bzw. der Router 192.168.5.254, sprich der des Cloudservers, gibt die Anfrage nicht durch den Site-to-Site-VPN-Tunnel Richtung lokalem LAN, sondern schickt sie in die weite Welt hinaus.

Frage:
Welche Route muss ich auf dem Cloudserver setzen, sodass die Anfragen an 188.144.x.x oder 188.145.x.x durch den Tunnel in das 192.168.1.0er Netz und von dort auf die IP 192.168.1.245 geroutet werden?

Stichwort "Metrik der Route" habe ich schon durchprobiert, sprich der Route in das Netz eine geringere Metrik und damit höhere Priorität gegeben als der, die die Subnetze 188.144.0.0/16 und 188.145.0.0/16 bedient.
Leider bisher alles ohne Erfolg.

Ich freue mich über jede Art der Hilfestellung.
Danke vorab und bleibt gesund!
 
Eigentlich hat auf dem Server überhaupt keine Route was zu suchen. Das ist ja kein Router.

Wenn die 5.254 in die Welt schreit und nicht in den Tunnel, dann fehlt dort die passende Route für die 188.144.0.0/15 mit Gateway ...1.254. Wenn das VPN schon steht, sollte das reichen. Den Tunneleinstiegspunkt als zusätzliches Interface angeben kann aber nicht schaden.
 
@till69 : Der Site-to-Site-Tunnel ist ein Standard-IPSec.
Ich vergaß zu erwähnen, dass es sich um einen Windows-Server handelt. Die Firewall cloudserverseitig ist eine PFSense, LAN-seitig steht ein Lancom-Router.

@RalphS : Der Cloudserver ist das einzige Gerät hinter der PFSense-Firewall. Dementsprechend habe ich es mir "einfach" gemacht und die Routen dort hinterlegt anstatt sie auf der PFSense selbst einzutragen. Oder ist das rein technisch gesehen ein Problem?

Edit: erstmal vielen Dank für eure Beteiligung und eure Antworten!
 
Routen auf dem Endgerät dann, wenn es im Netz kein eindeutiges Gerät gibt, sprich wenn es zwei oder mehr Router im selben Segment gibt. Oder Multihoming.

Multihoming wird das sicher nicht sein - wäre auch recht schlechte Praxis.
Ob es mehr als den einen Router gibt in der 5.0 weißt Du besser als ich. Wenn, muß der Client erfahren, zu welchem Router die Pakete sollen (und unter welchen Umständen). Dann (nur dann) muß die Routinginfo zum Client, zB per RIP2 oder sowas.

Routing ist immer hop-to-hop. Kein Netzwerkgerät kennt die Umstände nach dem nächsten Hop. Wäre auch viel zu aufwendig und fehleranfällig. Der Cloudserver muß wissen: kenne Ziel nicht, ergo Gateway(Router). Der muß wissen: aha dieses Zielnetz muß ich auf diesen Port kopieren. Und der Router des Zielnetzes schließlich muß wissen, daß sich der Zielhost im eigenen Segment befindet.

"Route über Route" ist daher per Design ausgeschlossen.

Da das site-to-site ist sollte eigentlich das VPN selber damit nix mehr zu tun haben.. aber ohne Gewähr. Mehr als "Route funktioniert nicht" kann ja nicht passieren. Also auf der 5.254 eine anlegen mit Ziel 188.144.0.0/15 gw 192.168.1.254 iface tunneleinstieg und entweder tut es dann schon oder tut es halt nicht.
Rückroute nicht vergessen, falls die noch nicht existiert, damit Geräte aus der 188... auch übers VPN antworten und nicht frei durch die Welt.
 
RalphS schrieb:
Also auf der 5.254 eine anlegen mit Ziel 188.144.0.0/15 gw 192.168.1.254 iface tunneleinstieg und entweder tut es dann schon oder tut es halt nicht.
Ich bleib dabei: "route add" reicht/geht nicht mit IPsec

Ist mit ein Grund warum ich OpenVPN bevorzuge...
 
  • Gefällt mir
Reaktionen: brainDotExe
Genau, Routen greifen bei IPSec nicht, da die Daten breits vorm Routing verarbeitet werden.
 
Moin zusammen,

danke für den vielen Input und die zahlreichen Antworten!
Ich habe jetzt die Phase2 der IPSec-Verbindung dupliziert und dort jeweils als "Remote Network" (so heißt das bei der PFSense) die IP-Netze eingetragen, die durch das "sichere Netz" geroutet werden soll.
Damit habe ich einen Phase1- und insgesamt drei Phase2-Einträge. Zusätzlich noch auf dem Cloudserver die statischen Routen für die beiden Netze auf die 192.168.5.254 eingetragen und jetzt läuft es :)
DANKE an alle Beteiligten!
 
  • Gefällt mir
Reaktionen: brainDotExe
Zurück
Oben