Nachträglich "abgetrennter" IP Bereich bei MPLS mit zentralem Breakout

[Skeeve]

Hallo,
wir sind gerade mitten in der Umstellung auf einen neuen Provider.
Alter Zustand: 1x MPLS zur Zentrale für alles Interne und 1x extra DSL für Internet Zugang direkt aus dem Standort.
Neuer Zustand: 1x MPLS zur Zentrale
Eigentlich kein Problem, die Leitungen sind "dick" genug um auch den Internettraffic mit aufzunehmen und Zentral rauszulassen.
Aber... leider haben wir übersehen, das es in machen Standorten kleine Gruppen gibt, die mit Endgeräten die außerhalb unserer Kontrolle liegen, Internetzugang benötigen und darum ja keinen Kontakt zum eigentlichen LAN haben sollen.
Vorher war das kein Problem, weil die direkt am Lancom rausgelassen wurden und darum keinen Kontakt zum eigentlichen LAN hatten. Es geht da jeweils nur um 2-3 Geräte. Aus "politischen" Gründen ist das Eingemeinden leider keine Option
Von daher die Frage, kriege ich mit den immer noch vorhandenen 1781ern einen Lösung für das Problem hin?
Ganz wichtig ist das es kein Techtelmechtel mit vorhandenen LAN-Ressourcen gibt, sondern nur der Weg zum zentralen Breakout genutzt wird.
Wir haben zentrales DNS und DHCP, aber für diese Sonderlocken dürfte auch der Lancom gerne den Job übernehmen. Vor allem, weil eh nicht auszuschließen ist, das da hin- und wieder mal ein Gerät an uns vorbei getauscht wird, mit Reservierungen im zentralen DHCP ist da dann auch wenig zumachen.
Eigene Subnetze kommen leider auch erstmal nicht in Frage, weil der Provider dann das ganze Routing im MPLS anpacken müsste damit die Rückrouten passen.
Bin dankbar für alle Denkansätze.

[backslash]

Hi Skeeve,

Eigene Subnetze kommen leider auch erstmal nicht in Frage

da frage ich mich, wie du bisher verhindert hast, daß die Geräte dein LAN "kapern"...

aber sei's drum:
am einfachsten packst du die betroffenen Geräte in ein eigenes Netz und baust einen LTP oder GRE-Tunnel zwischen Filiale und Zentrale auf, der den Traffic dieser Geräte durch das MPLS zur Zentrale tunnelt. In der Zentrale kannst du dann den Traffic der Geräte ins Internet ausleiten. Und wenn du das Ganze schön mit Routing-Tags versiehst brauchts du dazu nicht mal Firewallregeln...

In der Filiale verpaßt du dem eigenen Netz, in dem sich diese Geräte befinden ein Routing-Tag ungleich dem des INTRANETs. Dann erstellst du eine Default-Route mit diesem Tag, die auf die Tunnel-Verbindung zeigt. Für die Tunnel-Verbindung trägst du in der WAN-Tag-Tabelle ebenfalls dieses Tag ein.

In der Zentrale richtest du eine Route zur Filiale ein, die du auf die Tunnel-Verbindung legst - mit Routing-Tag 0. Desweiteren verpaßt du Tunnel-Verbidnung du in der WAN-Tag-Tabelle ein Routing-Tag, daß natürlich ungleich dem deines INTRANETs ist.

fertig... Damit kommen die Geräte nicht in dein INTRANET, wenn dein INTRANET aber das Tag 0 (Supervisor) hat, kannst du dennoch von dort aus auf die Geräte zugreifen...

Du kannst das Ganze natürlich auch mit aufwendigen Firewallregeln in Filiale und Zentrale lösen, aber wenn man es sich einfach machen kann...


Gruß
Backslash

[Skeeve]

Hi backslash,

