Netzwerk ist auch nichts Triviales. Es gibt Lösungen für 400EUR, das was ihr heute habt, bis weit in den 5-stelligen Bereich, für eine normale Infrastruktur.
Und jede Lösung kann mehr als die jeweils Kleinere. Mit den Möglichkeiten steigt die Komplexität und der Preis. Vorwärts immer, rückwärts nimmer, sagte mal einer.
Man muss für sich entscheiden, was will ich und was bin ich bereit zu zahlen.
Dynamische FW-Regel (user based) haben nichts mit dem Routing zu tun. Es wird einfach nur geprüft, ob der nun auf 3389 da hin darf oder eben nicht.
Die Stacks in der FW sind getrennt, getreu dem OSI-Modell. Es gibt einen FW-ingressfilter, dann kommt der Routing-Stack und dann gibt es den FW-egressfilter. Ob da nun der Routingstack dazwischen ist oder nicht, ist für den FW-Stack ohne Belang.
Es ist ja nicht so, dass der Rechner nun plötzlich in ein anderes Subnetz kommt, nur weil du als Admin eingelogt bist. (ja, auch das kann man machen, wenn man will, dyn. VLAN assignment - 802.1X, kann man mal nach suchen, sind auffällig viele Switchhersteller dabei)
Mit einer L4-ACL kommt man auch soweit(statisch), aber das will man nicht machen, auch wenn es vermeintlich gleich ist.
(außer eben der ArubaCX 10000, der hat tatsächlich ne (oder 2) FW-DPU eingebaut, der kann/soll bis L7 FW machen.... man wird sehen was das wird)
active/passiv FW wäre der Mindeststandard.
Wie gesagt, die Verdichtung von zu viel Funktionalität auf ein Gerät birgt im Umstiegsszenario viel viel Arbeit und man verbrennt sich dabei gerne mal die Finger.
Wenn du von einer FW mit Routing auf eine andere Firewall umsteigst, birgt das viel Aufwand beim Umstieg.
1. Man muss L2/L3 auf das neue Konstrukt migrieren.
2. Man muss das Regelwerk migrieren
Das alles muss gleichzeitig passieren.
Du könntest heute ohne weiteres deinen 2930F Stack auf z.B. ein Aruba CX Stack migrieren oder auch auf einen Nexus Stack. Merkt keiner, du musst die FW-Regeln nicht anfassen garnichts. Du kannst an dem Routing rumspielen, L2, PVLAN und sonst was machen. Gehts es nicht, steckst du einfach alles wieder zurück. Kannst du auch nach 4 Wochen noch zurückstecken.
Bei einer FW muss du eben gleichzeitig noch das Regelwerk migrieren. Und dann hast du ein Problem. Erweiterst du das Regelwerk auf der neuen FW, musst du entweder alles sauberst dokumentieren, damit du wieder Zurückschwenken kannst, damit du in dem alten Cluster die Regel nachpflegen kannst. Oder aber du lebst mit dem ggf. vorhandenen Schmerz auf dem neuen Cluster.
EDIT:
Grundsätzlich bin auch bei
@RedMoon.
Dienstleister braucht man nicht zwingend, wenn man sich wirklich auskennt. Und ein IT-Leiter steckt auch nicht so tief im Thema, was man dem irgendwas von L2/3, VSX und sonstwas verkaufen muss.
ABER: So ein Unterfangen kann einem heute das Genick brechen oder aber auch in 7 Jahren, wenn die nächste Migration ansteht.
Man sieht an den Ausführungen schon, dass es mit einer Fritzbox nicht gemacht ist. Es gibt ca. 1000 Technologien, die jede für sich was kann und was nicht kann. In Kombination wirds interessant.
Und die Aufgabe ist es jetzt, mögliche technische Konzepte aufzumalen und dann +/- machen und dann was festlegen. (und der Verantwortliche muss das Tragen können)
Ob da nun Cisco, Aruba oder Ruckus dran steht, ist erstmal egal. Die Kochen alle mit dem selben Wasser. Wichtig ist, dass man erstmal die Technologien und Strukturen festlegt. Die Geräteauswahl ergibt sich dann Anhand der Vorgaben. Natürlich muss das auch mit dem Geldbeutel passen. Also nicht die krassesten Sachen auspacken, die am Ende einen Porsche im Rack bedeuten.
Ja, das ist nicht trivial. Wenn man das nicht selber kann, dann braucht man nen Partner, der sich auskennt. Dem gibt man mit, was man will (das bedarf auch etwas Wissen) und der soll einem dann was verkaufen.
Ich mache das btw. selber, habe aber, egal wie klein das Problem sein, min. 2 Lösungen die es abzuwägen gilt. Da gehts dann um techn. Komplexität, Wartbarkeit, Verständlichkeit, Migrationsmöglichkeiten und weiters.
Es ist verdammt einfach ein extrem komplexes Konstrukt zu bauen, mit allen Haken in der Featurelist der Switches (und die sind lang), nur muss das auch jeder andere verstehen, auch der, der den Support macht und nicht 24/7 Netzwerk bedient.
Von daher kann man alle Switches zu L2 degradieren und L3 auf der FW machen, technisch kein Thema.
Aber lass dir gesagt sein, wenn du ein paar PBR, NATs, multi Subnetz, OSPF und weitere Sachen auf der FW laufen lässt, dann gibt es am Ende nur noch einen Weg. Du bleibst im Upgradepfad vom Hersteller. Da ist nichts mehr mit Schwenken von Checkpoint auf Fortinet oder Palo Alto oder sonst wie.
Wenn du das willst, machst du das wie der Predator. Die ziehst die ganze Wirbelsäule des Netzwerk raus und fängt an daran rumzuarbeiten.
Sprich, willst du vom Hersteller A weg, weil der dir zu teuer ist, die Möglichkeiten scheiße sind oder einfach nur der Support schlecht, dann wird es direkt mit "Millionen"operation und das am offenen Herzen.
Das sind dann immer die Baustellen, wo die Admins und Integratoren die Osterwochenenden oder die Tage zwischen den Jahren verballern. Ich persönlich kann mir besseres vorstellen als Migrationen immer nur zu 2 Zeiträumen im Jahr zu machen, mal unabhängig, dass ich mir persönlich was besseres für die Tage vorstellen kann.
Nur meine persönliche Meinung. Ich weiß, dass es immer so einfach ist, alles auf der FW zu machen, aber wehe dem, du musst da mal wirklich ran.
