Setup VLANs (vor allem für 2 WLANs)?

[underclocker2k4]

Siehe EDIT.

Beitrag automatisch zusammengeführt: 07.04.2026

"Block alles nach RFC_1918" wäre das eine "doppelte Negation", wie Du sie hier ausdenkst. Glaube aber kaum, dass die Sense daraus ein "ist zweimal geblockt, ich lass das jetzt durch" machen würde.

Block RFC1918 ist NICHT die doppelte Negation, sondern die direkte Ansprache. (siehe oben)
Negation der Negation hat nichts mit 2x Block = erlauben zu tun. Letzteres (2x deny=allow) funktioniert bei FWs grundsätzlich nicht, da nach dem ersten Block die Paketbearbeitung abgeschlossen ist.

Und wer sagt Dir, dass jemand nicht Ranges aus 192.168.0.0/16 und 10.0.0.0/8 zusammen nutzt? Macht das nicht auch eine Fritzbox für Gäste WLAN? Finde die Idee nicht mal so abwegig.

Ich habe doch geschrieben, dass das 192.168.0.0/16 als Beispiel dient. Ich kann dir jetzt Netzgruppen bauen, die 10k Netze beinhalten. Das ist ein akademisches Spiel und trägt nichts zum Thema bei.

EDIT:
Und nur weil es im Netz diese Notation gibt, heißt das nicht, dass sie gut ist.
Wenn du mal ne Firewall mit 4-5stelligem Regelset hast, weiß du, warum es klare und strikte Notationen gibt.
Nicht alles was technisch funktioniert, ist auch sinnvoll im Einsatz. Das gilt insbesondere für Firewallrulesets.
Besonders dann nicht, wenn das Regelwerk lebt. Da wundert man sich nämlich, warum ne Regel nicht greift.
Der Grund ist dann in der Regel, weil einer weiter vorne mal "kreativ" war.

2ndEDIT:
Man füllt ein Firewallregelset in der Regel wie folgt:
Verbieten Firewall:
1. erlaube 1
2. erlaube 2
3. erlaube 3
4. verbiete alles/den Rest

Erlauben Firewall:
1. verbiete 1
2. verbiete 2
3. verbiete 3
4. erlaube alles/den Rest

 

[sch4kal]

Solange die Firewall nicht invers arbeitet und das tut keine, ist immer alles erlaubt und man stellt eigentlich nur Verbote ein.
Eine Firewall ist ohne Regeln erstmal ein Router/Switch und sonst nichts. Per default ist da alles erlaubt,bzw. nichts verboten.

Das ist falsch. Sowohl Juniper SRX (bzw. generell in Junos), als auch Fortinets haben eine, zumeist unsichtbare, oder nicht direkt sichtbare, deny any default Regel.

 

[besterino]

Ich hab das jedenfalls anders dargestellt: Zugriff auf die VLANs ist aktiv geblockt und die Regel ist auch als solche („Block“) angelegt.

Allerdings ist zumindest bei der pfsense so, dass die nirgends irgendwas routet. Also insbesondere nicht zwischen VLANs und auch nicht zwischen VLAN/LAN und WAN. Damit also irgendwas über das Subnetz hinaus „raus“ kommt, braucht es eine Allow-Regel. Nach meinem Verständnis ergibt das eine grobe Reihenfolge:

1. Erlaube einzelne Hosts usw.
2. Erlaube Hostgruppen oder einzelne Subnetze
3. Verbiete alle zu schützenden Subnetze (die dann auch 1. oder 2. enthalten können) - bei mir synonym mit allen VLANs
4. Erlaube Internet

Auch bei mir ist „Erlaube Internet“ de facto gleichbedeutend mit „Allow !VLAN-Subnetze“, weil ich noch nicht geschnallt habe, wie ich „Internet“ anders als !VLAN-Subnetze / positiv in der pfsense ausdrücken könnte.

EDIT & Nachtrag: meins ist im Prinzip ne Variante von @underclocker2k4 „Erlauben-Notation“, weil ich vor den globalen Verboten halt noch Einzel-Ausnahmen von dem Verboten brauche, die sonst bei 4. „erlaube Rest“ nicht mehr zum Einsatz kämen.
Beispiel: Server-VLAN global verboten. File-Server für Host XYZ im Server-VLAN soll aber erreichbar sein. Nun könnte ich natürlich die Verbote so setzen, dass nur der Fileserver übrig bleibt, aber da werde ich ja wahnsinnig…

 