ja man merkt, ich bin derzeit nicht ganz auf der Höhe und war darum nicht präzise genug.
Vor der Umstellung waren die Geräte in einem eigenen Subnetz, auf LAN-4/ETH-4 mit DHCP von Lancom-Router.
Am 1781 war direkt ein ADSLer für den Internet-Zugang für den Standort, da drüber haben wir die Spezis dann auch mit raus gelassen und eben jeden Traffic von und nach links und rechts unterbunden. Genau der Anschluss ist jetzt aber weg gefallen, es gibt nur noch den zusätzlichen Router vom Provider der auch das MPLS stellt. Das MPLS vorher kannte die Sonderlocken-Netze nicht und darum kennt das jetzige diese Netze auch nicht.
Vorher war das auch gut so, quasi beiderseitig gewünscht, die Geräte sind vom Typ "BYOD" und benötigten und wollten auch keine internen Ressourcen. Wie gesagt, das ist "politisch" und auch mittelfristig nicht änderbar.
Das lief einige Jahre so und bei der Planung sind die echt durch durchgerutscht.
Der nächste Punkt, siehe wieder meinen ersten Satz , "Zentrale" ist zum Teil das virtuelle RZ des Providers, dort findet auch der eigentliche Internet-Breakout für die Standorte statt. Es wäre möglich den Traffic erst bis in die physische Zentrale zu holen, aber das würde die netto Bandbreite hier schon deutlich reduzieren... es geht um 12 Standorte.

Kommen wir also zu den aufwendigen Firewall-Regeln
Also das habe ich bisher gemacht:
LAN-1/ETH-1 ist mit dem Standortswitch verbunden über den auch der MPLS-Router erreichbar ist.
Da ich unsicher bin, wie das Standortnetz auf den DHCP auf dem Lancom reagiert, habe einen kleinen Teil der DHCP-Leases auf den zentralen DHCPs gesperrt und wieder auf dem 1781 auf LAN-4/ETH-4 per DHCP zur Verfügung gestellt. Das Sondernetz hängt an ETH-4 (über die Hausverkabelung sicher gestellt). LAN-1 und LAN-4 sind per BRG-1 verbunden. LAN-1 und LAN-4 habe beide Adressen aus dem Standort-Netz.
Ein Client an ETH-4 bekommt eine der gewünschten DHCP-Leases vom Lancom, Clients an ETH-2/3 bekommen DHCP-Leases vom Zentralen DHCP.
Diese Trennung ist also sauber.

Dann habe ich eine FW Regel erstellt, die jeden Netzwerkverkehr zu meinem PC aus dem DHCP-Bereich vom Lancom verbietet.
Leider ohne Erfolg, ich kann voll auch meinen PC zugreifen. Andersherum ist der Client an ETH-4 nicht mal pingbar.
Ich habe alle FW Regeln so gestaltet, das es immer eine Monitorbenachrichtigung gibt, also auch im Allow-Fall. Leider zeigt der LANMonitor auch die Zugriffe auf meinen PC nicht an, das bedeutet, das die FW gar nicht greift. Liegt das an der Bridge-Gruppe LAN-1/LAN-4?!

[backslash]

Hi Skeeve

wenn die BYOD-Geräte in deinem Netz hängen - egal ob physikalisch oder über die Bridge. dann geht Traffic zwischen deinem PC und den BYOD-Gewäten nicht über die Firewall - die Greäte sprechen direkt miteinander. Die Geräte müssen in ein eigenes Netz, das von einem INTRANET getrennt ist, damit der Traffic auch über die Firewall läuft...

Wenn du die Zentrle nicht anpassen kannst - entweder einen L2TP-Tunnel einruichetn oder das BYOD-BNetz dort bekannt machen, bleibt höchsztens noch die N:N-NAT-Variante, bei der du in Richtung der Zentrale die BYOD-Gerärte adreßmässig in dein Intranet mappst.. Angemonnem dein INTRANET ist 192.168.1.x/24 dann könntest du ein kleines für die BYOD-Geräate anlege, z.B. mit 16 Adressen: 192.168.2.x/28. Dann mußt du nur dafür sorgen, daß du in deinem INTRANET einen 16-Adressen langes Block unvergeben hast, z.B. am Ende (192.168.1.240 - 192.168.1.255). Dann kannst du ein N:N-NAT einrichetn, daß das BYOD-Netz in den freien Teil am Ende des INTRANETs mappt:

