DMZ oder besser DMZs?



  • Ich hoste ein paar Sachen öffentlich von zu hause. Ich verlasse mich dabei auf (automatische) Updates etc., wie gut aber jedes Projekt noch upgedatet wird, kann ich nicht wirklich beurteilen.
    Da die Sachen alle in VMs laufen und virtuelle Adapter nichts kosten, ist meine Überlegung nun, diese Server zu separieren und jedem sein eigenes virtuelles Interface zu geben und daraus jeweils eine DMZ zu machen.

    Was haltet ihr von der Idee? Wie wäre der Overhead einzuschätzen wegen eigenem DHCP usw., ich würde jetzt schätzen gering. Wobei beim Thema IPv6 könnte es etwas ausarten und ich müsste den /48 von HE auspacken.


  • LAYER 8 Moderator

    @Bob-Dig said in DMZ oder besser DMZs?:

    Da die Sachen alle in VMs laufen und virtuelle Adapter nichts kosten, ist meine Überlegung nun, diese Server zu separieren und jedem sein eigenes virtuelles Interface zu geben und daraus jeweils eine DMZ zu machen.

    Wenn die Büchsen nichts miteinander zu tun haben müssen/sollen, spräche m.E. nichts dagegen. Ist eher die Frage nach Segmentierung vs. Mikrosegmentierung. Letzteres hat natürlich mehr Aufwand mit Interfaces, VLAN, Regeln etc., dafür steht dann eben auch die Kiste allein in ihrem Netz und darf nur genau das was du sagst. Und kann nicht andere, nebenstehende Kisten mit angrabbeln.

    Von daher - why not. Und das /48er HE.net musste ich schon lange anfangen ^^ Muss jetzt aber nochmal komplett von vorn anfangen, weil sich das Prefix geändert hat (anderer Peer).

    Ich würde da wegen einer Kiste ggf. nicht mal DHCP großartig anfangen, sondern direkt einfach statisch konfigurieren :)

    Grüße



  • @JeGr Hallo Jens,

    in einem anderen Thread habe ich gerade deine Empfehlung gelesen, für eine DMZ auch "diese Firewall" zu blocken, da dies auch die WAN-IP inkludieren würde.
    Gut, wäre ich als Anfaenger natürlich nie drauf gekommen. 😁

    Meine Noobfragen darauf:

    Kann ein interner Host auf der WAN-IP mehr Schaden anrichten, als es ein externer könnte?

    Oder greifen tatsächlich einige Schutzmaßnahmen hier nicht, bspw. pfBlocker?

    Oder wäre es mehr ein Problem des Monitorings?

    Eine weitere Frage, ich habe hier einen xmpp-Server zu Hause, den ich mit einem internen Client ebenfalls an der WAN-IP anspreche und kein Split-DNS nutze. Da ich auch keine NAT-Reflection eingerichtet habe, geht das vermutlich nur, weil der Server auf einem anderen Interface gehostet wird. Würde ich hier nun ebenfalls "diese Firewall" blocken, hätte das negative Auswirkungen? Aber ich vermute mal nein.


  • LAYER 8 Moderator

    @Bob-Dig said in DMZ oder besser DMZs?:

    Kann ein interner Host auf der WAN-IP mehr Schaden anrichten, als es ein externer könnte?

    Ja. Gehen wir vom normalen Spielplatz aus:

    • WAN Interface: Nur erlaubt was muss. WebUI DEFINITIV nicht. Vllt. OVPN offen, sonst nüscht.
    • LAN Interface: Aus Faulheit LAN allow any rule drin. LAN darf somit eh alles.
    • DMZ Interface: Soll NICHT ins LAN können, stehen Server oder sonstwas drin, von da aus darf man nur ins Internet (wegen Updates o.ä.) aber sonst nichts. Alles andere (von außen oder LAN) darf nur reinconnecten, aber sonst darf die DMZ herzlich wenig.

    Jetzt schotten wir die DMZ ab.

    • Erlaubt Ping auf pfSense zum Debugging
    • erlaubt DNS/NTP auf pfSense
    • rejected alles was DMZ_net auf DMZ_net ist (wäre standard)
    • rejected alles RFC1918, damit DMZ nicht in andere lokale Netze darf
    • allow any (damit ins Internet)

    Und Tada, mit dem Set haben wir die externe IP der Firewall auf dem WAN vergessen. DMZ Host verbindet sich jetzt mit <firewall_IP:port> -> geht nicht. Klar wir haben DMZ auf DMZ Netz geblockt und im DMZ Netz natürlich auch die DMZ IP der Firewall. LAN IP der Firewall geht auch nicht -> RFC1918 rejected.
    Aber <ext_ip:port> der Firewall ... hmm ... ist ja eine öffentliche IP und die haben wir erlaubt! Tadaa, da das Paket auf dem DMZ Interface "zuerst" ankommt, wird der State geschrieben, erlaubt und da die Firewall beim Processing erkennt "ey die IP bin ja ich" geht die WebUI auf.

    Deshalb "This Firewall", denn dieses Makro/Alias enthält ALLE Firewall IPs die sie hat. Auch VIPs (Alias IPs, CARP IPs etc.) deren Zugriff geblockt wird. Darum ist This Firewall wichtig extra zu blocken. Man kann natürlich argumentieren, dass dann immer noch ein Login benötigt wird etc. und der interne Host weniger gefährlich ist. Klar, ist aber Abwägung und wenn ich schon ne DMZ aufmache, dann kann ichs ja richtig machen ;)

    Oder greifen tatsächlich einige Schutzmaßnahmen hier nicht, bspw. pfBlocker?

    Was von pfBlocker soll denn greifen? pfBlocker an der Stelle wären ja lediglich irgendwelche IP Blocklisten mit externen IPs. Du greifst aber von der DMZ auf deine eigene WAN IP zu. Was soll pfBlocker da blocken?

    Oder wäre es mehr ein Problem des Monitorings?

    Inwiefern Monitoring? Man darf eben auf eine IP des Systems zugreifen weil mans per Regel erlaubt hat. Gegen "eigene Dummheit" bei der Regelerstellung hilft auch Monitoring wenig :D

    Da ich auch keine NAT-Reflection eingerichtet habe, geht das vermutlich nur, weil der Server auf einem anderen Interface gehostet wird

    Eigentlich nicht. Wenn es geht, machst du NAT Reflection, andernfalls würdest du über die pfSense auf ihrer externen IP keinen XMPP Dienst erreichen, wenn der Server ne interne IP hat und du definitiv kein Split DNS machst. TCPdumpen und nachschauen hilft, aber ich würde raten, dass da doch NAT Reflection läuft.

    Würde ich hier nun ebenfalls "diese Firewall" blocken, hätte das negative Auswirkungen? Aber ich vermute mal nein.

    Hätte keine Auswirkung weil das ja auf dem LAN ist (oder nicht?) - auf dem LAN gilt ja eh die Anti-Lockout Regel ganz oben ;) Und du willst dich ja mit This Firewall auf dem LAN nicht selbst aussperren, oder?



  • @JeGr said in DMZ oder besser DMZs?:

    • rejected alles was DMZ_net auf DMZ_net ist (wäre standard)
    • rejected alles RFC1918, damit DMZ nicht in andere lokale

    Würde die untere der beiden nicht die obere inkludieren? 🤓

    Tadaa, da das Paket auf dem DMZ Interface "zuerst" ankommt, wird der State geschrieben, erlaubt und da die Firewall beim Processing erkennt "ey die IP bin ja ich" geht die WebUI auf.

    Muss nicht alles verstehen als Homeuser, mir reicht's, wenn Du das sagst. Danke Dir! 😀

    Eigentlich nicht. Wenn es geht, machst du NAT Reflection, andernfalls würdest du über die pfSense auf ihrer externen IP keinen XMPP Dienst erreichen, wenn der Server ne interne IP hat und du definitiv kein Split DNS machst. TCPdumpen und nachschauen hilft, aber ich würde raten, dass da doch NAT Reflection läuft.

    Hab zumindest nichts eingestellt, vielleicht ist es inzwischen Standard oder der XMPP-Server macht seine eigene Magic.


  • LAYER 8 Moderator

    @Bob-Dig said in DMZ oder besser DMZs?:

    Würde die untere der beiden nicht die obere inkludieren?

    Richtig, würde sie. Daher wird das meist weggelassen, was dann genau dazu führt, dass man denkt, man habe alles interne abgeschottet und die externe IP vergessen :)

    Muss nicht alles verstehen als Homeuser, mir reicht's, wenn Du das sagst. Danke Dir! 😀

    Es ist simpel. Firewall UI ist erreichbar (theoretisch) unter jeder IP die die Firewall trägt. Interne IPs, DMZ IPs, VPN IPs, externe IP aufm WAN (außer du hängst hinter einem anderen Router, dann trifft das ganze Szenario nicht auf dich zu weil die WAN IP eh unter RFC1918 fällt :))
    Pakete werden wie gefiltert? Auf dem Interface auf dem sie ALS ERSTES auf der pfSense aufschlagen. Da wird gefiltert. Eingehend. Ergo im Beispiel: DMZ Host versucht widerrechtlich FW UI anzugrabbeln und nutzt, weil alle internen IPs und VPN IPs nicht gingen, zuletzt die externe IP. Tadaa hat Erfolg, weil die nicht geblockt wurde (und in der letzten Regel, allow any [Internet] mit enthalten ist).

    Jetzt verständlicher? :)

    Hab zumindest nichts eingestellt, vielleicht ist es inzwischen Standard oder der XMPP-Server macht seine eigene Magic.

    Würde mich wundern. Kannst ja in die Port Forward Regel reinsehen, default ist da Use system default. Und wenn du bei System>Advanced>Firewall&NAT mal Pure NAT eingestellt hast o.ä. dann ist das bei jedem Forward automatisch drin. Ansonsten vielleicht ein Relay o.ä. das da aushilft oder er announced auch seine interne IP irgendwie :)



  • @JeGr said in DMZ oder besser DMZs?:

    Pakete werden wie gefiltert? Auf dem Interface auf dem sie ALS ERSTES auf der pfSense aufschlagen. Da wird gefiltert. Eingehend. Ergo im Beispiel: DMZ Host versucht widerrechtlich FW UI anzugrabbeln und nutzt, weil alle internen IPs und VPN IPs nicht gingen, zuletzt die externe IP. Tadaa hat Erfolg, weil die nicht geblockt wurde (und in der letzten Regel, allow any [Internet] mit enthalten ist).

    Jetzt verständlicher? :)

    Ja, danke Dir. Mir fehlt halt dieses Verständnis für die "unsichtbaren" Regeln und dass es so schnell gehen kann...

    Hier nun meine überarbeitete DMZ-Regel. 😉
    Capture.JPG


  • LAYER 8 Moderator

    @Bob-Dig said in DMZ oder besser DMZs?:

    Ja, danke Dir. Mir fehlt halt dieses Verständnis für die "unsichtbaren" Regeln und dass es so schnell gehen kann...

    Warum unsichtbar? Wie gesagt, man erlaubt es ja, vergisst eben nur, dass die externe IP der Firewall auch in "any minus RFC1918" mit drin ist. Da ist sonst nix versteckt :)

    Bei dir ist es also

    • Reject alles was Firewall ist (also auch kein DNS oder NTP oder ähnliches erlaubt, ergo wohl statische Konfiguration oder DHCP mit non-local settings)
    • Ansonsten IOT Netz nach any minus RFC1918 push über VPN raus.

    Jup. Da ist nirgendwo die Firewall drin. Vorher wäre es selbst mit IOT_net/adress aber OK gewesen, weil andere Interfaces der Firewall mit privaten IPs du ausgeschlossen hast (RFC1918) und du allen Verkehr der nicht spezifiziert ist übers VPN rausschiebst. Damit kommt sowieso kein Paket aus IOT direkt an das WAN Netz. Müsste man austesten, aber ich meine, damit wäre die WAN IP nicht zugreifbar.

    So ist aber eh besser :)



  • @JeGr Bei den Gateways bin ich mir eh unsicher, ich sollte das vielleicht selbst testen.



  • @JeGr Ich hab jetzt ein paar Versuche gestartet, aber es ist mir nie gelungen auf die Firewall zu kommen, wenn RFC1918 geblockt wurde, auch ohne verstellte Gateways etc. nicht. Wie hätte ich das testen müssen?

    Der xmpp-Client verbindet sich übrigens mit IPv6, was die Sache wohl erklärt. Das doofe daran, ich wollte ja damit bewusst ein Stück weit und einfach die Erreichbarkeit von außen testen, was so wahrscheinlich gar nicht funktioniert. Gut, ich hab ja immer noch StatusCake.



  • Danke das hatte ich nicht auf dem Schirm, ging tatsächlich mit der WAN IP.
    Also neue Regel für alle DMZ Netze DENY Mgmt Alias.

    Arbeite nur mit den Floauting Rouls, da ich nicht für jedes Int alles anlegen will.


  • LAYER 8 Moderator

    @NOCling said in DMZ oder besser DMZs?:

    Arbeite nur mit den Floauting Rouls, da ich nicht für jedes Int alles anlegen will.

    Wer das mag, kann das natürlich tun. Ich rate absolut davon ab. Ich hatte schon Firmen aufm Schirm die gedacht haben das ist ne super Idee. Ist es nicht, es war das totale Grauen weil man absolut null Übersicht mehr hatte. Gut, mit 2.4.5 ist nun endlich das Interface angezeigt worden, vorher konnte man nicht mal sehen, auf welchem IF Floats eigentlich konfiguriert sind. Aber nein, ich halte die nach wie vor für den Laien für zu gefährlich sich Löcher ins Regelwerk zu schießen weil man plötzlich mit Dingen wie "quick" "outbound/both" o.ä. experimentiert hat ohne zu realisieren was man tut. Da Floats auch noch default als Richtung "both" hatten/haben, ist mir das zu heikel und unübersichtlich. Ab ~30 Regeln halte ich das für total chaotisch. Dann lieber mehrere VLANs/LANs, die gleiche Regeln bekommen einfach per Interface Gruppe konfigurieren. Wesentlich weniger Gefahr damit was zu verbiegen als mit Floats. :)



  • @JeGr @NOCling Also bei mir ging es nicht mit der Internet-IP. Bitte mal genau das Testszenario beschreiben.

    Edit: Mir fällt gerade ein, dass meine Internet-IP ja nicht an WAN anliegt, sondern eine CG-(1:1)NAT-Adresse... Ich müsste es wohl mit dieser versuchen, immer diese verdammten Sonderfälle. 😌



  • Ok, konnte es jetzt mit meiner 100.65.xxx.xxx-IP, also meiner tatsächlichen WAN-IP, ebenfalls nachvollziehen, danke @JeGr !!

    Edit: Und das in der Regel definierte Gateway verhindert den Zugriff ebenfalls nicht. Mein Eindruck zu Gateways ist, dass diese keine geprüften Voraussetzungen für eine Regel/Verbindung darstellen, sondern lediglich den Traffic anschließend ausleiten, sofern anwendbar.


  • LAYER 8 Moderator

    @Bob-Dig said in DMZ oder besser DMZs?:

    Edit: Und das in der Regel definierte Gateway verhindert den Zugriff ebenfalls nicht. Mein Eindruck zu Gateways ist, dass diese keine geprüften Voraussetzungen für eine Regel darstellen, sondern lediglich den Traffic anschließend ausleiten, sofern anwendbar.

    Nun es schiebt den Traffic dann aus der Firewall ausgehend aus dem angegebenen Interface. In dem Fall wird es aber dort behalten weil die Firewall merkt, dass sie selbst gemeint ist. Daher klappt es wohl auch gut. Wie gesagt, wenn du jetzt RFC Block nicht drin hättest und wolltest ins LAN zugreifen würde es nicht klappen, weil der Traffic übers VPN gepresst wird und dort dann am GW abgewiesen wird. Darum muss auch bei MultiWAN bspw. und Policy Regeln da entsprechend drauf geachtet werden, dass man interne Ausnahmen o.ä. definiert, die als Gateway "default" (*) angegeben haben, damit das interne Routing sauber läuft.



  • @JeGr gerade mal getestet und Du hattest, wie immer, recht. Aber jetzt wird es wieder schwierig für mich, dem ganzen logisch zu folgen. Warum ist das Gateway mal optional und dann wieder nicht.


  • LAYER 8 Moderator

    @Bob-Dig said in DMZ oder besser DMZs?:

    Warum ist das Gateway mal optional und dann wieder nicht.

    Warum sollte es optional sein? Dem kann ich jetzt nicht folgen.



  • @JeGr Na ja, warum konnte ich mit allein dieser Regel noch auf die Firewall zugreifen, wenn doch sämtlicher Traffic hätte ausgeleitet werden müssen. Du hattest schon was dazu geschrieben, ein logisches Problem aber bleibt (für mich).

    Capture.JPG


  • LAYER 8 Moderator

    Weil die IP auf der Firewall bekannt ist. Warum sollte ich ein Paket routen, wenn ich es selbst bin? Ganz einfach. Klar kann ich auf das Paket noch den Sticker draufkleben "schicke es über VPN wenns raus geht" aber wenns nicht raus gehen muss - ist das eben obsolet.



  • @JeGr Es ist und bleibt aber eine Regelverletzung. 😜


  • LAYER 8 Moderator

    @Bob-Dig said in DMZ oder besser DMZs?:

    @JeGr Es ist und bleibt aber eine Regelverletzung.

    Wie kommst du darauf? Nein ist es nicht?

    Regel sagt "erlaube alles was NICHT RFC1918 ist und überall hin will". Zusätzlich sagst du damit "route wenn nötig als GW nicht per Default sondern per VPN". Da Routing unnötig -> Paket bereits am Ziel wenn Firewall erreicht - ist das alles komplett legitim.



  • @JeGr said in DMZ oder besser DMZs?:

    Wie gesagt, wenn du jetzt RFC Block nicht drin hättest und wolltest ins LAN zugreifen würde es nicht klappen, weil der Traffic übers VPN gepresst wird und dort dann am GW abgewiesen wird. Darum muss auch bei MultiWAN bspw. und Policy Regeln da entsprechend drauf geachtet werden, dass man interne Ausnahmen o.ä. definiert, die als Gateway "default" (*) angegeben haben, damit das interne Routing sauber läuft.

    Ich sehe das im Widerspruch zu dem hier, wo etwas durchs Gateway gepresst wird, obwohl ja ebenfalls unnötig. Aber wie gesagt, mir fehlt da wohl der Blick fürs große Ganze und solange es Sinn für dich macht, alles supi.


  • LAYER 8 Moderator

    @Bob-Dig said in DMZ oder besser DMZs?:

    wo etwas durchs Gateway gepresst wird, obwohl ja ebenfalls unnötig.

    Das passiert aber nur, weil es nicht die Firewall selbst ist, also keine lokale IP. Ergo wird es geroutet. Und statt der Routing Tabelle wird eben durch die Regel (PBR) dann das Gateway "erzwungen" und das Paket da rausgepresst. Wenns aber nirgends hin muss - bleibts zu Hause :)



  • @JeGr said in DMZ oder besser DMZs?:

    • rejected alles was DMZ_net auf DMZ_net ist (wäre standard)

    Moin Jens,
    ich habe nochmal eine Frage dazu.
    Was wäre hierfür das Anwendungsgebiet. Wenn ich einen Switch angeschlossen hätte, so könnte pfSense auf dem selben Interface eh nichts filtern, weil der Verkehr allein über besagten Switch liefe, korrekt? Was beträfe das also, vielleicht wenn ich Ports in pfSense gebridged hätte? 🤓


  • LAYER 8 Moderator

    Da ich Bridging auf der Sense vermeide wie Teufel und Weihwasser und ich das einfach Unfug finde, ja vielleicht. Es blockiert gegenüber "_address" eben jegliche Adresse aus dem "_net" auch wenn ich der Firewall mehrere IPs gebe. Ggf. will ich ja wirklich nur innerhalb des Netzes filtern. Anderer Punkt: NAT Reflection unterbinden. Bei Reflects wäre der Zugriff tatsächlich von _net auf _net weil die IP aus der DMZ auf die externe IP geht, auf der FWL umgeschrieben wird auf die DMZ IP und dann wieder in die DMZ geht. Ich möchte aber ggf. gar nicht dass sich Kiste 1 selbst via extern aufruft oder Kiste 2 über extern aufruft, sondern die sollen direkt intern miteinander reden um direkter zu kommunizieren und Latenz zu sparen. Rejecte ich das, merkt man das sofort ob/was für ein Zugriff da zum Tragen kommt.



  • @JeGr Danke Dir.
    Denke, damit ist das Thema DMZ hinreichend beschrieben. Schönes WE.


  • LAYER 8 Moderator

    Oder bis später? ;)



  • @Bob-Dig said in DMZ oder besser DMZs?:

    Der xmpp-Client verbindet sich übrigens mit IPv6, was die Sache wohl erklärt. Das doofe daran, ich wollte ja damit bewusst ein Stück weit und einfach die Erreichbarkeit von außen testen, was so wahrscheinlich gar nicht funktioniert. Gut, ich hab ja immer noch StatusCake.

    Hatte gerade mal wieder einen Ausfall. Nun läuft's wieder, aber IPv6 geht noch nicht und ich sehe, dass die Verbindung über IPv4 erfolgt, wie gesagt, ohne NAT Reflection. Faszinierend.



  • Ich habe jetzt die DMZs fertig angelegt.

    Was mich noch stört ist die Reihenfolge der Interface in pfSense, insbesondere unter Firewall / Rules. Gibt es hier eine Möglichkeit Ordnung bzw. eine gewünschte Reihenfolge einzurichten? Ggf. welche Risiken wären damit verbunden?

    Und spricht etwas dagegen, den ganzen /48er und den /64er von HE in einen Alias zu packen und ihn dann quasi als RFC1918-Alias zu nutzen?
    Würde die Regelerstellung vereinfachen.

    Capture.JPG

    Und wenn ich unter dieser ASN-Nummer von meinem ISP gucke, dann sehe ich dessen gesamtes IPv6-Netz? Das könnte ich ja auch noch dem Alias hinzufügen, um sicherzustellen, dass auch mein dynamischer IPv6-Prefix nie angegrabbelt werden kann? 😎


  • LAYER 8 Moderator

    @Bob-Dig said in DMZ oder besser DMZs?:

    Was mich noch stört ist die Reihenfolge der Interface in pfSense, insbesondere unter Firewall / Rules. Gibt es hier eine Möglichkeit Ordnung bzw. eine gewünschte Reihenfolge einzurichten? Ggf. welche Risiken wären damit verbunden?

    Deshalb hatte ich da schonmal gesagt, ich sortiere die alphabetisch und benenne die Interfaces mit Prefixen. Dann ist das meine Sortierung :)

    System / General -> Sortierung mit Haken auf alphabetisch. Dann einfach den Namen ändern. Fertig.



  • @JeGr Danke, werde ich dann auch so machen. Und auch ne Meinung zum Rest des gesagten?


  • LAYER 8 Moderator

    @Bob-Dig said in DMZ oder besser DMZs?:

    Und spricht etwas dagegen, den ganzen /48er und den /64er von HE in einen Alias zu packen und ihn dann quasi als RFC1918-Alias zu nutzen?
    Würde die Regelerstellung vereinfachen.

    Ja, weil es nichts mit RFC1918 zu tun hat ;)
    Nenne es wie du möchtest - aber bitte nicht RFC9181 :)

    Und wenn ich unter dieser ASN-Nummer von meinem ISP gucke, dann sehe ich dessen gesamtes IPv6-Netz? Das könnte ich ja auch noch dem Alias hinzufügen, um sicherzustellen, dass auch mein dynamischer IPv6-Prefix nie angegrabbelt werden kann?

    Nicht zwangsläufig, außerdem haben Provider oftmals mehrere ASNs.



  • @JeGr said in DMZ oder besser DMZs?:

    Nenne es wie du möchtest - aber bitte nicht RFC9181 :)

    Gegenvorschläge? :)



  • Muss sagen, schön sieht das jetzt nicht aus mit a1_WAN, b1_LAN... 😢



  • Hab mal auf alphabetische Prefixe umgestellt. Es ist so schade, dass man die Interface nicht wie Firewall Rules umordnen kann. 😥

    Capture.JPG


  • LAYER 8 Moderator

    Hmm, verstehe das Problem nicht. Ich ordne das nach Interfaces.

    Also Kiste mit 6 physischen Intefaces bspw.:

    • WAN1
    • WAN2
    • SYNC
    • DMZ
    • "Console"
    • TRUNK

    Die benenne ich dann entsprechend:

    • 1_WAN_DSL
    • 2_WAN_Cable
    • 3_SYNC
    • 4_DMZ
    • 5_CONS
    • 6_TRUNK

    Trunk wird nicht aktiv geschaltet und nur zugewiesen und benannt, weil da die VLANs draufkommen. Benennung und Zuweisung hilft aber, wenn man mal in der UI sucht, welches Interface draußen / an der HW was ist. 1-6 sind die HW Ports auf dem Gerät. Bei 10Gs hab ich dann ggf. auch mal X1/X2 genommen.

    Dann kommen VLANs, bspw.:

    • 10.23.1.0 LAN
    • 10.23.2.0 IOT
      etc.

    die werden dann enannt:

    • V2301_LAN
    • V2303_IOT
      ...

    Damit ist alles ordentlich sortiert und gut. Ich muss nicht alles alphabetisch haben o.ä. das bringt mir nix, aber mit dem VLAN Tag mit drin hilft es mir direkt die IP Range und das VLAN Tag aus dem Namen heraus ableiten zu können.

    Funktioniert fabelhaft. Und kann man auch mit Gruppen machen -> G_Infra, G_DMZs, G_WLANs, etc.

    Aber man muss es ja nicht übertreiben ;)


Log in to reply