Routing in 3 Netzwerken durch IPsec-Tunnel
Problem mit Routingtabellen zur Kommunikation in 3 Netzwerken durch IPsec-Tunnel
Hallo zusammen,
nach vielen Stunden und erfolglosen Versuchen beschreibe mal mein Problem zum Netzwerkrouting in 3 Teilnetzwerken:
Aufbau:
Standort A
192.168.10.0/24
|
|
ROUTER 192.168.10.254 (Netgear FVS318)
|
|
IPSEC-Tunnel durchs Internet
|
|
ROUTER 192.168.0.254 (Netgear FVS318)
|
|
Standort B
192.168.0.0/24
|
|
interner Router 192.168.0.10
2.NIC=192.168.3.10
Debian mit iptables
|
|
internes Netz 192.168.3.0/24
|
|
irgendein Server 192.168.3.101
Kein dynamisches Routing, d. h. keine Routingprotokolle wie RIP oder so...
So, das ganze funktioniert von Standort A zu Standort B und umgekehrt einwandfrei durch den IPSEC-Tunnel.
Die Rechner aus dem 10.0-Netz erreichen das 0.0er Netz und umgekehrt. Die Routingtabellen haben wir auf den PCs und Servern (nur dort, wo der Zugriff ins andere Netz notwendig war), statisch eingetragen (route add -p ...)
Jetzt kommt das 3.0-er Netz ins Spiel:
Das 3er Netz kommt problemlos ins 0.0-er Netz über den internen Router und umgekehrt, aber leider nicht zum Standort A durch.
Standort A kommt auch nicht ins 3.0-er Netz von Standort B.
Wohin muss der Client in Standort A sein Paket schicken, wenn er ins 3.0er-Netz will ? Vermutlich zuerst an den IPSEC-Router 192.168.10.254. Und wie dann weiter ? Am IPsec-Router kann man statische Routingtabellen anlegen. Der IPsec-Router muss das Paket vermutlich weiterleiten an den Router in Standort B, oder direkt an den internen Router im Standort B ?
Welche Route braucht der Server 3.101 zurück ?
Vermutlich ist die Lösung ganz simpel, nur ich komm einfach net drauf
Danke schonmal für Eure Hilfe !
Hallo zusammen,
nach vielen Stunden und erfolglosen Versuchen beschreibe mal mein Problem zum Netzwerkrouting in 3 Teilnetzwerken:
Aufbau:
Standort A
192.168.10.0/24
|
|
ROUTER 192.168.10.254 (Netgear FVS318)
|
|
IPSEC-Tunnel durchs Internet
|
|
ROUTER 192.168.0.254 (Netgear FVS318)
|
|
Standort B
192.168.0.0/24
|
|
interner Router 192.168.0.10
2.NIC=192.168.3.10
Debian mit iptables
|
|
internes Netz 192.168.3.0/24
|
|
irgendein Server 192.168.3.101
Kein dynamisches Routing, d. h. keine Routingprotokolle wie RIP oder so...
So, das ganze funktioniert von Standort A zu Standort B und umgekehrt einwandfrei durch den IPSEC-Tunnel.
Die Rechner aus dem 10.0-Netz erreichen das 0.0er Netz und umgekehrt. Die Routingtabellen haben wir auf den PCs und Servern (nur dort, wo der Zugriff ins andere Netz notwendig war), statisch eingetragen (route add -p ...)
Jetzt kommt das 3.0-er Netz ins Spiel:
Das 3er Netz kommt problemlos ins 0.0-er Netz über den internen Router und umgekehrt, aber leider nicht zum Standort A durch.
Standort A kommt auch nicht ins 3.0-er Netz von Standort B.
Wohin muss der Client in Standort A sein Paket schicken, wenn er ins 3.0er-Netz will ? Vermutlich zuerst an den IPSEC-Router 192.168.10.254. Und wie dann weiter ? Am IPsec-Router kann man statische Routingtabellen anlegen. Der IPsec-Router muss das Paket vermutlich weiterleiten an den Router in Standort B, oder direkt an den internen Router im Standort B ?
Welche Route braucht der Server 3.101 zurück ?
Vermutlich ist die Lösung ganz simpel, nur ich komm einfach net drauf
Danke schonmal für Eure Hilfe !
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 63804
Url: https://administrator.de/contentid/63804
Ausgedruckt am: 05.11.2024 um 10:11 Uhr
5 Kommentare
Neuester Kommentar
Hi,
ich vermute es liegt an der Rückroute.
Zuerst das einfache:
Der Server 192.168.3.101 braucht als Standardgateway die 192.168.3.10; sonst nichts; also keine weiteren statischen Routen.
Der Router 192.168.10.254 muss wissen dass das Netz 192.168.3.0 hinter dem VPN-Tunnel liegt. Kenne den Router nicht; entweder in der VPN-Konfig einzustellen oder als Route.
Der Router 192.168.0.254 braucht eine statische Route für das Netz 192.168.3.0 mit Gateway auf die 192.168.0.10.
Diese interne Router kennt dann den Weg; das Netz 192.168.3.0 ist ja sein eigenes auf der entsprechenden NIC, aber er kennt u.U. den Weg zu 192.168.10.0 nicht, also hier auch eine statische Route mit Gateway 192.168.0.254.
Viel Erfolg und lass uns wissen obs geklappt hat.
Gruss
Randy
ich vermute es liegt an der Rückroute.
Zuerst das einfache:
Der Server 192.168.3.101 braucht als Standardgateway die 192.168.3.10; sonst nichts; also keine weiteren statischen Routen.
Der Router 192.168.10.254 muss wissen dass das Netz 192.168.3.0 hinter dem VPN-Tunnel liegt. Kenne den Router nicht; entweder in der VPN-Konfig einzustellen oder als Route.
Der Router 192.168.0.254 braucht eine statische Route für das Netz 192.168.3.0 mit Gateway auf die 192.168.0.10.
Diese interne Router kennt dann den Weg; das Netz 192.168.3.0 ist ja sein eigenes auf der entsprechenden NIC, aber er kennt u.U. den Weg zu 192.168.10.0 nicht, also hier auch eine statische Route mit Gateway 192.168.0.254.
Viel Erfolg und lass uns wissen obs geklappt hat.
Gruss
Randy
Hi,
ich hab mir die Anleitung des Routers grad mal angesehen. Man kann hier scheinbar nur ein Netz für die Gegenseite des Tunnels angeben. Aber das ist genau das Problem; der Router muss wissen dass er die 192.168.3.0 in den Tunnel routen soll.
Frag doch mal bei Netgear nach: https://my.netgear.com/myNETGEAR/support.asp
Wie kann man weitere Subnetze eines Standortes in den Tunnel routen?
Sorry, sonst fällt mir im Moment auch nix ein.
Gruss
Randy
ich hab mir die Anleitung des Routers grad mal angesehen. Man kann hier scheinbar nur ein Netz für die Gegenseite des Tunnels angeben. Aber das ist genau das Problem; der Router muss wissen dass er die 192.168.3.0 in den Tunnel routen soll.
Frag doch mal bei Netgear nach: https://my.netgear.com/myNETGEAR/support.asp
Wie kann man weitere Subnetze eines Standortes in den Tunnel routen?
Sorry, sonst fällt mir im Moment auch nix ein.
Gruss
Randy