VLANs, Regeln; Gateways? uff, sehe nicht durch

Started by MarroniJohny, July 13, 2024, 09:30:08 PM

Previous topic - Next topic
July 13, 2024, 09:30:08 PM Last Edit: July 13, 2024, 10:42:09 PM by MarroniJohny
Hi

Versuche mich kurz zu halten. Bin seit 10 Jahre bei Zyxel zu hause, bzw. Zyxel bei mir. Da komme ich recht gut klar mit. Habe eine 10 GbE Anbindung über Fiber, im Moment doppelt NAT. Liegen 4 Fasern hier, und möchte den Provider wechseln. Darum habe ich mir eine 10 GbE Firewall gebaut, mit 6x Kupfer. Da baue ich dann aber noch eine SFP+ Karte ein für das WAN.

Leider kann man nur 4 Pics posten. Habe schon mehr vorbereitet. Ethernet seht ihr in den beiden Pics "EthernetZywall" und "EthernetOpnsense", wobei letzeres mein aktueller Versuchsaufbau ist, um den es geht im Moment. Ich möchte vom produktiven untagged 101, 102, 104 und 200 am Server weg kommen, da fahre ich mit 4 Strippen drauf. Ziel ist mit der Sense diese 4 Netzwerke neu getagged mit einer einzelnen 10 GbE Strippe anzufahren. Bzw. das läuft schon soweit. Die VMs an den entsprechenden VLANs beziehen brav die gewünschten Adressen per DHCP.

Nun habe ich aber das Problem mit den Firewall Regeln. Hätte ja gerne Bilder gepostet von den entsprechenden Regeln, aber bin schon beim maximum. Bei den LAN Regeln hat es eine Regel drin "allow all" eingehend. Das verwirrt mich maximal, müsste das nicht ausgehend heissen? Also habe ich jetzt mal stur die Regeln bei den betreffenden VLANs auch mit rein genommen. So komme ich an allen VLANs/Gästen raus ins Internet. Nun kann ich aber zwischen den VLANs pingen. Wenn ich da als Ziel "WAN Schnittstelle" wähle, komme ich nicht mehr raus.

Was muss ich da in den VLANs genau für default Regeln anlegen, damit ich raus komme, aber die VLANs untereinander isoliert sind?

Ahja, Desktop und Server sollen direkt an der Firewall hängen, auch später dann produktiv. 10 Gbit Switch ist nicht vorgesehen.

Gruss und danke.

July 14, 2024, 02:54:22 PM #1 Last Edit: July 14, 2024, 02:56:13 PM by kruemelmonster
Quote from: MarroniJohny on July 13, 2024, 09:30:08 PM
....
Bei den LAN Regeln hat es eine Regel drin "allow all" eingehend. Das verwirrt mich maximal, müsste das nicht ausgehend heissen? Also habe ich jetzt mal stur die Regeln bei den betreffenden VLANs auch mit rein genommen. So komme ich an allen VLANs/Gästen raus ins Internet. Nun kann ich aber zwischen den VLANs pingen.
...

"allow all" eingehend erlaubt genau das. Eingehenden Verkehr (in Richtung zur Sense) nach überall hin. Wenn du dicht machen willst (habe ich auch so gemacht) auf jedem LAN/vLAN augehend blockieren und nur gewünschte Verbindungen durchlassen. Hat den Vorteil, das du nicht jede Verbindung nach außen explizit erlauben musst. Eingehend dicht machen geht auch. Ist aber mehr Arbeit, jeden gewünschten Verkehr nach außen zu erlauben.
Mini-PC; Celeron N5105; 16GB RAM; 4 x i226

July 15, 2024, 11:24:05 AM #2 Last Edit: July 15, 2024, 11:28:48 AM by lewald
Um die Aufgabenstellung, dass die VLANs ins Internet dürfen,
aber untereinander nicht kommunizieren sollen zu lösen,
besteht die Möglichkeit, das mit einer Firewall-Regel und einem Alias zu erledigen.

Hierzu legt man ein Alias an, welches die IP-Bereiche von lokalen Netzwerken definiert.

Ensprechend RFC1918. https://www.rfc-editor.org/rfc/rfc1918

10.0.0.0        -   10.255.255.255  (10/8 prefix)
172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

