5
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 !
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: 63804
Url: https://administrator.de/forum/routing-in-3-netzwerken-durch-ipsec-tunnel-63804.html
Ausgedruckt am: 23.12.2024 um 17:12 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 Randy,
danke erstmal für Deine Antwort !
<<
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.
<<
Vermutlich liegt hier der Hund begraben. Durch den Tunnel werden keine Daten mit Destination 3.0/24 geleitet. Auch nach dem statischen Eintragen auf 10.254 (192.168.3.0/24 via 0.10/24) gings net. Vom Router aus kann ich die 0.10 aber anpingen, die Daten kommen dort auch an (mit tcpdump verifiziert). Nur wenn ich 3.10 ping, kommt nix an auf 0.10 lt. tcpdump.
Also muss ich mir das ipsec genauer anschauen. Allerdings wirds hier Schwierig, weil das IPSEC wird ja mit einem lokalen LAN und einem remote-LAN konfiguriert (10.0 und 0.0 in diesem Falle).
Leider bietet der Router 10.254 (Netgear FVS 318 auf beiden Seiten) keine Möglichkeit, hier zusätzliche Parameter zu konfigurieren. Die Zugangsrestriktionen für den Tunnel (any local subnet usw...) habe ich alle freigeschalten. Leider auch ohne erfolg.
Evtl. hilft ein zweiter Tunnel weiter. Da muss ich mal noch rumexperimentieren. Sonst fällt mir leider nix ein. Solange keine Daten auf 0.10 ankommen, liegts sicher am IPSEC.
Fällt Dir sonst noch was ein ?
Grüssle, Stefan
danke erstmal für Deine Antwort !
<<
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.
<<
Vermutlich liegt hier der Hund begraben. Durch den Tunnel werden keine Daten mit Destination 3.0/24 geleitet. Auch nach dem statischen Eintragen auf 10.254 (192.168.3.0/24 via 0.10/24) gings net. Vom Router aus kann ich die 0.10 aber anpingen, die Daten kommen dort auch an (mit tcpdump verifiziert). Nur wenn ich 3.10 ping, kommt nix an auf 0.10 lt. tcpdump.
Also muss ich mir das ipsec genauer anschauen. Allerdings wirds hier Schwierig, weil das IPSEC wird ja mit einem lokalen LAN und einem remote-LAN konfiguriert (10.0 und 0.0 in diesem Falle).
Leider bietet der Router 10.254 (Netgear FVS 318 auf beiden Seiten) keine Möglichkeit, hier zusätzliche Parameter zu konfigurieren. Die Zugangsrestriktionen für den Tunnel (any local subnet usw...) habe ich alle freigeschalten. Leider auch ohne erfolg.
Evtl. hilft ein zweiter Tunnel weiter. Da muss ich mal noch rumexperimentieren. Sonst fällt mir leider nix ein. Solange keine Daten auf 0.10 ankommen, liegts sicher am IPSEC.
Fällt Dir sonst noch was ein ?
Grüssle, Stefan
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
Hi Randy,
vielen Dank für Deine Hilfe !
Das mitlesen mit tcpdump bestätigt den Verdacht, dass es an den IPSEC-Routern liegt.
Ich werde daher mal beim Support nachfragen, obs ne Lösung gibt. Ansonsten muss ich die Router wohl mal langsam ersetzen...
Bis ich die Antwort vom Support habe, werde ich den Thread noch offen lassen.
Gruss, Stefan
vielen Dank für Deine Hilfe !
Das mitlesen mit tcpdump bestätigt den Verdacht, dass es an den IPSEC-Routern liegt.
Ich werde daher mal beim Support nachfragen, obs ne Lösung gibt. Ansonsten muss ich die Router wohl mal langsam ersetzen...
Bis ich die Antwort vom Support habe, werde ich den Thread noch offen lassen.
Gruss, Stefan
Hier die Antwort vom Support:
7/16/2007 11:27:00 AM
Um das zweite Subnetz erreichen zu können, benötigen Sie einen direkten tunnel in das Zielnetz.
Der LAN-Router, der die beiden Subnetze trennt muss als Tunnel-Endpunkt konfiguriert werden.
Eine Angabe von mehreren Teilnetzen im VPN-Client ist nicht möglich und auch ein Weiterrouten mittels statischer Routen im Gatewayrouter wird nicht funktionieren.
Damit kann der Thread geschlossen werden, da das Problem zwar nicht gelöst werden konnte, aber die Ursache ermittelt wurde.
Gruss
Stefan
7/16/2007 11:27:00 AM
Um das zweite Subnetz erreichen zu können, benötigen Sie einen direkten tunnel in das Zielnetz.
Der LAN-Router, der die beiden Subnetze trennt muss als Tunnel-Endpunkt konfiguriert werden.
Eine Angabe von mehreren Teilnetzen im VPN-Client ist nicht möglich und auch ein Weiterrouten mittels statischer Routen im Gatewayrouter wird nicht funktionieren.
Damit kann der Thread geschlossen werden, da das Problem zwar nicht gelöst werden konnte, aber die Ursache ermittelt wurde.
Gruss
Stefan