[underclocker2k4]

Das ist falsch. Sowohl Juniper SRX (bzw. generell in Junos), als auch Fortinets haben eine, zumeist unsichtbare, oder nicht direkt sichtbare, deny any default Regel.

Also habe ich doch recht.
Wenn es unsichtbar/nicht direkt sichtbar ist, dann ist es also doch da. Sonst wäre es nicht unsichtbar, sondern einfach nicht da.

Auch bei mir ist „Erlaube Internet“ de facto gleichbedeutend mit „Allow !VLAN-Subnetze“, weil ich noch nicht geschnallt habe, wie ich „Internet“ anders als !VLAN-Subnetze / positiv in der pfsense ausdrücken könnte.

0.0.0.0/0 sind alle IP-Adresse auf der Welt.

1. Verbiete X (192.168.0.10/32)
2. Verbiete Y (192.168.10.95/32)
3. Verbiete Z (192.168.20.0/24)
4. Erlaube die Welt. (0.0.0.0/0)

Verbiete Host X, verbiete Host Y, verbiete Netz Z, erlaube sämtliche andere Kommunikation. (sowohl intern als auch extern)

 

[besterino]

Na gut, aber 0.0.0.0 ist doch dann synonym zu !VLANs - quasi bisserl Schutz mehr, wenn ich mal die Deny-Regel verliere (insb. aus Dummheit).

 

[underclocker2k4]

Wie gesagt, die Negation (!VLAN) wirkt ja. Informatik ist am Ende auch nur Mathematik. Hier im Beispiel die Mengenlehre. (man kann jetzt noch mit Teil der Menge und nicht Teil der Menge anfangen...)
Und eben weil das so "kompliziert" ist, nutzt man einfache und auf den ersten Blick, besonders für andere, klare Notationen.

 

[sch4kal]

Ich hab das jedenfalls anders dargestellt: Zugriff auf die VLANs ist aktiv geblockt und die Regel ist auch als solche („Block“) angelegt.

Sieht bei mir so aus:

Besser Reject (intern), damit die Endgeräte auch ein ICMP Unreachable bekommen und nicht unnötig auf Antwort warten. Aus dem WAN natürlich Block.

Allerdings ist zumindest bei der pfsense so, dass die nirgends irgendwas routet.

Doch, routen schon, nur die pf Firewall blockt per default auch alles, sofern es unten keine "Erlaube alles" Regel gibt.

Nach meinem Verständnis ergibt das eine grobe Reihenfolge:

1. Erlaube einzelne Hosts usw.
2. Erlaube Hostgruppen oder einzelne Subnetze
3. Verbiete alle zu schützenden Subnetze (die dann auch 1. oder 2. enthalten können) - bei mir synonym mit allen VLANs
4. Erlaube Internet

Das wäre eine gute Richtlinie. Wenn etwas "für alle" Richtung z.B. WAN gelten soll, kann man auch über Floatingrules nachdenken.

Auch bei mir ist „Erlaube Internet“ de facto gleichbedeutend mit „Allow !VLAN-Subnetze“, weil ich noch nicht geschnallt habe, wie ich „Internet“ anders als !VLAN-Subnetze / positiv in der pfsense ausdrücken könnte.

Das erreichst du, indem du das Gateway in der Regel festlegst bzw. bei pfSense nimmt er default immer die reguläre Routingtable. Wenn dort also vermutlich eine 0.0.0.0/0 Route Richtung deines Internetanschlusses existiert, dürfte das ausreichen, einfach nichts als Quelle anzugeben.

 

[BobbyD]

Besser das Video gucken.
Grundsätzlich hat UC2004 aber recht. Im professionellen Umfeld, wo ggf. verschieden Personen die selbe Firewall administrieren müssen, sind solche Invertierungen nicht gerne gesehen, hab ich mir sagen lassen. Zuhause geht das aber in Ordnung.
Die Sense ist übrigens Default Deny, das kann man auch nicht ändern.