In OpenSense bitte zu Firewall->Aliases gehen.
Dort auf plus (Hinzufügen) drücken.
Dem Eintrag einen Namen geben -RFC 1918 beispielsweise-.
Beim Typ Networks auswählen und jetzt die Bereiche anlegen welche zum RFC1918 gehören.
Damit hat man ein Alias, der die Netzwerke definiert, die zum RFC 1918 Bereich gehören.

Nun muss noch eine Firewall-Regel erstellt werden, welche alle Ziel Netzwerke außer den RFC1918 erlaubt.
Hierzu geht man unter Firewall->Regeln.
Auf dem passende VLAN, Regel hinzufügen via Plus (hinzufügen).
Beim erstellen der neue Regel, (Action=Pass) ist, (Richtung= in) und als (Ziel= das angelegte Alias- hat).
Wichtig ist (Ziel / Umkehren) auf an.
Dadurch erreicht man das die Regel umgekehrt wird.

Nun ist alles außer dem Ziel (Alias) erlaubt.

Achtung. Sollten im lokalen Netzwerk DNS Server oder andere dienste laufen, welche nicht direkt im jeweiligen Vlan sind muss für diese jeweils eine Allow Regel definiert werden.
Diese muss vor der RFC1918 Regel sein.

Die Regel sollte auf jedes Vlan gepackt werden welches gesichert werden soll.

Quote from: MarroniJohny on July 13, 2024, 09:30:08 PM
Bei den LAN Regeln hat es eine Regel drin "allow all" eingehend. Das verwirrt mich maximal, müsste das nicht ausgehend heissen?

Zumindest diesen Teil kann ich (hoffentlich) beantworten:
Die Richtung (in/out) ist aus der Sicht des Firewalls zu sehen. Ein Request von einem Rechner im LAN in das Internet ist inbound/eingehend auf dem entsprechenden LAN-Interface und outbound/ausgehend auf dem WAN-Interface.

D.h. eine Regel, wie du sie beschreibst, erlaubt Netzverkehr, der am LAN-Interface ankommt (also im LAN-Netz seinen Ursprung hat), in Richtung aller anderen Interfaces, insbesondere auch ins WAN-Interface.

Okay, ich habe das mit den VLANs und welche Interfaces mit wem reden dürfen mal eingerichtet und durch gepingt. Ist auf den ersten Blick verwirrend, aber mit der super Anleitung von @lewald hat das geklappt soweit. Danke dafür.

Von aussen ist noch nichts beregelt, muss mir erst noch paar 10 Gbit NICs holen, bevor ich da von der Zywall zur opnsense switche.

Hi

Habe jetzt noch überall 10 Gbit Karten in den Clients und dem Server eingebaut. Wird Zeit, dass ich die Sense mal produktiv gehen lasse dann. Von der OPNsense fahre ich jetzt einige VLANs getagged mit einer Strippe auf den Server. Auf dem Server habe ich einen ESXi vKernel angelegt, der ist innerhalb des VLANs auch erreichbar. Aber wenn ich von einem physischen Gateway (Desktop, hängt direkt an der Firewall) auf den vKernel kommen will, was muss ich da genau beregeln?

Beim physischen Gateway habe ich allow all Regeln:

You cannot view this attachment.

Beim VLAN wo der Kernel drin ist diese Regeln:

You cannot view this attachment.


You cannot view this attachment.


Komme aber leider nicht vom Pilot Netzwerk auf den vmkernel in VLAN LAN_Server1 Netzwerk. Was mache ich da falsch?

Gruss und danke!

Die Regeln am Pilot Netzwerk können schon nicht mehr erlauben. Es ist wohl eher ein Routing-Problem.

Die Fähigkeiten eines "ESXi vKernels" kenne ich nicht. Kann der überhaupt routen? D.h., hat der auch ein Default Gateway (richtig) konfiguriert?
Falls er die Optionen gar nicht hat, müsstest du Zugriffe auf ihn mittels einer Outbound NAT Regel masqueraden.

December 29, 2024, 09:50:56 PM #7 Last Edit: December 29, 2024, 09:56:36 PM by MarroniJohny
Hi

Ja danke. Nein, man kann dem vmkernel auch gar kein Default Gateway zuweisen. Der soll idealerweise auch gar nicht nach aussen telefonieren dürfen. In meinem bisherigen Netzwerk habe ich den vmkernel sogar in einem separaten VLAN, das komplett nicht nach aussen telefonieren darf. Schon alleine wegen dem NFS Share, wo die VMs drauf liegen. Weil die haben kein Passwort.

