Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Classic89

#1
Quote from: drosophila on December 02, 2025, 02:46:36 AMVielleicht wäre ein externer PEO Injektor die bessere Wahl für Dich? Klar ist es ein Gerät zusätzlich, aber damit bist Du bei der Wahl des Switches, inklusiver zukünftiger Änderungen, wesentlich freier.

Was das schwache Powerlan angeht, könntest Du die Adapter nochmal resetten und am tatsächlichen Anbringungsort neu verpaaren. Oft werden die nebeneinander gesteckt, gepaart, und dann verteilt. So oder so kann sich an der Verbindung untereinander was ändern (und sei es nur ein unschuldig aussehendes neue Steckernetzteil), was die ganze Signalaushandlung zunichte macht. Da kann dann eine Neuaushandlung Wunder wirken (so gesehen: von 14MBits/s zu über 200MBit/s). Die Verbindungsqualität kann man mit den Powerlan-Managerprogrammen angucken, leider aber keine Neuashandlung anstoßen oder sonstiges Management betreiben.

Generell gilt: das Einzige, was ein festverlegtes LAN-Kabel übertrifft, sind zwei festverlegte LAN-Kabel. Wenn Du also diese Chance hast: nutze sie, und verlege so viele wie möglich, wenn Du einmal dabei bist.

Denn egal was man tut: die schlechte Bandbreite kommt nicht von dem einen Port an der OPNsense Box, sondern vom Powerlan und / oder dem WLAN (hast Du ja auch so beobachtet). Eine auf 1Gigabit ausgehandelte WLAN-Verbindung bricht bei ernsthafter Nutzung aber auch schnell ein, und je mehr Parteien mitfunken (eigene Geräte oder die der Nachbarn), umso schneller wird es schlechter. Das ist bei Powerline nicht anders, nur, dass da jede Lampe, jedes Steckernetzteil, Fernseher, Computer, etc. ggfs. für Störungen sorgen. Daher ist es auf jeden Fall sinnvoll, möglichst viele Geräte möglichst direkt und per Kabel anzubinden. Da würde aber kein Unterschied zwischen dem einzelnen Port an der OPNSense Box und der Bündelung herauskommen, weil entweder der Verkehr gar nicht über die OPNSense Box läuft (z.B. für ein NAS), oder durch die Internetanbindung begrenzt ist, und bei Beidem zusammen ja eigentlich auch nicht (da begrenzt dann eher die Verbindung am Rechner). Die Portbündelung würde IMO nur dann etwas bringen, wenn 1) Deine Internetverbindung deutlich schneller ist als der Port an der OPNSense Box und 2) Deine Geräte entweder gleichzeitig oder einzeln diese Bandbreite auch absorbieren können. Deiner Beschreibung nach ist ein Gerät (der Desktop-PC) Hauptnutzer der Bandbreite und die anderen sind Nebenschauplätze. Es wäre wahrscheilich am besten, das Hauptgerät direkt anzubinden und so dem Rest das ganze W/PLAN zu überlassen, die VLANs sind dafür eigentlich egal.

Der Hauptgrund, trotzdem einen Managed Switch zu nehmen wäre die Tatsache, dass an jedem (derzeit noch freien) Port eher früher als später ein Gerät hängen wird. Und wenn der dann keine VLANs kann, ist das natürlich schlecht.

Das mit dem PoE-Injektor hatte ich auch mal überlegt, aber dann wieder verworfen weil ich eh noch einen zusätzlichen Switch dazu holen wollte um die bereits angesprochene Aufteilung von LAN (und einem VLAN für meine Arbeitsgeräte zur Isolierung vom Rest) und den VLANs für meine DMZ und IoT zu erreichen. Hier findet auch der von viragomann angesprochene Traffic über die OPNSense zwischen LAN und den beiden anderen VLANs statt. Daher würde wie ich das verstanden habe die Aufteilung hier schon etwas bringen, weil dann der Traffic durch die Firewall eben nicht durch die gleiche Leitung rein und raus muss. Dass die mangelnde Bandbreite nicht an der Internet-Verbindung oder der OPNSense liegt ist mir auch bewusst, ich bin mir hier recht sicher dass die Powerline-Verbindung das Nadelör ist. Den Tipp mit dem neu pairen werde ich auf jeden Fall auch noch ausprobieren, auch wenn ich die Adapter in der aktuellen Konstellation bereits bei Einrichtung so gepairt habe und seitdem auch nicht umgesteckt habe. Zusätzliche Verbraucher können seitdem natürlich schon dazu gekommen sind.

