Generelle Routing Frage
Hallo,
ich habe einige grundsätzliche Fragen zu Thema Routing. Ich habe einen VPN-Tunnel eingerichtet. Auf beiden Seiten sind mehrere VLANs eingerichtet.
Site A: 10.2.x.x
- VLAN 10: 10.2.10.x
- VLAN 20: 10.2.20.x
Site B: 10.1.x.x
- VLAN 10: 10.1.10.x
- VLAN 20: 10.1.20.x
Der Tunneln ist in 10.1.96.0 bzw. 10.2.96.0
Ich möchte jetzt das von Site A aus VLAN 20 auf das VLAN 10 in Site B zugegriffen werden kann.
Ich habe auf Site A eine Routing Regel die besagt:
Source VLAN 20 Destination SiteB_VLAN10 NextHop Tunnel
Wäre das korrekt? Ist es in dem Fall die einzige notwendige Regel auf Site A, wie kommt der Traffic zurück? Wie sieht die Regel auf der Seite B aus?
Danke für eure Hilfe!
ich habe einige grundsätzliche Fragen zu Thema Routing. Ich habe einen VPN-Tunnel eingerichtet. Auf beiden Seiten sind mehrere VLANs eingerichtet.
Site A: 10.2.x.x
- VLAN 10: 10.2.10.x
- VLAN 20: 10.2.20.x
Site B: 10.1.x.x
- VLAN 10: 10.1.10.x
- VLAN 20: 10.1.20.x
Der Tunneln ist in 10.1.96.0 bzw. 10.2.96.0
Ich möchte jetzt das von Site A aus VLAN 20 auf das VLAN 10 in Site B zugegriffen werden kann.
Ich habe auf Site A eine Routing Regel die besagt:
Source VLAN 20 Destination SiteB_VLAN10 NextHop Tunnel
Wäre das korrekt? Ist es in dem Fall die einzige notwendige Regel auf Site A, wie kommt der Traffic zurück? Wie sieht die Regel auf der Seite B aus?
Danke für eure Hilfe!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 360177
Url: https://administrator.de/contentid/360177
Ausgedruckt am: 05.11.2024 um 06:11 Uhr
11 Kommentare
Neuester Kommentar
Hier fehlen wieder mal sämtliche Informationen welche VPN Spielart überhaupt zum Einsatz kommt (IPSec(L2TP)/OpenVPN/SSTP/SSL ...), denn wäre es bspw. IPSec würde man die Subnets dem Partner in Phase 2 übermitteln und bräuchte überhaupt keine manuellen Routen defnieren.
Hi,
folgende Möglichkeiten gibt es um mehrere Netze an einem Endpunkt durch einen IPsec Tunnel verfügbar zu machen:
1. mehrere Phase 2 Einträge; deiner Aussage nach läßt es ich auf deiner Firewall nicht einstellen;
was ist das für eine FW ? Wenn sie es wirklich nicht kann: ggf. ersetzen.
2. Phase 2 erhält die übergeordnete Netz als Source ud Target: Site A = 10.2.0.0/16 , Site B = 10.1.0.0/16;
Zugriff auf die einzelnen tatsächlich existierende Netze muß dann durch Regeln erfolgen.
3. Erstelle ein Transfernetz mit ggf. 1:1 NAT
-
Meiner Meinung nach macht auf Dauer nur eine "vernünftige" Firewall mit der Möglichkeit mehrere Phase 2 Einträge zu erstellen Sinn.
CH
folgende Möglichkeiten gibt es um mehrere Netze an einem Endpunkt durch einen IPsec Tunnel verfügbar zu machen:
1. mehrere Phase 2 Einträge; deiner Aussage nach läßt es ich auf deiner Firewall nicht einstellen;
was ist das für eine FW ? Wenn sie es wirklich nicht kann: ggf. ersetzen.
2. Phase 2 erhält die übergeordnete Netz als Source ud Target: Site A = 10.2.0.0/16 , Site B = 10.1.0.0/16;
Zugriff auf die einzelnen tatsächlich existierende Netze muß dann durch Regeln erfolgen.
3. Erstelle ein Transfernetz mit ggf. 1:1 NAT
-
Meiner Meinung nach macht auf Dauer nur eine "vernünftige" Firewall mit der Möglichkeit mehrere Phase 2 Einträge zu erstellen Sinn.
CH
Es ist ein IPSec. Hier kann ich allerdings nur ein Subnetz eintragen.
Das ist natürlich blöd wenn man so kastrierte Hardware hat Aber das ist kein Thema, denn du kannst ja etwas mit der Subnetzmaske Spielen dann. Damit kannst du das Problem einfach lösen.
Wenn du auf der einen Seite einen 14 Bit Prefix angibst (255.252.0,.0) und das Netz 10.0.0.0 dann inkludiert das alle Netze von 10.0.0.0 bis 10.3.255.255
Für die andere Seite machst du das dann mit 10.4.0.0 das inklidiert dann alle Netze bis 10.7.255.255.
Du kannst natürlich auch mit anderen Prefixes arbeiten je nachdem wie du deine lokalen Netze aufgeteilt hast.
Leider hast du es versäumt uns mitzuteilen mit welchen LAN Masken du arbeitest so das wir hier mal wieder nur im freien Fall raten können.
Kollege fuerte hat das oben schon zu Recht angemeckert.
Aber so mit den CIDR Masken löst du das Handicap deiner Hardware ganz einfach. Du musst dann nur aufpassen das du dieses Schema beibehälst.
Bei 16 Bit kannst du natürlich mit 10.1.0.0 arbeiten und 10.2.0.0 du musst dann aber logischerweise darauf achten das am Standort 1 nur IP Netze mit einem 10.1.x.y Prefix und größerer Maske auftauchen und analog an Standort 2 dann mit 10.2.x.y
Bedeutet dies dann in der Konsequenz, dass ich keine Routing-Einträge brauche?
Ja, denn der IPsec Tunnel schaufelt dann alles was 10.1.x.y ist auf eine Seite und alles was 10.2.x.y ist auf die andere.Alternativ könnte man auch dynamisch Routen mit RIPv2 oder OSPF wenn deine VPN Gurke das kann. Ist aber etwas Kanonen auf Spatzen wenn man nur ein paar Subnetze auf beiden Seiten hat. Guckst du dazu auch hier:
Cisco SVTI - Tunnel
Die Kenntnis, welche Firewall sich auf der anderen Seite befindet, ist sehrwohl von Bedeutung, da hiervon u.U. abhängig wäre, welche Konfiguration man auf der Zywall wählt. Das gewünschte Szenario ließe sich nämlich auf der Zywall durchaus in verschienen Varianten abbilden - u.a. halt auch per explizitem Routing (mittels Policyrouten). Letzteres ist einem jedoch verwehrt, wenn die Gegenstelle hiermit nicht umgehen kann - was durchaus häufig der Fall ist, denn der Standard geht eigentlich davon aus, dass nur solcher Traffic in den Tunnel geroutet wird, der Teil der Sicherheitsvereinbarung aus Phase 2 ist.
Um geeignete Empfehlungen abgegeben zu können, wäre daher nicht nur die Kenntnis des Modells der Gegenstrelle nötig, sondern auch Kennnis über deren Konfigurationsmöglichkeiten und Funktionsweise im Detail. Anderenfalls bestünde lediglich die Möglichkeit, das vom Standard vorgesehene Verhalten als "kleinsten gemeinsamen Nenner" anzunehmen. Und dies würde hier die Aufnahme aller Netze in die Phase2-Policy bedeuten. Wie bereits empfohlen, böte es sich beim vorliegenden IP-Adress-Design natürlich an, einfach die vorhandene Phase2-Policy auf zwei /16-Netze auszuweiten.
Zitat von @aqui:
Der letzte Eintrag sagt doch alles !! DISCONNECTED also wie wir hier schon vermutet haben KEIN Tunnelaufbau !
Der letzte Eintrag sagt doch alles !! DISCONNECTED also wie wir hier schon vermutet haben KEIN Tunnelaufbau !
Wie wäre es, das Logfile richtig zu lesen? Was Deiner Annahme nach der letzte Eintrag ist, ist nämlich der Erste! Der TO hat den Tunnel nur kurz gedropt, um den erfolgreichen Neuaufbau zu loggen...
Zitat von @aqui:
War eigentlich auch klar wenn du die andere Seite nicht anpasst an die Konfig. Nix Tunnel wenn die beidseitigen Credentials nicht stimmen !
War eigentlich auch klar wenn du die andere Seite nicht anpasst an die Konfig. Nix Tunnel wenn die beidseitigen Credentials nicht stimmen !
Auch hier gilt: einfach mal in Ruhe lesen, statt rumzupöbeln!
Der TO schrieb, dass er die Konfig auf beiden Seiten angepasst hat...
Hat er auch nicht behauptet! Das ist das Regelwerk der Policyrouten...
Zitat von @aqui:
Diese offenbaren aber ggf. eine weitere Falle in die du getappt bist !
Dort steht was von "L2TP" ! Bedenke das L2TP VPN nichts mit native IPsec zu tun hat !!
Wenn also eine Seite L2TP macht die andere IPsec dann scheitert das ebenfalls schon im Ansatz. Beide VPN Protokolle sind 2 unterschiedliche Baustellen. Hast du das beachtet ?
Diese offenbaren aber ggf. eine weitere Falle in die du getappt bist !
Dort steht was von "L2TP" ! Bedenke das L2TP VPN nichts mit native IPsec zu tun hat !!
Wenn also eine Seite L2TP macht die andere IPsec dann scheitert das ebenfalls schon im Ansatz. Beide VPN Protokolle sind 2 unterschiedliche Baustellen. Hast du das beachtet ?
Meine Güte. Liest Du irgendetwas von dem, was der TO schreibt?
Es besteht auf der Zywall zusätzlich zum Site-to-Site-IPSec-Tunnel noch ein Client-to-Site-VPN mit L2TPoverIPSec.
Für einen Internetaccess über Letzteres benötigt er die Policyroute Nr.1 (wegen dem SNAT). Die Policyroute Nr. 2 ist bei aktuellem Firmwarestand und geeigneter Konfiguration eigentlich entbehrlich, steht aber in den verfügbaren Anleitungen aus Kompatibilitätsgründen häufig noch drin.
Zitat von @Maik20:
Allerdings landet ein Tracert auf den Standort B nun im Internet:
Allerdings landet ein Tracert auf den Standort B nun im Internet:
C:\>tracert 10.2.10.10
>
> Routenverfolgung zu 10.2.10.10 über maximal 30 Hops
>
> 1 3 ms 2 ms 2 ms 192.168.1.1
> 2 10 ms 9 ms 9 ms 87.186.224.81
> 3 * * * Zeitüberschreitung der Anforderung.
> 4 *
>
Die Zywall antwortet als ersten Hop mit ihrer IP-Adresse im LAN1. Folglich hast Du Deinen Tracert aus dem LAN1 abgesetzt. Da das IP-Netz von LAN1 aber nicht Teil der Phase2-Policy ist, ist es völlig in Ordnung, dass die Zywall diesen Traffic an ihr Default-Gateway schickt...
Gruß
sk