Beitrag automatisch zusammengeführt: 07.04.2026

Das erreichst du, indem du das Gateway in der Regel festlegst

Mit IPv6 funktioniert das meine ich nicht mehr, würde ich also eher nicht empfehlen, auch wenn ich es für IPv4 auch schon genutzt habe. Gewöhne es mir aber gerade ab.

Beitrag automatisch zusammengeführt: 07.04.2026

So sieht das exemplarisch bei mir aus:

DNS und NTP werden zuvor über Gruppen-Regeln abgehandelt (hier nicht abgebildet).
reserved4 ist ein System-Alias in neueren pfSensen und GroupVSix eine Interface-Gruppe, in der ich alle vorhandenen IPv6-Interface (ULA/GUA) gruppiert habe.

 

[sch4kal]

Besser das Video gucken.

Der zeigt das auch nur mit einer Alias RFC1918 Regel. Kann man so auch machen, hat aber auch Nachteile. z.B. bei Renumbering von anderen Interfaces, oder beim Hinzufügen neuer VLAN Interfaces mit anderen RFC1918 Adressen. Da muss ich wieder mehr "Knöpfe" anfassen (und Hirnschmalz reinstecken, weil ich ja dann unter Umständen keine /8, /12 oder /16 Ranges mehr als Ganzes blocken kann), als (wie du ja auch im Screenshot) "$IF address" und "$IF subnet" anzugeben.

 

[BobbyD]

weil ich ja dann unter Umständen keine /8, /12 oder /16 Ranges mehr als Ganzes blocken kann

Doch, die Ausnahmen definierst Du ja jeweils als Regel davor (bei TS nicht vorhanden, wäre im Bild dann die zweite Regel).

Bei dynamischem IPv6 geht das leider nicht mehr (es sei denn, man nutzt nur ULA mit NPt). Daher muss ich die Gruppe (siehe Edit) "händisch" pflegen. Aufwand hält sich in Grenzen, da ich IPv6 nur sehr bedacht einsetze.

 

[tar]

Das sieht zumindest wunderbar hässlich aus 😄

 

[besterino]

Wasn das fürn Kommentar, vor allem wäre es erhellend, worauf sich "Das" eigentlich bezieht.

 

[tar]

Das ist meine abwertende Meinung zu dieser visuell furchtbar unübersichtlichen Firewall bzw. der Anwendung des "Invert Match". Man sieht eben überhaupt nicht, was da passiert. Was sich hinter "_reserved4_" und "GroupVSix networks" verbirgt, weiß allein das Hirn des Admins. Das Schlimmste dabei: es ist einfach nur Tippfaulheit, weil man für ein Gäste-WLAN halt keine 5 Block-Regeln für all die anderen internen VLANs und dann eine Pass-Regel fürs Internet anlegen möchte, erledigt der invertierte Alias, den kein Schwein auf Anhieb lesbar versteht, das alles in einer Zeile. Das mag wunderbar kurz und effizient sein - es bleibt ein schierer Albtraum bei der Fehlersuche

 

[AliManali]

Naja, all die Firewalls mit denen ich zu tun hatte, sind ein Albtraum für den armen Supporter, der sich nicht damit auskennt. Dachte ich mir auch erst, als ich von Endian/Zyxel und weiteren auf die OPNsense umgestiegen bin. Man gewöhnt sich an (fast) alles...

 

[BobbyD]

weiß allein das Hirn des Admins. Das Schlimmste dabei: es ist einfach nur Tippfaulheit

Das erste ist wie gesagt ein System-Alias, den hat jede aktuelle pfSense(+). Außerdem habe ich fast 40 Firewall-"Interfaces" (WANs, LANs, VLANs, VPN-Clients und -Server). Es in meinem Falle anders zu machen, wäre einfach nur dämlich.

Beitrag automatisch zusammengeführt: Mittwoch um 11:29

Ich habe mal die Berechtigung für ausgehendes IPv6 entfernt und dem LXC gesagt, er soll IPv4 bevorzugen. Wenn TeamSpeak3 das nicht noch stört, dann wäre das ok, denn ich "brauche" firewalltechnisch IPv6 nur eingehend. Und gerade gelesen, dass der Server ausgehend wohl nur Port 443 voraussetzt, also reichen die Webports für das und Debian-Updates.

