maik20
Goto Top

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!

Content-Key: 360177

Url: https://administrator.de/contentid/360177

Printed on: April 20, 2024 at 03:04 o'clock

Mitglied: 135111
135111 Jan 07, 2018 updated at 09:34:44 (UTC)
Goto Top
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.
Member: Maik20
Maik20 Jan 07, 2018 at 11:28:17 (UTC)
Goto Top
Es ist ein IPSec. Hier kann ich allerdings nur ein Subnetz eintragen. Hier ist auf der einen Seite das 10.2.96.0 und auf der anderen das 10.1.96.0 eingetragen. Mehr Subnetze lassen sich nicht angeben also muss ich doch routen, oder?
Member: ChriBo
ChriBo Jan 07, 2018 at 12:03:56 (UTC)
Goto Top
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
Member: Maik20
Maik20 Jan 07, 2018 at 13:13:49 (UTC)
Goto Top
Also ich könnte schon mehrere Phase 2 Einträge anlegen. Die Firewall ist eine Zyxel USG100.
Allerdings will ich die Netze nicht 1 zu 1 durchleiten. Letztendlich gibt es mehrere VLANs. Ein Beispiel:

VLAN85A soll auf 10B, 20B, 30B zugreifen oder
310B, 390B auf 10A, 90A

Die Netze müssen nicht 1:1 verbunden werden.

Wenn ich es richtig sehe wäre die Option 2 dann der richtige Weg. Ich setze einfach in der Phase 2 Die Netze 10.2.0.0/16 , Site B = 10.1.0.0/16 und erstelle dann ein Regelwerk. Bedeutet dies dann in der Konsequenz, dass ich keine Routing-Einträge brauche? Lediglich das Regelwerk in der Firewall? Oder müsste ich zusätzlich eine Route anlegen? Wenn ja welche?
Member: aqui
aqui Jan 07, 2018 updated at 13:33:53 (UTC)
Goto Top
Es ist ein IPSec. Hier kann ich allerdings nur ein Subnetz eintragen.
Das ist natürlich blöd wenn man so kastrierte Hardware hat face-sad
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. face-sad
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
Member: Maik20
Maik20 Jan 07, 2018 at 15:13:54 (UTC)
Goto Top
Danke für eure Hilfe, leider fruchtet es noch nicht. Kann aber auch an mir liegen, da ich hier absoluter Neuling bin.

Ich fasse einfach nochmal zusammen.

Standort A - Zyxel USG 100
LAN 1: 192.168.1.0/24
Auf dem LAN 1 sind einige VLANs eingerichtet um die es geht. Die VLANs liegen alle in 10.1.0.0/16
-> VLAN10 = 10.1.10.0
-> VLAN20 = 10.1.20.0
-> ...

Standort B - Firewall ?
Subnetz 10.2.0.0/16
-> VLAN10 = 10.2.10.0
-> VLAN20 = 10.2.20.0
-> ...

Ich habe den Tunnel jetzt auf beide Seiten folgende Subnetze wechselseitig als Local und Peer zugeordnet:
10.1.0.0/16 und 10.2.0.0/16

Der Tunnel wird aufgebaut und steht.

Ich bekomme jedoch von Standort A derzeit kein Paket nach Standort B. Am Standort B ist im VLAN10 eine NAS 10.2.10.10. Wenn ich vor Ort bin, kann ich diese anpingen. Ein Ping von Standort A aus schlägt fehlt. Ein Tracert löst mir nur bis zur USG100 auf:

C:\>tracert 10.2.10.10

Routenverfolgung zu 10.2.10.10 über maximal 30 Hops

  1     2 ms     2 ms     1 ms  192.168.1.1
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3     *        *        *     Zeitüberschreitung der Anforderung.

Eine Route ist nicht eingerichtet. Ich habe auf der USG100 zum testen die Firewall mal mit folgender Regel versehen:
From Any
To Any
Allow

Damit würde ich also auch die Firewall ausschließen.
Member: aqui
aqui Jan 07, 2018, updated at Jan 10, 2018 at 09:35:21 (UTC)
Goto Top
feh.
Member: Maik20
Maik20 Jan 07, 2018 updated at 15:42:10 (UTC)
Goto Top
Hallo aqui,

sei doch nicht gleich so grummelig. Mir ist der Name der Firewall entfallen, kann ich gerne nachreichen. Ich komme heute nicht mehr hin, da meine Frau das Auto hat face-wink Der Tunnel war aber im Log drüben augenscheinlich in Ordnung. Auch dieses Log kann ich gerne noch nachreichen.

Hier erstmal der Auszug aus "meiner Gurke" face-wink

Ich habe den Tunnel geschlossen und dann neu aufgebaut:
tunnelaufbau

Wie bereits erwähnt habe ich keine Routingregeln angelegt:
routing

Die beiden ersten Regeln sind für VPN Zugang mittels L2TP, die beiden anderen Regeln sind deaktiviert. Statische Routen sind nicht angelegt.

Ich habe die Gurke einmal neu gestartet. Half nicht wirklich. 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 Firewall war auf alle "ANY" Interfaces eingestellt. Sprich einmal auf Durchzug.

Ich bin echt dankbar für eure Hilfe!!!!
Member: aqui
aqui Jan 08, 2018, updated at Jan 10, 2018 at 09:27:26 (UTC)
Goto Top

Member: sk
Solution sk Jan 09, 2018 updated at 19:09:41 (UTC)
Goto Top
Zitat von @aqui:
kann ich gerne nachreichen
Nöö, ist ja nicht soo wichtig.

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 !

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 !

Auch hier gilt: einfach mal in Ruhe lesen, statt rumzupöbeln!
Der TO schrieb, dass er die Konfig auf beiden Seiten angepasst hat...


Zitat von @aqui:
Das ist auch KEINE Routingtabelle sondern sieht eher nach Filterregeln ein.

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 ?

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:

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
Member: Maik20
Maik20 Jan 09, 2018 at 20:15:43 (UTC)
Goto Top
Danke sk!



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...


Genau das war das Problem. Mein Test-Laptop hing die ganze Zeit im LAN1 mit 192.168.1.x nicht aber im 10er Netz. Da er natürlich nur innerhalb des 10er-Netzes den Tunnel nutzt konnte es nicht funktionieren.