Also hier müsste ich das einrichten, damit ich vom Pilot Netzwerk auf den vmkernel komme? Muss ich da auf "Hybride Erstellung ausgehender NAT Regeln" umstellen?


You cannot view this attachment.


Was ich jetzt gesehen habe, wenn ich die Adresse vom vmkernel per DHCP beziehen lasse, dann ist der erreichbar. Aber dann kann er wahrscheinlich wieder nach aussen telefonieren, was ich nicht will. Ich habe ihm nun in Leases ISC DHCPv4 eine statische Adresse ohne Gateway zugewiesen, nun ist er natürlich nicht mehr erreichbar. Wenn ich auf dynamisch beziehen gehe und einen fixen lease eintrage, was muss ich da eingeben in der Sense? Jetzt im Moment komme ich auf den ESXi drauf, aber noch unter falscher Adresse (aus dem DHCP Pool zugewiesen).

So ist er momentan erreichbar, aber unter falscher Adresse noch. Ich hätte den gerne unter 192.168.29.140.

You cannot view this attachment.

Quote from: MarroniJohny on December 29, 2024, 09:50:56 PMJa danke. Nein, man kann dem vmkernel auch gar kein Default Gateway zuweisen.
wenn ich die Adresse vom vmkernel per DHCP beziehen lasse, dann ist der erreichbar.
Dazu braucht er ein Gateway.
Heißt also, wenn er die IP automatisch zieht, setzt er auch das Gateway, das er vom DHCP zugewiesen bekommt.

Das "nach außen telefonieren" würde ich mit Firewall Regeln am Interface in OPNsense unterbinden.

Ansonsten, für das Masquerading müsste der Hybride Modus im Outbound NAT aktiviert werden. Dann werden Benutzerregeln vor den automatischen geprüft und ggf. angewandt.

Die Regel wäre dann:
Interface: das, an dem der vKernel hängt
Quelle: LAN, oder das, von dem du darauf zugreifen möchtest
Ziel: vKernel IP
Translation: Interface Adresse

Protokoll und Ziel-Port kannst du auch noch einschränken, wenn gewünscht.

December 29, 2024, 11:27:59 PM #9 Last Edit: December 29, 2024, 11:41:51 PM by MarroniJohny
Okay, alles klar. Hätte ich mir auch selber denken können. Aber im Moment habe ich mit den paar Geräten so viele Strippen, da sehe ich selbst nicht mehr wirklich durch. Ist auch alles super verknotet und liegt im Dreck das Rig. Kommt Zeit, kommt Rat.

Problem ist halt auch, dass ich an der neuen Firewall keinen Switch habe. In einem anderen Forum hatten die mir geraten, nimm irgend einen Mini PC mit einer 10 Gbit Dual Karte mit Switch. Ich wusste es dann halt besser, und habe mir eine Haswell Firewall mit drei X540 gebaut, also sechs 10 Gbit Ports. Werde dann noch eine quad Gbit NIC dazu stecken. Dachte, so kann ich mir den Switch sparen, aber war mal wieder selten dämliche Idee.

Bei der Zyxel ist das bisschen schöner gelöst, da kann man Netzwerke und VLANs beliebigen NICs zuweisen, auch mehreren. Bei der sense müsste ich wohl mit bridges arbeiten, aber das ist andere Baustelle. Weil wäre schon schön, wenn das "Pilot LAN" im selben VLAN wie das "VLAN 29 Server 1" stecken würde, dann müsste ich da auch nicht gross was beregeln. Weil im Moment hängt jeder Crap auf seinem eigenen Gateway.

So sieht das auf der Zywall aus, das war/ist super komfortabel:


You cannot view this attachment.

Aber bei der Zywall war die Lernkurve auch nicht ohne. Hätte mir ja wieder eine geholt, aber die sind halt super teuer und im 10 Gbit Bereich sowieso.


Weder OPNsense noch ESXi können einen Switch ersetzen, maximal eingeschränkt emulieren. Und da ein managed Switch weniger kostet als eine deiner Netzwerkkarten, und weniger Strom verbraucht, muss wirklich die Frage erlaubt sein, was das ganze soll? ;)
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

December 30, 2024, 12:14:50 AM #11 Last Edit: December 30, 2024, 12:18:47 AM by MarroniJohny
Ja, wie soll ich sagen. Ein managed 10 Gbit Switch mit ein paar Ports kostet halt auch CHF 500.- aufwärts. Dachte mir, mit dem X10SLH-LN6TF könnte ich mir den Switch sparen, und damit Server getagged, sowie Pilot- ond Copilot Sitz "bequem" mit 10 Gbit anbinden. Aber im Endeffekt hat mich die neue FW inkl Ersatzteile vierstellig gekostet. :/