Code: Alles auswählen

Gegesntelle:   MPLS-Verbindung
Quell-IP:      192.168.2.0        (Netz-Adresse des BYOD-Netzes)
Netzmakse:     255.255.255.240    (Netz-Maske des BYOD-Netzes)
Umgesetzte-IP: 192.168.1.240      (erste freie IP des INTRANET)

Wobei: wenn die BYOD-Geräte nur ins Internet sollen, dann kannst du eigentlich auch das Polcy-Based-NAT verwenden und den Traffic der BYOD-Geräte hinter einer von dir frei gewählten Adresse maskieren. Dazu ertellst du folgende Firewall-Regel:

Code: Alles auswählen

Name:     NAT-BYOD
Aktion    übertragen
          [x] policy basierets NAT: IP-hinter der maskiert werden soll (freie IP aus dem INTRANET)
Quelle:   alle Stationen im lokalen Netz BYOD
Ziel:     alle Stationen
Dienste:  alle Dienste

Und dann brauchst du natürlich noch eine Firewall-Regel die den Traffic des BYOD-Netzes in alle Netze blockiert, in die die nicht sollen, also die INTRANETs aller Filialen sowie Netz der Zentrale - ggf. einfach alle privaten Netze verbieten:

Code: Alles auswählen

Name:     DENY-BYOD
Aktion    zurückweisen
Quelle:   alle Stationen im lokalen Netz BYOD
Ziel:     IP-Netze 10.0.0.0/255.0.0.0, 172.16.0.0/255.240.0.0, 192.168.0.0/255.255.0.0, 224.0.0.0/224.0.0.0
Dienste:  alle Dienste

Gruß
Backslash

[Skeeve]

So, ich habe mir im Labor mal eine "Teststrecke" aufgebaut.

Client -> 1781A (BYOD-Router) -> 1781A (als MPLS Simulator) -> LAN in Zentrale
Auf den 1781ern ist jeweils der isolierte Modus aktiv.
Der BYOD-Router ist über ETH-1/LAN-1 mit dem MPLS-Router ETH-4/LAN-4 verbunden.
Und der MPLS-Router ist dann per ETH-1/LAN-1 mit der Zentrale verbunden.

Stecke ich den Client an ETH-2 oder 3/LAN-1 auf dem BYOD-Router, bekommt der Client eine DHCP Lease wie gewünscht/gewollt/erwartete aus der Zentrale. DHCP-Weiterleitung zur Zentrale auf dem MPLS-Simulator.
Also, der IST-Zustand ist erfolgreich nachgebaut

Jetzt zum SOLL-Zustand:
Auf dem BYOD-Router ist auf LAN-4 der DHCP-Server aktiviert, die richtigen Leases aus dem "BYOD"Netz werden auch vergeben. Aber das NAT scheint nicht/nicht richtig zu greifen.
Ich habe es mit Policy-based und auch mit N:N probiert. Der MPLS-Router verwirft in beiden Fällen alle Pakete aus dem geNATeten "BYOD"-Netz "intruder detection" Paket von "ungeNATete IP" - Paket verworfen. Der MPLS-Router sollte die ungeNATete IP eigentlich ja gar nicht "kennen".

[backslash]

Hi Skeeve

Ich habe es mit Policy-based und auch mit N:N probiert. Der MPLS-Router verwirft in beiden Fällen alle Pakete aus dem geNATeten "BYOD"-Netz "intruder detection" Paket von "ungeNATete IP" - Paket verworfen. Der MPLS-Router sollte die ungeNATete IP eigentlich ja gar nicht "kennen".