In jedem Fall auch euch beiden danke für die zahlreichen Hinweise!
#2
Quote from: osmom on December 01, 2025, 03:42:11 PMAus deiner Beschreibung ist mir der Sinn des 3 Switches nicht ganz klar. Du kannst doch über den neuen Kabelkanal 2 Leitungen zwischen Opensense und deinem bestehenden Switch legen.
Da dein Powerline laut deiner Beschreibung nach schwach ist,  besprich doch mit deinem Hauselektriker ob der Einbau eines Pasekopplers nicht die bessere Investition wäre. z.B. https://shop.allnet.de/ALLNET-ALL16881-Powerline-Phasenkoppler-Signalbruecke-3-Pha/112411

An dem Switch sind dafür nicht mehr genug Ports frei, müsste also eh einen neuen kaufen. Und da beide aktuell im Betrieb befindlichen Switche und auch der WLAN AP PoE fähig sind, war der Gedanke da noch einen PoE-Switch dazwischen zu schalten um sich an den "Endgeräten" zumindest teilweise noch die Netzkabel zu sparen. Gerade beim AP wäre das schon ein großer Vorteil da nur noch ein Kabel hinzuziehen.
#3
Quote from: meyergru on December 01, 2025, 12:36:02 PMOder auch nicht, weil die billigen Switche LACP maximal anhand der MACs machen. Wenn die ungünstig ausfallen, kann der Traffic zufällig auch immer nur über den selben Port laufen. Das mittelt sich statistisch erst heraus, wenn sehr viele Clients gleichzeitig Traffic verursachen - im Heimnetz eher unwahrscheinlich.

Deswegen mache ich das meist über 2.5 Gbps-Ports und verteile die VLANs gescheit, z.B. LAN auf einen Port und alle anderen VLANs auf den anderen. Meistens läuft der Inter-VLAN Traffic ja zwischen LAN und einem der VLANs, dann ist garantiert, dass zwei Ports dafür genutzt werden.

LAGG würde ich eher für Failover-Konstellationen nutzen.

Trotzdem benötigt man dafür einen managed Switch - der wird dann aber auch mit zwei Ports an die OpnSense angeschlossen.


Ja genau das war mein Gedanke, aber dann sollte ich mich wohl eher nach einem managed POE-Switch umsehen. Vielen Dank für die zahlreichen Tipps und Hinweise!
#4
Quote from: knebb on November 30, 2025, 01:10:46 PMMoin,

wenn ich auch Deine Struktur nicht so ganz durchblicke, so gilt: Finger weg von unmanaged Switchen bei Verwendung von VLAN!

Diese unmanaged Switche sind dann eher sowas wie eine Bridge. Eingehender Verkehr mit dem "VLAN42" tag wird auch auf allen Ports rausgejagt. Ebenso "VLAN3141".

Du könntest zwar einen managed dahinter schalten, aber dann blickt ja keiner mehr durch...

/KNEBB



Danke für deine Antwort. Der Gedanke war im wesentlich nur, den gesamten Network-Traffic auf beide Ethernet-Ports der OPNSense aufzuteilen und die Verteilung dahinter übers Netzwerk über einen zentralen Switch zu organisieren. Sprich zwei Leitungen aus der OPNSense raus, in einen Switch und von da aus ins gesamte Haus, also an den WLAN AP und die beiden im Haus verteilten Switche an denen alle primären kabel-gebundenen Geräte hängen. Die Aufteilung des Traffics in VLANs würde hier auch erst an den beiden "End"-Switches und dem WLAN AP (der ist VLAN fähig) gebraucht. Daher der Gedanke mit dem unmanaged Switch.

Quote from: meyergru on November 30, 2025, 01:55:59 PMLeider ist es so, dass das Verhalten von unmanaged Switches nicht genau definiert ist - im besten Fall verhalten sie sich so, als wenn alle Ports als "Trunk" konfiguriert sind, aber garantiert ist das nicht.


Danke für den Hinweis, dann ist das vermutlich keine so gute Idee.

Quote from: viragomann on November 30, 2025, 02:59:05 PMHallo,

nicht VLAN-fähige Switche verbinden einfach sämtliche angeschlossenen Geräte und vermitteln die Pakete entsprechend der Hardwareadressen. Sie kümmern sich einfach nicht um die VLAN Tags, weil sie dafür auch keine Logik implementiert haben. Soweit jedenfalls meine Erfahrung.
Also im Grunde kann man VLANs drüber schicken, wie sonst über einen Trunk Port. Eine Trennung der VLANs geht so natürlich nicht, auch nicht, wenn sie über verschiedene Leitungen laufen.