Aber irgendwie schweifen wir ab.

 

[tar]

Dann bitte auch erwähnen, das sich LANcom jede Menge Features extra bezahlen lässt, wie z.B. pro VPN Client um die 100 Euro. Wenn man im Business Umfeld dann auch die Anwendung dafür hat, mag das gerechtfertigt sein, fürs HomeLab wird das keiner Ausgeben wollen.

Ich habe heute mal testweise VPN via WireGuard auf dem LANCOM-Router eingerichtet, weil ich zufälligerweise mal wieder den Plex-Docker angeworfen hatte und leidlich feststellte, dass die einen (neuerdings?) zur Kasse bitten wollen, wenn man seine eigenen Daten vom eigenen Server abspielen möchte, aber nicht im heimischen (W)LAN hockt bzw. das Ganze gar vom Smartphone versucht. Kurzerhand bot es sich halt an und - oh Wunder - es kostet nichts und funktioniert.

Also soll sich bspw. jemand vom Laptop von einem externen Netz (bspw. vom Hotel-WLAN aus) ins heimische Netz "einwählen" und dort den Plex-Docker (der auf dem Server läuft) mit einer "lokalen IP" aufrufen können. Der VPN-Tunnel soll die IP 10.0.250.10 bekommen. Der Router die zusätzliche IP 10.0.250.1 als VPN-Gateway. Das simuliert im Grunde ein VPN-Netzwerk 10.0.250.x - tatsächlich ist das aber kein wirkliches Netzwerk, weswegen wir das mit der "250" optisch deutlich von den restlichen lokalen Netzwerken/VLANs trennen. Der Server hat die lokale IP 10.0.5.10 und Plex ist im LAN über 10.0.5.10:32400 erreichbar.

Man kann das ganze in LANCOM nun wie folgt einstellen. Erstmal den VPN-Tunnel erzeugen:

• VPN -> WireGuard
  • "WireGuard aktiviert" aktivieren (wer hätte dies gedacht)
  • Verbindungs-Liste -> Hinzufügen
    • Verbindung: VPN-BERND (halt was sprechendes)
    • Verbindung aktiv: Ei ja
    • Immer aktiv: nein
    • Lokaler Port: 51.820
    • Remote Gateway: leer lassen
    • Remote Port: 51.820
    • Routing Tag: 0
    • Local Private Key: auf Schlüssel erzeugen klicken
    • Peer Private Key: auf Schlüssel erzeugen klicken
    • Preshared Key: auf Schlüssel erzeugen klicken
    • IPv6-Profil: DEFAULT oder INTERNET oder was man halt so nutzt
    • Persistent Keepalive: 25
    • Kommentar: die Kalorien der letzten Mahlzeit
    • via "Peer Konfig erzeugen" kann man sich direkt die Importdaten für den WireGuard-Client erzeugen lassen
      • Adress: 10.0.250.10/32 (die eigene VPN-IP)
      • DNS: 10.0.250.1 (der VPN-Gateway)
      • Allowed IPs: 10.0.5.10/32 (da wollen wir hin), 10.0.250.1/32 (der VPN-Gateway, optional ginge auch 10.0.250.0/24 - man hätte den Gateway gleich mit dabei und könnte andere VPNs im selben IP-Bereich "netzwerkartig" anpingen oder dergleichen, muss das Ganze dann aber auch durchrouten)
      • Endpoint: <deineÖffentlichZuErreichendeIP>:51820 (bspw. via DuckDNS einrichten und hier dann eben "mytollesubdomain.duckdns.org:51820" setzen)
      • Persistent Keepalive: 25

Wenn man das alles eingegeben hat, sollte oben der Text auftauchen (kann man in einer .conf-Datei ablegen und im WireGuard-Client auf dem Laptop dann einfach importieren/laden - oder am Smartphone den QR-Code scannen).

Damit hätten wir die Verbindung (und theoretisch auch den Client fertig), aber da fehlt noch bissl was. Wir brauchen einen VPN-Gateway. Dafür erzeugen wir eine weitere Adresse für den Router selbst