Du hast den MPLS-Router auch über eine IPoE-WAN-Strecke angebunden? Für NAT wird in jedem Fall eine WAN-Verbindung benötigt (obwohl: für das N:N-NAT mußt du ja schon den Namen der WAN-Verindung eingetragen habe - ohne geht's schließlich ja nicht).
Hast du nach dem Einrichten des N:N-NAT die MPLS-Verbiundung auch mal kurz getrennt? Das ist für N:N-NAT zwingend nötig - wenn das dann nicht funktioniert, dann hast du dich vertippt...
Mit der Firewall-Regel (policy based NAT) muß das eigentlich sofort funktionieren - auch ohne die WAN-Vernindung zu trennen...

Gruß
Backslash

[Skeeve]

Hi Backslash,
hmmm, ich glaube ich habe den Knackpunkt verstanden. NAT geht bei Lancom immer nur gegen WAN?!
Bei der N:N-Konfig hatte mich die Gegenstelle schon etwas stutzig gemacht, da ich aber keine habe, habe dann einfach einen Namen "erfunden".
Da ich die Konfig so anwenden konnte, dachte ich auch es ist OK so. Der BYOD-Router hat ja keine WAN-Gegenstelle mehr, das ist ja mein Problem.

Dann habe ich jetzt wohl doch ein Problem... und muss mir überlegen ob ich nicht doch den Bandbreitenverlust durch die Tunnel in kauf nehme.
Man, daheim habe ich 50€ Hardware mit OpenWRT, da ist das kein Problem, so halte ich das ganze China SmartHome-Zeug unter Kontrolle, hätte nicht gedacht dass das mit den guten Lancom-Komponenten so ein Problem ist.

[backslash]

Hi Skeeve

hmmm, ich glaube ich habe den Knackpunkt verstanden. NAT geht bei Lancom immer nur gegen WAN?!

genau.

Dann habe ich jetzt wohl doch ein Problem... und muss mir überlegen ob ich nicht doch den Bandbreitenverlust durch die Tunnel in kauf nehme.

wenn du vorher den 1781 für die MPLS-Leitung genutzt hast, dann sollte es jetzt genau so gehen. Wo siehst du Bandbreitenverlust?

Man, daheim habe ich 50€ Hardware mit OpenWRT, da ist das kein Problem, so halte ich das ganze China SmartHome-Zeug unter Kontrolle, hätte nicht gedacht dass das mit den guten Lancom-Komponenten so ein Problem ist.

auf so primitives Bashing lohnt es sich eigentlich nicht zu reagieren

Backslash

[Skeeve]

Den zweiten 1781 habe ich nur jetzt zum Testen hier im Labor, um die MPLS-Strecke die der Standort in Echt hat zu simulieren.
Vorher waren das eigene DSL-Leitungen, die wir jetzt eingespart haben.
Das mit dem Bandbreitenverlust wäre die Sache, wenn ich die BYOD-Clients wirklich per Tunnel zu mir in die Zentrale holen müsste um sie von hier dann ins Internet raus zulassen, Dein erster Vorschlag.

Aber ich vermute wir haben eh aneinander vorbei geredet, bzw. ich erwähnte es, mein Stresslevel ist derzeit extrem hoch und ich habe es schlecht ausgedrückt, darum auch sorry fürs bashing, ich bin mega frustriert dass das soviel Zeit frisst und nur so eine "kleine" Baustelle neben den vielen anderen ist.

Ich habe jetzt auf dem BYOD-Router eine "echte" Gegenstelle eingerichtet, als wenn dieser an einem Provider-Router eine Feste-IP auf einem Switch-Port bekommt, nur das die IP dann eben eine aus dem LAN des Standortes ist. Damit scheint es zu gehen. Damit wird ja quasi auch automatisch geNATet. Ich war wahrscheinlich zu fixiert weiterhin nur die eine ETH-Schnittstelle zu nutzen, dabei kann ich den ganzen Router nutzen.

Danke für Deine Unterstützung!