Wie du die VLANs auf die Leitungen aufteilen möchtest, ist mir auch nicht klar. Wenn du die beiden Leitungen optimal ausnutzen möchtest, konfiguriere eine Bündelung. OPNsense kann das. Der Switch müsste es natürlich auch unterstützen.
Und dieser könnte dann doch auch gleich VLANs unterstützen.
Der weitere Aufpreis hierfür ist wohl geringer als für PoE, was du ohnehin haben möchtest. Wenn du den Switch eh erst kaufen musst, sollte sich daher diese Frage gar nicht stellen.

Grüße

Der primäre Gedanke war, wie oben genannt, den Traffic auf die beiden Ports aufzuteilen. Ich hatte bisher immer so verstanden, das Bridging von mehreren Ethernet-Ports nicht empfohlen wird. Der Gedanke war, dass ich an dem Switch hinter der OPNSense nicht zwangsläufig eine VLAN-Verteilung brauche, sondern erst an den "Endgeräten", wo bereits VLAN-fähige Geräte hängen. Und nach meiner Recherche war der Aufpreis für Managed eben doch nicht so gering. Aber dann werde ich wohl eher doch auf einen managed switch für das genannte Szenario setzen müssen.

Danke auf jeden Fall für den Input an auch alle!
#5
Hallo zusammen,
ich hoffe es ist okay wenn ich hier eine eher Netzwerk-spezifische Frage stelle die nur am Rande mit OPNSense zu tun hat. Und zwar hätte ich eine Frage über die Verwendung von Unmanaged switches in Verbindung mit VLANs.

Kurz zu meinem Ausgangspunkt. Ich habe aktuell hinter meiner OPNSense-Maschine drei Netzwerkbuchsen, eine ist für das WAN, aus einer geht aktuell das LAN (und damit alle VLANs) raus und die dritte ist unbenutzt. An dem LAN hängen über eine Powerlan-Verbindung (leider keine Netzwerkkabel in der Wohnung verlegt und der Internet-Anschluss liegt sehr ungünstig) an zwei Ausgängen jeweils ein Managed Switch der die LAN-Geräte und den WLAN-AP anschließt und den entsprechenden VLANs zuordnet. Das ganze ist gerade mit dem WLAN AP eher ungünstig, da die Powerline-Verbindung die Bandbreite doch schon stark einschränkt und wenn ich auf meinem Desktop PC mal etwas größere Runterlade frisst das die gesamte Bandbreite. Daher möchte ich das jetzt auftrennen, da ich über einen Kabelkanal zumindest einen der beiden Switche direkt per Ethernet-Kabel dran hängen kann. In dem Zuge möchte ich auch noch einen dritten Switch einbauen, der direkt hinter der OPNSense sitzt und an dem dann auch der WLAN AP direkt angeschlossen werden soll. Um sich Stromkabel zu sparen, würde ich hier gerne eine POE-Switch einsetzen, da die verwendeten Switche und der AP jeweils POE-fähig sind.

Nun zu meiner Frage. Ich würde in dem Zuge auch planen, den dritten Ethernet-Port an der OPNSense zu nutzen und die VLANs gewissermaßen auf beide aufteilen. Ich plane aktuell mir einen 6 Port Switch mit 4 POE-Ports zu kaufen. In die beiden nicht POE-Ports würde ich dann die Kabel direkt aus den beiden Ausgängen der OPNSense führen und mit den POE-Ports dann die aktuell vorhandenen Switche und den WLAN AP speisen. Damit könnte ich zumindest die beiden direkt über Ethernet angehängten Geräte ohne Netzkabel betreiben. In diesem Fall müssten die VLANs an alle dahinter liegenden Switche und den AP weitergeleitet werden. Geht dies über einen Unmanaged Switch? Leitet dieser einfach den gesamten getaggten Traffic weiter? Oder ist hierfür ebenfalls ein Managed Switch notwendig, da die VLANs ja von zwei verschiedenen Ports kommen? Ich würde mir gerne den Aufpreis für den Managed POE Switch sparen, wenn er nicht unbedingt erforderlich ist. Oder bringt das Aufteilen der VLANs auf zwei Ethernet-Ports in diesem Setup gar nichts? Dann könnte ich auch weiterhin den gesamten Traffic über einen Port leiten und dann würde in jedem Fall ein Unmanaged Switch reichen.

Vielen Dank schon mal im Voraus!
#6
Ich habe es jetzt glaube ich gelöst bekommen.