• IPv4 -> Allgemein -> Loopback-Adressen -> Hinzufügen
  • Name: VPN-GATEWAY
  • IP-Adresse: 10.0.250.1 (das ist die weitere Adresse, die der Router nun selbst hat)
  • Routing-Tag: 0

Diese Adresse vom Router müssen wir dem VPN-Tunnel nun noch mitteilen.

• Kommunikation -> Protokolle -> IP-Parameter -> Hinzufügen
  • Gegenstelle: VPN-BERND (identisch zur WireGuard-Verbindung, kann man auch auswählen)
  • IP-Adresse: 10.0.250.1
  • Netzmaske: 255.255.255.255
  • Rest: auf 0.0.0.0 belassen

Dann müssen wir noch die (Rück-)Route festlegen, damit der Router weiß, wo er die (Antwort-)Pakete für den VPN-Tunnel hinschicken soll. Ohne diesen Eintrag landen sie im Nirvana.

• IP-Router -> Routing -> IPv4-Routing-Tabelle -> Hinzufügen
  • IP-Adresse: 10.0.250.10 (die von VPN-BERND)
  • Netzmaske: 255.255.255.255 (das beschränkt die Route auf diese eine IP)
  • Routing-Tag: 0 (wie üblich, wir keepen es simple und trennen hier keine Netze auf)
  • Schaltzustand: aktiviert
  • Router: VPN-BERND (genau hier in diesen VPN-Tunnel sollen die Pakete für 10.0.250.10 ja hin)
  • RIP-Distanz: 0
  • IP-Maskierung: abgeschaltet (damit bleibt der Netzverkehr transparent)
  • Administrative Distanz: 0
  • Kommentar: "Schokobons sind eine vollwertige Mahlzeit"

Schließlich müssen wir den VPN-Tunnel noch in der Firewall berücksichtigen.

• Firewall/QoS -> IPv4-Regeln -> Hinzufügen
  • Regel 1: Erlaube VPN-BERND-IP zu ROUTER-VPN-IP: DNS (= 10.0.250.10 zu 10.0.250.1:53)
  • Regel 2: Erlaube VPN-BERND-IP zu SERVER-IP:PLEX (= 10.0.250.10 zu 10.0.5.10:32400)
  • optional Regel 3: Verbiete VPN-BERND-IP zu allem und logge das (grenzt das Logging von der BLOCK-ALL-Regel ab)

 

[BobbyD]

Das nenne ich mal eine hässliche Teil-Übersetzung und Beschreibung...

Kommentar: die Kalorien der letzten Mahlzeit

Mir hätte ja die Aussage gereicht: WireGuard komplett kostenlos nutzbar.

 

[besterino]

Rumkotzerei mit der Juniper CLI...

Besterino's Cheat-Sheet für die Zukunft (vor allem für mich in x Tagen/Wochen/Monaten):

Hostnamen setzen:

set system host-name <HOSTNAME>

VLAN erstellen

set vlans <VLAN NAME> vlan-id <#>

VLAN löschen:

delete vlans <VLAN NAME>

Trunk konfigurieren:

set interfaces <INTERFACE z.B. ge-0/0/0> unit 0 family ethernet-switching interface-mode trunk vlan members [ ID# oder NAME oder Range, also z.B. 1 2 3 4-6 seven ]

Beschreibung für Port setzen

set interfaces <INTERFACE NAME ge-... / xe...> description <TEXT>

Virtuellen Management-"Port" setzen für Zugang nur per VLAN auf einem "normalen" Port (mit DHCP-IP, damit ich das dann über die pfsense verwalten kann - für Notfälle bleibt der dedizierte physische Management-Port ja erhalten)

set interfaces irb unit <# FREI WÄHLBAR> family inet dhcp
set vlans <MGMT VLAN NAME> l3-interface irb.<# VON ZEILE DIREKT OBENDRÜBER>

Funzt zumindest soweit, dass der Switch zusätzlich zum physischen mgmt-Port nun auch über das mgmt-VLAN per ssh und https erreichbar ist.

VLAN für untagged Port setzen (trunk oder access Port)

set interfaces <INTERFACE NAME> native-vlan-id <#>

Alarm deaktivieren (bzw. ignorieren) wenn der physische MGMT-Port nicht verbunden ist:

set chassis alarm management-ethernet link-down ignore

Falls man mal wieder was verfummelt und z.B. eine SSH-Session darüber das zeitliche segnet:
Leichen anzeigen lassen:

show system users no-resolve

Leiche rausschmeißen:

request system logout terminal <TERMINAL>

ABER: ich fürchte, das nutzt am Ende alles nichts, weil meine Mikrotiks (CSS326 und CSS610) sich anscheinend nur mit 24V passive POE befeuern lassen... Aus irgendeinem Grund war ich der Meinung, dass entweder die Mikrotiks PoE+ als "PoE-PD" könnten oder der EX2300 Passive PoE - keine Ahnung wieso... tjaja, das war mal wieder nix. Aber immerhin kann der Aruba 2930F das auch nicht...

Warum baut Mikrotik denn noch so einen Mist mit poe-pd als passive poe?

 

[Supaman]

Und ich sag noch: nehm Unifi, das spart jede Menge Zeit und Nerven... aber auf mich hört keiner

 

[Shihatsu]

Und ich sag noch: Das telefoniert heim...

 

[Luckysh0t]

@Shihatsu


Das kann man mittlerweile wirklich abschalten - vorher war "off" effektiv das, was nun "minimum" ist. Ob man das glauben möchte, sei mal dahingestellt - allerdings muss man solchen Optionen in den meisten Fällen halt auch ein Stück weit "vertrauen" entgegenbringen. Sonst kann man es sich ja überall sparen ^^.

Bei meiner neuen UCG-Fiber, war es übrigens im Standard auf "off". Liegt vielleicht daran, dass ich die Lokalisierung/Zeitzone auf Deutsch habe.
In 6 Jahren kann sich dann doch auch mal was ändern.

 

[Shihatsu]

Hast du das mal überprüft? Denn leider hat Unifi mindestens einmal gezeigt das sie trotzdem DAten übertragen haben. Und dieses eine Mal ist halt das berühmte eine Mal zuviel, wenn die Transparenz darüber von dritten hergestellt werden muss...

 

[Luckysh0t]

Also was ich in meinem Pihole so gesehen habe, werden folgende URL aufgerufen

• trace.svc.ui.com
• static.ui.com
• secure-uploads.ui.com
• ping.ui.com
• mtls-security.svc.ui.com
• ips.svc.ui.com
• img.community.ui.com
• img.community.ui.com
• help.ui.com
• gpt.help.ui.com
• geo.svc.ui.com
• fprint-ml-poc.dev.svc.ui.com

Allerdings habe ich auch Failover WAN an - entsprechend dürfte da eh mehr Traffic passieren. Auch die automatische Füllung der Hersteller auf Basis der Mac Adresse bekommt immer wieder Updates, dann die ganzen Icons für das Dashboard, der Speedtest - wenn man ihn nutzt, entsprechend auch die Serviceerkennung samt Icon/Hersteller wird eine URL Abfrage generieren. Wobei ein Großteil der URLS vom PiHole geblockt werden wie auch von meinem Windows-PC sowie Windows VM xD
Manche Icons zeigen auch nur einen Grünen Status an, wenn die Logik dahinter ins Internet darf - ähnlich wie das Icon bei Windows bez. Internet ist da oder nicht.

Im Großen und Ganzen, kann ich dank der URL und dem, was in der UI so sichtbar ist, nachvollziehen was wofür gebraucht wird - aber wie bei allem, sicher kann man sowas nie sagen. Das ist klar.
Ich habe allerdings auch nicht das Teil mit einem UI Account verbunden - werde ich auch nicht, da würde ich vmtl. noch mehr sehen xD


Der WAN Failover funktioniert jedenfalls immer noch - gerade getestet

 

[BobbyD]

Und ich sag noch: Das telefoniert heim...

Wie so vieles heutzutage. Ich sehe auch nirgends, dass das ein Ausschlussgrund für besterino war.
Ich vermute eher, es war der Preis ausschlaggebend.
Warum sich hier so viele altes Enterprise-Geraffel hinstellen, bleibt mir ein Rätsel. Ok, mir fällt auch nicht ein, warum man zuhause einen 48-Port-Switch braucht, es sei denn, man hat einen kleinen Palast.

 

[besterino]

Doch, „Heimtelefonie“ meiner Geräte wollte ich nicht. Und in der Tat war/ist Preis ein Kriterium - gerade nur für das letzt i-Tüpfelchen:

Die Idee war halt, die Anzahl der Geräte zu verringern, Kabelsalat zu reduzieren und ggf. etwas Energie zu sparen.

An den APs hängen entsprechend 4 PoE-Injektoren, und hätte ich auch die zwei Etagenswitches per PoE-PD versorgen können, wären die Injektoren mit ihren nervigen Kabeln und 2 Netzteile weniger gewesen. Und ich hätte eine hübsche Option für Kameras, Telefone usw. gehabt.

Im Prinzip würde das ja auch alles gehen, minus die Switches.

Dummerweise möchte ich als Etagenswitch gerne was mit 2xSFP+ - da wirds mit POE+-PD dann schon sehr sehr überschaubar.

Muss mal schauen, was ich nun mach. Im Prinzip ist es ja wirklich kein Problem, alles zu lassen wie es nun ist.

Sollte irgendwann mein Zoo an PoE+ Geräten wachsen, könnte ich den Juniper ja immer noch in Betrieb nehmen.

 

[Luckysh0t]

Muss mal schauen, was ich nun mach. Im Prinzip ist es ja wirklich kein Problem, alles zu lassen wie es nun ist.

Dieser Satz aus deinem Mund, wenn es um Netzwerkhardware geht? Hm....

 

[besterino]

Die Ernüchterung nach erfolglosem (weniger erheblichen) Kapital- und Zeiteinsatz (schon eher nervig) gepaart mit der Erkenntnis mal wieder im Vorfeld die Hausaufgaben nicht gründlich genug erledigt zu haben geht auch an mir nicht spurlos vorüber…

Dat Haupthindernis is aber: die Kiste ist viel viel lauter als der Ist-Zustand und frisst im Zweifel auch mehr Energie bei Null Mehrwert außer …öhm… „ich fahr nen 40 Tonner statt Sprinter mit Anhänger“ oder so. Hätte das wie gewünscht geklappt, hätte ich mir das halt irgendwie gefühlt ganz anders schönreden können…

Ist ja nicht so, dass ich nicht schon wieder Zeit in Recherche zu Alternativen gesteckt hätte - aber da gibts einfach nix Passendes zu vertretbaren Preisen.

 

[Luckysh0t]

Ist ja nicht so, dass ich nicht schon wieder Zeit in Recherche zu Alternativen gesteckt hätte - aber da gibts einfach nix Passendes zu vertretbaren Preisen.

Eher nur so halbes und nichts Ganzes - MIkrotik hat da was, aber die haben nur SFP+ und einen RJ45 - über den geht dann POE, aber der kann natürlich nur Gigabit

 

[besterino]

Je länger ich stöbere, desto mehr reift die Erkenntnis, dass das Quatsch ist. Entweder ich fahre wirklich SFP+ als Uplink, dann ist eine zusätzliche Verbindung „nur“ für POE-PD eher hirnrissig, oder ich will POE-PD, dann sollte ich mich halt von SFP+ gedanklich verabschieden.

Nun bin ich aber ich, und da geht nunmal Speed (und wenn nur theoretisch) über alles andere… also bleib ich bei dem, was ich hab. Aus die Maus.

Vielleicht hol ich die ganzen PoE-Injektoren noch runter in den Keller, dann ists immerhin am Verwendungsort der APs etwas aufgeräumter. Sollte ja Wurst sein, wo in der Kette die Injektoren stecken…?

 

[Luckysh0t]

Vielleicht hol ich die ganzen PoE-Injektoren noch runter in den Keller, dann ists immerhin am Verwendungsort de APs etwas aufgeräumter. Sollte ja Wurst sein, wo in der Kette die Injektoren stecken…?

Wäre ja mit einem Switch auch nicht anders - da ist es auch am Anfang und nicht am Ziel.