Handelt sich um eine Flugsimulator Community.

www.flugsimulatoren.ch

Ja, der Switch wäre jetzt sicher komfortabler, aber das Kind ist nunmal schon im Brunnen. Ein 1 Gbit Switch ist vorhanden, der wandert dann auch mal noch an die neue Firewall für den ganzen Wulst an weiteren Geräten. Weil hier herrscht WLAN freie Zone. Übertreibe da nicht, wenn ich sage viele Strippen. Soll dann aber noch bisschen reduziert werden, so hoffe ich zumindest. Drum fahre ich dann den Hauptserver neu getagged an, an dem hängen atm 6 Strippen.

Problem sind dann auch noch Sachen wie IPMI. Weil die laufen dann ja nicht mehr, wenn die FW down ist. Da werde ich wohl noch einen kleinen Switch dafür hin stellen dann. Zu Sachen wie NFS Share für den ESXi muss ich mir dann auch noch Gedanken machen. Stehe da noch in der Findungsphase. Der ganze Wechsel soll dann auch möglichst unterbruchsfrei von statten gehen, lass meine Community nicht gerne hängen wegen meinen Experimenten.

Quote from: MarroniJohny on December 30, 2024, 12:14:50 AMJa, wie soll ich sagen. Ein managed 10 Gbit Switch mit ein paar Ports kostet halt auch CHF 500.- aufwärts.

1. Weshalb brauchst du zwingend 10G?
2. 8x SFP+ - 269,- USD

https://mikrotik.com/product/crs309_1g_8s_in
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

December 30, 2024, 01:09:55 AM #13 Last Edit: December 30, 2024, 01:55:07 AM by MarroniJohny
1. Ich brauch nicht zwingend 10 Gbit/s. Habe halt eine 10 Gbit Anbidung. Stand heute würde ich eine Flamme kleiner kochen, und bei 1 Gbit bleiben. War halt mehr so ein "will haben Ding". Meine Zywall macht halt bei einem einzelnen TCP Stream bei 500 Mbit zu, das wollte ich mal ersetzen. Ausserdem macht die mit dem uralt Switch richtig Krach. Aber schon auch schön, wenn die Uploads meine SATA SSD bisschen stressen können. Nötig ist das sicher nicht, ja. Habe im Monat unter 5 TB im Upstream, und da bei meinen "Kunden" eh nie die passende Gegenstelle.


You cannot view this attachment.


2. Hier ist alles auf Kupfer. Ist glaube ich besser im Raucherhaushalt. Einzige Fiber ist das WAN.


Quote from: MarroniJohny on December 29, 2024, 11:27:59 PMWeil wäre schon schön, wenn das "Pilot LAN" im selben VLAN wie das "VLAN 29 Server 1" stecken würde, dann müsste ich da auch nicht gross was beregeln.
Was wäre daran schön? Nur sich die Regeln für die Zugriffe zu ersparen?

Ist es nicht aus Sicht der Netzwerksicherheit nicht besser, wenn OPNsense den Datenverkehr zwischen den Geräten kontrolliert?

Du könntest natürlich eine Bridge über die Netzwerksschnittstellen auf OPNsense spannen. Ich habe auch mehr als eine eingerichtet. Doch würde ich das nur empfehlen, wenn wirklich Layer 2 Protokolle über die Netzwerkanschlüsse hinweg benötigt werden. Das ist bei mir der Fall.
Von den Anforderungen, die du beschrieben hast, trifft das aber nicht zu.
Das Pilot VLAN darf laut deinen Regeln ohnehin alles. So sollte der Zugriff möglich sein. NFS brauchst du vermutlich auch noch von anderen Subnetzen aus. Da müsstest du ggf. noch entsprechende Regeln einrichten.

Wenn das Routing des vKernel klappt, wenn er seine Netzwerkkonfiguration vom DHCP bekommt, würde ich das ebenso einrichten. Im DHCP (ISC) kannst du ein statisches Mapping einrichten, damit der vKernel immer dieselbe IP bekommt. So kannst du die Zugriffsregeln auf diese IP einschränken.
Ob das mit KEA auch möglich ist, weiß ich nicht.