Nach einem direkten Vergleich der Config-Files (danke für den Tipp mooh!) ist mir aufgefallen, dass ich bei meiner "eigenen" Konfiguration nur "qname-minimisation: yes" gesetzt hatte (was laut der Dokumentation von Unbound anscheinend eh der Default ist), während die Konfiguration in der Sense nur nach "qname-minimisation-strict" fragt. Habe "qname-minimisation-strict" jetzt auf "no" gesetzt und in einer "custom.conf" Datei die restlichen Einstellungen die ich selbst vorgenommen hatte, aber nicht von der Sense aus der GUI gesetzt werden konnten, eingestellt. Jetzt scheint es seit gestern Vormittag stabil zu laufen und ich konnte bisher keine Seite finden, die nicht im Browser aufgelöst werden kann.

Danke euch allen für die Hinweise!

#7
Quote from: mooh on August 08, 2025, 01:52:25 PMGut, vielleicht nochmal zur Klarstellung: Wenn "Dein" unbound im selben Netzwerk ist wie dein PC, dann ist keine Firewall dazwischen. Wenn jedoch die unbound Instanz auf der Sense verwendet wird, spielen die FW-Regel mit. Hier könnte eine Ursache liegen.

Die zweite Möglichkeit ist der verwendete unbound selbst. Wird die gleiche Version benutzt? Ich würde auch mal die Konfigurationsdateien vergleichen. Auf der Sense ist das /var/unbound/unbound.conf. Darin werden auch noch andere Dateien "include"d. Aus dem Vergleich der beiden Instanzen sollte klar werden, was der Unterschied ist.

Danke für die Klarstellung, ich werde mir die Logs nochmal genau ansehen ob dort etwas auftaucht.

Danke auch für den Hinweis mit der Config, schaue ich mal rein. Kann ich Unbound auf der Sense eigentlich theoretisch auch über das Config-File konfigurieren? Also zum Beispiel dort meine Config zum testen mal reinkopieren? Oder beißt sich das mit Einstellungen der Sense?
#8
Quote from: mooh on August 07, 2025, 01:18:01 PMWenn die Namesauflösung mit den üblichen Netzwerktools funktioniert, im Browser aber nicht, dann hilft vielleicht ein Blick in dessen Konfiguration. Will der vielleicht DNS over HTTPs machen oder besteht auf DNSSEC? Dann müssten die Firewall Regeln evtl noch dafür angepasst werden. Im LAN würde ich ohnehin eher darauf verzichten. Schon mal in den FW Logs nachgesehen ob das was blockiert wird?

Danke für den Tipp. Die Namensauflösung im Browser funktioniert ja allerdings mit meinem "eigenen" Unbound, nur wenn ich mit den gleichen Einstellungen Unbound auf der Sense benutze, funktioniert es in manchen Fällen nicht. Hatte um das auszuschließen es ja bewusst in mehreren Browsern ausprobiert (Brave, Chrome und Edge), überall das gleiche: Der eigene Unbound funktioniert, der auf der Sense bei den genannten Seiten nicht. Das irgendwas geblockt wird konnte ich jetzt in den Logs nicht sehen, aber dann würde es ja eigentlich in beiden Fällen nicht funktionieren. Oder sehe ich das falsch? 

Habe jetzt selbst noch mal ein wenig rumexperimentiert und es funktioniert mit Unbound auf der Sense wirklich nur dann, wenn ich "Harden DNSSEC Data", "Aggressive NSEC" und "Strict QNAME Minimisation" ausschalte. Sobald eines der drei an ist, treten wieder die alten Probleme auf. Und das wiederum finde ich dann schon seltsam, weil in meinem eigenen Unbound alle drei Einstellungen aktiv sind. Und da macht es wie gesagt keine Probleme.
#9
Danke dir auf jeden Fall für den Tipp! Aber bringt QNAME Minimisation nicht auch mehr Privacy?

Was mich aber wundert ist, ich habe "qname-minimisation" in meinem selbst konfigurierten Unbound in dem LXC auch auf "yes", und dort klappt die DNS-Auflösung der beiden genannten Fälle.
#10
Ja, ich hatte alle drei an. Hatte ich in meiner "eigenen" Unbound Instanz auch. Da hat es immer relativ problemlos funktioniert.

Habe jetzt mal alle drei ausgemacht, dann ging die beiden genannten Seiten wieder. Spannend das es vorhin, als ich Unbound komplett auf die Standard-Einstellungen zurück gesetzt hatte (also alles in Advanced aus) nicht ging. Dann gilt es jetzt wohl durch Try&Error herauszufinden welche der drei Einstellungen der Übertäter war.

