Recent posts

#91

25.7, 25.10 Series / Re: 25.7.8 Unbound blocklist s...

Last post by franco - December 02, 2025, 10:15:40 PM

> I understand, but if the firewalls can't work with the RFCs or vice-versa, then something is broken.

This isn't about the RFCs. It's about asking a firewall/router/distro to reload everything while reconnecting the WAN to a new prefix.

I think to this day Unbound doesn't even have a proper reload. Dnsmasq is the only software I know that has a built in for a prefix matching. pf doesn't have it either but it would be so useful, but apparently not for the use cases it is written. Maybe that's the real issue here why home users are sidelined. They are not considered a use case.


Cheers,
Franco

#92

25.7, 25.10 Series / Re: 25.7.8 Unbound blocklist s...

Last post by OPNenthu - December 02, 2025, 10:06:28 PM

I don't understand it actually... everyone is asking here to fix PD for users but we're not the ones who hand out PDs or write the actual software based on the RFCs to do it?!

I understand, but if the firewalls can't work with the RFCs or vice-versa, then something is broken.  The RFC people didn't talk with the network admins, I guess.  This is a mess because the internet is in transition to IPv6 and us non-corporate users without elaborate DHCP setups will be stuck holding the bag.

Maybe I can do something with NPT, but a point of IPv6 was to do away with address translation and centralized control mechanisms.

I'm so confused. :-/

As long as ISPs will milk users for static prefixes or not offer them at all... yes.

Maybe we will all sooner win the lottery :-)

#93

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

Last post by Classic89 - December 02, 2025, 09:54:25 PM

Vielleicht 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!

#94

25.7, 25.10 Series / Re: 25.7.8 Unbound blocklist s...

Last post by franco - December 02, 2025, 09:42:40 PM

[LAN/64]

is the same as

::123:0:0:0:0/64%lan

except that in the latter you can merge the prefix from LAN with a suffix for better targeting.

Though we were talking today about the possibility to design a simple "LAN" (per-interface) type setting that latches on to all networks currently present on the interface. I'm not saying it will happen, but it would be the simplest solution although in reality it will require a number of changes and additions to get it to the finish line in a pretty full schedule we already have.

> If not then, are we already at an impasse with IPv6 PD as a viable migration path from IPv4?

As long as ISPs will milk users for static prefixes or not offer them at all... yes.

We've been at the trying to handle end with DHCPv6, ISC, DHCP, Radvd and Unbound and it's spaghetti code that produced unnecessary bugs and reworks over the years. Even today we need a daemon to watch a modern software daemon like Kea writing a lease file so that we can extract a PD assignment to add a route. You'd think by now bindings would do that in modern software, but they don't do this in a consistent way.

I don't understand it actually... everyone is asking here to fix PD for users but we're not the ones who hand out PDs or write the actual software based on the RFCs to do it?!


Cheers,
Franco

#95

Hardware and Performance / Re: Suggestion for Bufferbloat...

Last post by OPNenthu - December 02, 2025, 09:21:40 PM

On Linux you can achieve as well A+, same as on windows the score results are as well depending on your browser performance. When you check the github link and description that testing was done in Linux on (Floorp) Firedragon browser 12. The documentation was written and all test performed as well on Linux.

Marginal differences at best, but I do get a consistent +5 to +10ms on the download portion of the test under Linux using the latest version of FireFox on both (and keeping all OPNsense parameters constant):

Linux: https://www.waveform.com/tools/bufferbloat?test-id=964b7180-4a1f-4eed-a114-1dfb613e9b63
Win10: https://www.waveform.com/tools/bufferbloat?test-id=edad2d94-d2c8-41e1-8b63-a31eeb2539bb

I've spent some time trying to close the gap but no luck :)  Maybe it's a quirk with my motherboard's i225V (rev02) NIC and the Windows driver is just a little bit better.

#96

Zenarmor (Sensei) / Re: Backup & Restore Backup Do...

Last post by OPNDeciso - December 02, 2025, 09:20:09 PM

Trying to restore downloaded backup to a different box, I get Error (200) File could not uploaded successfully.

You cannot view this attachment.

#97

25.7, 25.10 Series / Re: 25.7.8 Unbound blocklist s...

Last post by Monviech (Cedrik) - December 02, 2025, 09:10:20 PM

The issue is if you implement outside scripting that is not natively supported by the application, your only chance is to restart it all the time whwn the environment changes.

If applications would support more features like dnsmasq (which can track IPv6 addresses on interfaces, partial ones as well) it would be better. But it speaks books even KEA cannot work with dynamic prefixes (Lol btw).

#98

Intrusion Detection and Prevention / Re: Alot of SSH Traffic

Last post by chemlud - December 02, 2025, 08:49:35 PM

Skip ssh rules in your config for Suricata. Done.

#99

Intrusion Detection and Prevention / Re: Alot of SSH Traffic

Last post by spetrillo - December 02, 2025, 08:33:26 PM

Yes there are a number of web servers in this instance. Yes the Internet is a bad place...but I'd rather drop the traffic and not worry about it. I use Maxmind to provide country IP blocks inbound, and so the only thing left is to see what traffic is coming my way from approved countries and filter out the potentially bad traffic. I do not allow normal SSH over the Internet...we use our VPN for that kind of work.

#100

25.7, 25.10 Series / Re: 25.7.8 Unbound blocklist s...

Last post by OPNenthu - December 02, 2025, 08:30:23 PM

For one you'd need to invent a suffix notation that includes the interface and the netmask:

::123:0:0:0:0/64%lan

Hmm... but if I'm not concerned with hosts and instead I want to just specify a network to the Unbound config, could we not have a syntax to reference that information from either Track Interface or a network Alias on the back end?

I was imagining that the Unbound form could take something like this for input:

"192.168.1.0/24, [LAN/64]"

Of course there would need to be accompanying code to interpret that... somewhere.  :-(

Or, better, expose an option to select an interface (no IPs needed).

If not then, are we already at an impasse with IPv6 PD as a viable migration path from IPv4?