Hi.
Ich habe heute den ersten Schritt in eine größere Welt getan — unsere OPNSense-Firewall läuft (3 Schnittstellen, von denen einmal 10 GBit LAN vorhanden ist, einmal 1GBit WAN, einmal 1Gbit OPT). Es ist alles natürlich noch nicht produktiv, aber morgen soll es in Sachen Konfiguration weitergehen und da fangen die Fragen an:
Der Umstieg vom IPFire ist schon gewaltig, da nun so ziemlich alles anders ist. Daher vorab ein paar Fragen: Es gibt ja ein “fertiges” .ova-Image für die VirtualBox, das man einspielen kann. Ich habe nun aber gleich Version 19.1.1 installiert und habe anschließend sofort ein Update angeworfen, so dass alles aktuell ist. Bringt es was, die Konfiguration des ova-Images einzuspielen? Bei uns heißen die Subnetze/VLANs derzeit alle nicht 10.0.0.x/24 wie das im neuen Setup vorgesehen ist. Auch hier bin ich nicht sicher, ob ich nun alles umstricken muss oder ob ich es so lassen kann. Irgendwann meinte Holger schon mal, dass es einen Schalter “-do-it-like-babo” geben wird. Gibt’s da schon genauere Erkenntnisse?
Da die unterschiedlichen Netzwerke nun ja keine Farben (grün, rot, blau, orange) mehr besitzen, frage ich mich die ganze Zeit, ob man die unter OPNSense nicht trotzdem aufgrund der Macht der Gewohnheit weiterhin so benennen kann (Kommentarfunktion o.ä.). Gibt’s da eine Möglichkeit?
Ich möchte natürlich die dicke 10 GBit-Leitung für die ganzen VLANs bzw “Farben” nutzen, um alles (?) tagged auf diese Leitung zu bringen. Hat sich da schon jemand durchgebissen und hätte ein paar Tipps?
So schöne Dinge wie “URL-Filter” oder “OpenVPN-Zertifikat via Schulkonsole erstellen lassen” fallen im neuen Setup weg, oder?
Mehr fällt mir im Moment nicht ein – daher zunächst bis hierhin.
Da stimme ich dir voll zu. IPFire vereinfacht viele Dinge, aber es fehlen dafür auch einige Dinge einer „echten“ Firewall.
Diesen Schalter gibt es bereits für das Skript linuxmuster-prepapre.
in pfSense kann man die Interfaces direkt umbenennen. Ich vermute mal, dass das auch in OPNSense geht.
Ich denke, die Doku von OPNSense hilft dir hier weiter (wobei ich da auch die Schnelle nichts gefunden habe). Oder hier: https://homenetworkguy.com/how-to/configure-vlans-opnsense/
Im Prinzip kannst du die ganzen „tagged“ Interfaces wie jedes andere (physische) Interface verwenden.
URL-Filter wird es bestimmt geben, OpenVPN per Schulkonsole eher nicht, vermute ich mal.
Der Umstieg vom IPFire ist schon gewaltig, da nun so ziemlich
/alles/ anders ist. Daher vorab ein paar Fragen: Es gibt ja ein
“fertiges” .ova-Image für die VirtualBox, das man einspielen kann.
Ich habe nun aber gleich Version 19.1.1 installiert und habe
anschließend sofort ein Update angeworfen, so dass alles aktuell
ist. Bringt es was, die Konfiguration des ova-Images einzuspielen?
Bei uns heißen die Subnetze/VLANs derzeit alle nicht 10.*0.0*.x/24
wie das im neuen Setup vorgesehen ist. Auch hier bin ich nicht
sicher, ob ich nun alles umstricken muss oder ob ich es so lassen
kann. Irgendwann meinte Holger schon mal, dass es einen Schalter
“-do-it-like-babo” geben wird. Gibt’s da schon genauere Erkenntnisse?
den schalter gibt es und er funktioniert auch.
Ich werde ihn bei mir in der Schule verwenden, weil ich nicht alles
umstricken will (Switchconfigs von ca. 20 Switches und die gesammte
workstations Datei mit > 200 Einträgen).
Ich verwende -do-it-like-babo schon seit letztem Jahr in den
Testumgebungen die ich zum Downlaod bereit stelle.
Und ich habe letzten Dezember eine Testmigration gemacht mit den Daten
meiner Schule ( ich hab dann aber alle Schülerdaten rausgeschnitten,
weil das echt zu groß gewesen wäre für meine VM). Das hat geklappt: ich
hatte danach ein in die 7er migriertes echtes 6.2 System mit
10.16.0.0/255.240.0.0 Netz.
Ich konnte meine Images auf einen Client klonen, er bootete, ich konnte
mich anmelden und meine Homeverzeichnisse waren da.
Da die unterschiedlichen Netzwerke nun ja keine Farben (grün, rot,
blau, orange) mehr besitzen, frage ich mich die ganze Zeit, ob man
die unter OPNSense nicht trotzdem aufgrund der Macht der Gewohnheit
weiterhin so benennen kann (Kommentarfunktion o.ä.). Gibt’s da eine
Möglichkeit?
weiß ich nicht: ist mir auch wursch.
Mein Speicher ist groß genug dass ich zwei Begriffe rein bekommen:
LAN =Grün
WAN = ROT
OTP = Blau
Ich möchte natürlich die dicke 10 GBit-Leitung für die ganzen VLANs
bzw “Farben” nutzen, um alles (?) tagged auf diese Leitung zu
bringen. Hat sich da schon jemand durchgebissen und hätte ein paar
Tipps?
leider nein: ich lasse das tagging den Virtualisierer machen.
So schöne Dinge wie “URL-Filter” oder “OpenVPN-Zertifikat via
Schulkonsole erstellen lassen” fallen im neuen Setup weg, oder?
vom openVPN weiß ich jetzt nicht, aber ich meine der Proxy filtert schon.
Ob das nun URL Filter heißt oder irgend wie anders: mal schauen.
Ich halte aber von solchen Filtern nicht viel, da sie eigentlich
unbrauchbar sind (sobald jemand auf die Idee kommt eaus dem htt ein
https am Anfang zu machen, oder wenn man eine Seite besucht die, wie
inzwischen die meisten, sowiso auf https umleitet: das wird nicht besser
werden).
Vom Man in the middle halte ich auch nichts: bleibt DNS Filterung.
So mache ich das nun.
Ist halt nicht durch SchuKo zu steuern: das ist an oder es ist aus;
Systemweit.
Hi.
Ok, gut zu lesen. So würde ich es auch auf der Serverseite machen wollen, wenn’s soweit ist.
Ich habe hier allerdings aufgrund des Subnettings lauter Netzmasken der Form 255.255.255.0. Das dürfte ja prinzipiell genauso laufen?
Die Sache mit den Begriffen “LAN -> Grün”, “WAN -> Rot” und “OPT -> BLAU” ist schon klar, doch es ist aufgrund der ganzen VLANs halt komplizierter bzw bin ich nicht ganz sicher, ob ich auf der Firewall nun auch alle einzelnen VLANs anlegen muss wie sie im Switch existieren. Im IPFire war ja das grüne Netz einfach ein Netz mit diversen Subnetzen. Unter OPNSense kann man aber ganz bequem daraus eigene/getrennte VLANs machen, die dann auch getrennt behandelt werden.
Ich habe das im OPNSense WebGUI bereits gemacht und alle VLANs so eingerichtet, wie wir sie hier nutzen. Auch das Umbennen hat dort wunderbar geklappt, so dass es nun nicht mehr OPT1 bis OPT10 heißt, sondern direkt “Fachraum”, … usw. Man hat also eine durchgängige Namensgebung, was die Sache schon mal vereinfacht!
Da ich jedoch alle VLANs tagged auf der 10 GBit Leitung haben möchte (vom L3-Switch zur Firewall alles auf einer dicken Zuleitung), suche ich weiterhin, wie/wo ich das unter OPNSense einstellen kann. Finde ich bisher aber nicht. Der einzige Punkt wäre evtl “Bridge”/“Brücke” aber da kann man imho nicht festlegen, welche VLANs tagged und welche untagged laufen sollen?? (Dieser Punkt vereinfacht sich tatsächlich, wenn man die FW virtualsiert … aber die Diskussion hatten wir ja schon).
Steht eigentlich in dem Link, den ich dir weiter oben geschickt habe. Du erstellst das VLAN und sagst auf welcher physikalischen Leitung es ankommt und kannst dann im zweiten Schritt ein logisches / virtuelles Interface mit diesem VLAN erstellen.
Es gibt ja nur ein untagged VLAN, alle anderen sind getaggt. Das untaggt hast du ja jetzt schon eingerichtet (dein LAN).
Hi Stephan. Ja, ich bin so vorgegangen, wie es in deinem Link von oben beschrieben wird. Das hat auch alles geklappt – dennoch bin ich “etwas” planlos : Der Switch liefert auf der Leitung nun alle VLANs aus (1 VLAN untagged, der Rest tagged). Die Firewall macht daraus nun scheinbar ohne weiteres Zutun lauter untagged Devices (virtuell) und diese kann man sich auf virtuelle Interfaces legen – richtig so?
Aber wie geht es weiter? Bzw ist das Vorgehen so überhaupt empfehlenswert? Ich frage auch deshalb, weil man auf diese Art ja für jedes VLAN eigene Regeln benötigt (mit Gruppen habe ich noch nichts gemacht), um z.B. den Zugriff auf das Servernetz zuzulassen, oder?
Es ist ja schön, dass man alle VLANs in der FW getrennt lassen kann – aus Sicherheitssicht top! Aber ist es auch aus Sicht der Verwaltung vernünftig? Wie gesagt: Im IPFire war das ja vorher auch nur ein einziges Netz (grün – jetzt LAN) und fertig!?? Falls diese Dinge im .ova bereits alle eingestellt sind, würde ich mir Konfiguration evtl doch noch besorgen…
würde ich so nicht machen. Dann jage ich ja den ganzen Traffic immer durch die OPNsense. Ich würde weiterhin den L3 Switch in die VLANS routen lassen. Das dürfte performanter sein. Denn trotz der 10 GE Interface muss die FW ja auch den Datendurchsatz bringen.
Und jedes RaumVlan auf der FW anzulegen ist auch nicht so spassig. Ferner hast du dann evtl das Problem. Steht deine OPNsense, dann geht im Netz nix mehr.
Hallo Thomas.
Ok. Das heißt, dass es dann tatsächlich einfach bei “LAN, WAN, OPT” ohne die weiteren VLANs pro Raum bleibt, ja? Dann ist mir aber noch unklarer, wie ich die bestehenden Subnetze (z.B. 10.16.2.0/24 , 10.30.20.0/24 usw…) in der FW abbilde?! Es müssen ja dennoch Regeln für die Zugriffe auf die unterschiedlichen Subnetze her!? Das hat ein “import_workstations” ja aufgrund des pub.key-ssh-Zugangs auf dem IPFire bisher immer “automatisch” mit erledigt.
Ich hatte die FW übrigens aus genau dem Grund der Erreichbarkeit gerade nicht virtualsiert – aber da scheiden sich die Geister.
kommt drauf an wie du das realisieren willst.
Du kannst doch den L3 Switch Routen lassen und der routet alle Raumnetze in das Servernetz 10.0.0.0/24.
Die zentrale Routinginstanz mit den jeweiligen Netzen die dann in einem jeweils eigenen VLAN sind, ist der Core.
Damit bleibt der Traffic für das paed-Netz auf den Switches und alles was in DMZ, Internet etc geht, läuft über die OPNsense.
Hi.
Ok, ich sehe schon. Ohne eine gescheite Anleitung wird das schwer . Ich will das ganze natürlich möglichst genauso realisieren, wie es im Moment auch ist. Unser Aufbau ist laut Doku wie im 2. Bild.
Ich hatte die FW übrigens dediziert aufgesetzt, da ich auch einen getrennten OpenVPN-Zugang zum Management-Netz (alle Switche, Server, IMM, Hypervisor, …) haben wollte. Das wollte ich vom Rest “komplett” entkoppeln, und es sollte dennoch von außen erreichbar sein auch wenn der Server stehen sollte.
Daher dachte ich, dass ich dieses VLAN auf jeden Fall auf der FW brauche!
DMZ muss auch bis zur FW gelangen – daher muss die FW auch dieses VLAN kennen?!?
Ach ja – wo ich schon dabei bin: Ist es schlau, die FW für gewisse Bereiche als dhcp-Server laufen zu lassen? Oder ist das letztlich nur eine Frage des Geschmacks? Best practice?
OPNSense kann das ja alles ootb …
Thomas hat schon recht: die Firewall des paedMNetzes gehört, wie es
jetzt schon ist, ins Server VLAN.
Deine neue Firewall gehört überhaupt nicht ins grüne Netz sondern hängt
ja komplett außerhalb, also “vor” dem IPFire.
Dort kann sie im Server VLAN einen Fuß haben, und eben in Rot.
Willst du darüber ins Grüne Netz, so mußt du von dort aus den Weg über
den IPFire nehmen: ganz normal.
Du willst ja zusätzlich zum IPFire eine Firewall und nicht statt IPFire.
Ja, für den Moment ist das so … aber natürlich nicht langfristig. Im Moment ist das zu Testzwecken so, dass die FW einfach mit in ROT hängt. Dennoch ist mir nicht ganz klar, wie das aussehen muss, wenn „eines Tages“ der IPFire nicht mehr ist …
Ach ja: Da die OPNSense-FW im Moment in ROT ist (also WAN direkt an der FritzBox), kann ich natürlich im Moment problemlos mit weiteren OpenVPN-Zugängen herumspielen, ohne die Konfiguration des IPFire durcheinander zu bringen …
Genau, ein virtuelles VLAN Interface erscheint in der Firewall wie auch ein physikalisches - so als ob deine FW seeehr viele Netzwerkkarten hätte.
Ja, Regeln braucht es für jedes Interface. Ich weiß nicht, wie das in OPNSense gibt, aber in pfSense kann man sogeannte Floating Rules erstellen, die auch für mehrere Interfaces gelten (erleichtert die Verwaltung).
Mit dem IPFire ging es ja auch nicht anders
Das finde ich eine spannende Frage, @tjordan. Wahrscheinlich ist ein Switch performanter; ob und wie groß der Unterschied in einem wenig ausgelasteten Schulnetzwerk ist - keine Ahnung. Bei uns routet die Firewall alles. Fällt sie aus, hat mein ein Problem (hatten wir kürzlich :)), aber das gilt für den Switch ja genauso, Wenn der Core-Switch mal ausfällt, dann geht auch nichts mehr. Die wenigsten werden einen zweiten Core-Switch haben. IMHO ist es einfacher (und günstiger) neben der Hauptfirewall noch eine zweite (virtuelle) als Backup zu haben.
Ja.
Haben wir so - nur im LAN kümmert sich der LMN Server um DHCP.
Das wirkt sich nur in großen Umgebungen aus, wenn gerade Betriebsspitze ist. Im Normalbetrieb spielt das keine Rolle. Ich sag Mal Nachmittags um fünf stellt sich für die meisten Schulen die Frage nicht.
Es hängt davon ab, was die Firewall alles noch zusätzlich macht. Wenn die gleichzeitig auch noch ständig den kompletten Traffic nach Viren filtert, dann ist das für der Durchsatz im “grünen Netz” evtl nicht mehr der Bringer und je nachdem wie gut oder schlecht der Filter arbeitet kann das zu Fehlfunktion in der Lösung führen.
Wenn der Core ausfällt hat man ohnehin ein Problem, ob der nun routet oder nicht.
Wenn ich mein LAN über den Core Route spare ich mir einen Weg. So fasse ich das Paket nur einmal an. Sonst jage ich alles durch den Core zur Firewall um es dann geroutet über den Core zurück zu schicken und hab das gleiche Paket zweimal durch die gleiche Einheit geschickt.
ich habe gesehen, dass du pfSense anstatt OPNSense nutzt, wahrscheinlich „historische Gründe“? Der Unterschied dürfte aber gering ausfallen. Noch haben sich die beiden nicht soooo weit auseinander entwickelt, würde ich mal behaupten?!
Virenprüfung macht sie im Moment bei uns nicht; allerdings kommen schon ein paar VPN-Verbindungen dazu. Wir haben als L3-Switch neuerdings einen Cisco SG350X (mit besagten 10 GBit Leitungen). Der wird das schon stemmen – aber es wäre dennoch wichtig, wie man’s gleich richtig/performant anlegt.
Die ACL/ACE-Regeln sind im Moment ja auch schon vorhanden. Allerdings habe ich mir damals sagen lassen,dass das auf dem Cisco-Switch nicht 100%ig einstellbar ist (war da nicht was mit ingress/egress oder so??) bzw dass es umständlich(er) ist …!?
Der Grund war, dass pfSense in vielen Punkten IPFire überlegen ist (VLAN Support, Multi-WAN, Captive Portal, …). Wir sind bisher sehr zufrieden damit. Laut Entwicklern der OPNSense soll es ja kaum noch Gemeinsamkeiten im Code geben, die Features sind aber weiterhin sehr ähnlich. Wobei ich persönlich die Doku von pfSense besser / vollständiger finde. Inwieweit es perfomancetechnisch oder anderweitig große Unterschiede gibt, weiß ich nicht. pfSense ist auf jeden Fall weiter verbreitet. Die Entscheidung hier für OPNSense war ja auch eher eine Glaubensfrage
Den zweiten Aufbau finde ich sicher falsch: da eine zweite Firewall in
das Netzwerk als router (hat ja auch externen Zugang) eingeführt wird.
Kann ja sein, dass “man” das Heute so macht: ich mache es sicher nicht
so, da ich nach dem Grundsatz handle: “keep it simple”: kompliziert wird
es von Alleine: da brauch ich nicht helfen.
Also würde ich das nie machen: ich ahbe ein Netzwerk und das hat eine
Firewall: und das ist bei der lmn6.2 nun mal der IPFire.
Wenn du unbedingt eine OPNSense statt des IPFire willst (warum genau?),
dann bitte: setz dir die lmn7 hin, mach eine Migration und voila: da
hast du deine OPNSense.
Ich habe ja gar nichts dagegen, wenn du die OPNSense vor deinen IPFire
stellst: aber dann haben das die ganzen Grünen Netzwerke nichts zu
suchen: und mit dem L3 Switch hat sie auch nix zu tun.
Versteh mich nicht falsch: auch ich will in den nächsten Ferien eine
OPNSense mit in mein Netzwerk nehmen: aber nur, weil der BelWü Router
wegfällt: das soll dann die OPNSense übernehmen: damit ich noch immer
eine Firewall habe vor dem IPFIre, dem moodle, der Nextcloud … und all
den anderen Servern die da so rumwuseln.
kann es sein, dass du Michael falsch verstanden hast? Ihm geht es glaube ich um ein LMNv7 Setup (so wie es im Betreff steht und in den Bildern zu sehen ist (deshalb ist da auch kein IPFire).
: Der Switch liefert auf der Leitung nun alle VLANs aus (1 VLAN untagged, der Rest tagged). Die Firewall macht daraus nun scheinbar ohne weiteres Zutun lauter untagged Devices (virtuell) und diese kann man sich auf virtuelle Interfaces legen – richtig so?
. Ich will das ganze natürlich möglichst genauso realisieren, wie es im Moment auch ist. Unser Aufbau ist laut Doku 