Recent posts

#21

General Discussion / Re: referer protection

Last post by meyergru - Today at 12:44:53 PM

HTTP referer protection can prevent other websites from sending sensitive data over a link that was unprotected, say "https://.../xyz?login-secret=abc".

Usually, you can avoid the problem by using <a href="https://..." rel="noreferrer">" in your link.

#22

German - Deutsch / Re: Frage bzgl. Unmanaged Swit...

Last post by meyergru - Today at 12:36:02 PM

Oder 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.

#23

25.7, 25.10 Series / Re: Firewall: Log Files: Live ...

Last post by Kayakero - Today at 12:25:41 PM

> wasted space seems the same

No, it's not the same.


Cheers,
Franco

Time is truncated and Source and Destination have a lot of wasted space. That's at least how I see it.

#24

Virtual private networks / Re: Wireguard Local Traffic on...

Last post by Seimus - Today at 12:15:43 PM

Show the rules you have?

Regards,
S.

#25

General Discussion / Re: Traffic Shaping - High and...

Last post by Seimus - Today at 11:34:02 AM

would that mean that the clients in the high priority queue would get at least 60% of the bandwidth (shared fairly among them, I assume) and the clients in the low priority queue would get at least 40%?

If you use a weight based based scheduler, the weights work like a ratio. If your BW is 100Mbit the Queue with Wight 60 will get ratio 60% of that BW and a Queue with Wight 40 will get ration of 40% of the BW. If you would like to share equally the BW within the Queue for all devices that are classified into the Queue you need to as well configure MASKs on the Queue.

Keep in mind, even the devices to whom you dont want to give any BW, needs to be schaped. They need to fall into so called default class. Cause if they are not in any of those queues/pipes, they will eat into the shaped ones which will cause you exhaustion of the BW and negatively impact shaped ones.

Would this be a good way to favor my work from home computer and VOIP device over my kids video streaming? Thanks!

Depends on your usage/use-case. It may be enough from BW related terms but, weight based based schedulers do not handle bufferbloat well. They only manage BW based on weights.

Regards,
S.

#26

German - Deutsch / Re: Frage bzgl. Unmanaged Swit...

Last post by Patrick M. Hausen - Today at 11:29:08 AM

Mit einem managed Switch kannst du aus beiden Ports ein LACP-Bundle machen, und darüber beliebig viele VLANs betreiben. Je nach Anzahl der Endgeräte in deinem gesamten Netz, wird sich der Traffic dann schön auf die beiden Ports verteilen.

#27

German - Deutsch / Re: Frage bzgl. Unmanaged Swit...

Last post by viragomann - Today at 11:28:15 AM

das Bridging von mehreren Ethernet-Ports nicht empfohlen wird.

Die Empfehlung ging Richtung Bonding (IEEE 802.3ad). Das ist eine grundsätzlich andere Technik.

Grüße

#28

German - Deutsch / Re: Frage bzgl. Unmanaged Swit...

Last post by Classic89 - Today at 11:22:48 AM

Moin,

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.

Leider 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.

Hallo,

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!

[25.7.7_4]

#29

25.7, 25.10 Series / DHCP - device gets IP w/o rese...

Last post by opn_minded - Today at 11:14:26 AM

Hi there,

I have a strange issue regarding a device that gets an IP, but has no reservation set for it. First things first, I'm on opnSense 25.7.7_4. The device is a soundbar, that is connected via cable and once had 10.0.40.4 as IP reservation. Several months ago, I decided that this device doesn't need to be online anymore, so I removed it's reservation in KEA.

A couple days ago I found out that 10.0.40.4 is (still) ping-able, even though it has no IP reservation in KEA. When I disable the switch-port (where the soundbar is connected to), I can't ping that IP.

My (IoT) VLAN is defined as 10.0.40.0/24, with just a single IP (10.0.40.199/32) as pool.

In my understanding - if I haven't set up an IP reservation for a certain device (based on its MAC), this device shouldn't be able to obtain an IP and access subnets. Am I wrong or is this actually an issue?

#30

German - Deutsch / Re: IT Security Experte Floria...

Last post by opnsenseuser - Today at 11:02:33 AM

Natürlich muss man heutzutage alles hinterfragen. Die Webseite von dem Typen habe ich im ersten Post verlinkt.

Es gibt aber sicher mehr als einen Security Experten in Deutschland!

Auf seiner Seite gibts auch Veranstaltungen. Am 20-21.5.2026 dürfte er oder einer seiner Kollegene einen Vortrag halten.
Aber natürlich kann man auch das faken. Aber wenn wir so weit sind, dann muss ich mich auch fragen, ob ich mich hier nicht nur mit Chatbots unterhalte. ;-)