Weißt du zufällig was das Problem mit den drei Einstellungen ist?
#11
German - Deutsch / Seltsames Problem mit Unbound DNS
August 06, 2025, 06:46:14 PM
Hallo zusammen,

nachdem ich lange Zeit hier nur stiller Mitleser war und hier auch unteranderem einige nützliche Dinge beim Aufbau meines Netzwerks hinter einer OPNSense gelesen habe, habe ich mich nun entschlossen hier auch mal anzumelden. Hintergrund ist, dass ich ein für mich äußerst seltsames Problem mit Unbound DNS habe und mir beim googlen bisher weder jemand mit einem vergleichbaren Problem, noch eine passende Lösung begegnet ist.

Zum Hintergrund, ich habe vor kurzem nachdem ich länger mit einer Testumgebung herum gespielt habe mein gesamtes Netzwerk hinter die OPNSense gezogen. Das ist mittlerweile auch weitestgehend abgeschlossen und es funktioniert soweit fast alles. Bis auf das oben genannte Problem mit Unbound. Ich hatte in meinem vorherigen Setup auf meinem Proxmox Server einen LXC mit Pi-Hole + Unbound als rekursiver Resolver als DNS-Server laufen. Dieser LXC ist zunächst mit hinter die Sense gezogen und fungiert dort aktuell weiterhin als Netzwerk-weiter DNS-Server. Das funktioniert soweit alles gut, Firewall-Regeln sind so formuliert dass der Pi-Hole aus allen VLAN's erreicht werden kann und er auch nach draußen telefonieren kann. Zusätzlich habe ich über Port-Forwarding Regeln eingerichtet, das alle DNS-Anfragen an andere Server automatisch an Pi-Hole umgeleitet werden. Auch das funktioniert (mit Hilfe hier aus dem Forum) sehr gut. Allerdings merke ich beim Surfen eine gewisse Latenz beim Aufrufen von Webseiten. Unter anderem aus diesem Grund (aber auch weil es logischer und einfacher erscheint) wollte ich den Unbound in dem Pi-Hole LXC durch die OPNSense-eigene Instanz von Unbound ersetzen. Diese habe ich dann ähnlich konfiguriert wie bereits die Version in dem LXC und dann in Pi-Hole als Upstream DNS-Server gesetzt sowie dem Pi-Hole in der Firewall Zugriff gewährt. Das klappt auch soweit und die Latenz ist spürbar geringer.

Allerdings habe ich jetzt einen seltsamen Fehler. Und zwar kann ich bestimmte Homepages nicht mehr aufrufen. Zum Beispiel aliexpress.com. Hier kommt z.B. im Browser Brave der Fehler "DNS_PROBE_POSSIBLE". Versuche ich das gleiche aus Chrome, bekomme ich den Fehler "DNS_PROBE_FINISHED_NXDOMAIN". In den Logs vom Pi-Hole kann ich sehen, dass der Query beantwortet wird, gleiches in den Logs von Unbound. Wenn ich im Windows Terminal

nslookup aliexpress.com

aufrufe, wird mir auch eine IP des Webservers geliefert. Allerdings kann ich die Homepage nicht aufrufen. Gleiches passiert zum Beispiel bei dhl.de, allerdings nur wenn ich den Login-Screen erreichen will (login.dhl.de). Auch hier kann man in den Logs sehen, dass der Query beantwortet wird. Aufgerufen im Browser kann es allerdings nicht.

Nun hatte ich Unbound in meinem LXC sehr aggresiv und konfiguriert und dies soweit erkennbar auch in der Konfiguration in OPNSense übernommen. Dachte also zunächst dass es vielleicht damit zu tun hat. Allerdings taucht der Fehler auch in der Standard-Konfiguration von Unbound auf. Wenn ich den Upstream-Server zurück auf die Unbound Instanz in dem LXC schalte, funktioniert wieder alles tadellos. Blocklisten in Unbound sind keine konfiguriert (der Query steht auch auf "pass") und Pi-Hole blockiert hier auch nichts, sonst würde es ja mit der anderen Unbound Instanz auch nicht funktionieren. Wenn ich den Upstream DNS auf Quad9 setze, funktioniert es auch. Also muss es hier an der Unbound Instanz in OPNSense liegen.

Ich bin mittlerweile relativ ratlos und konnte bisher im Internet nichts dazu finden. Vielleicht kann mir hier ja jemand weiterhelfen :)