Recent posts

#1
26.1 Series / IPv6 from Android devices stil...
Last post by rmayr - Today at 12:23:53 AM
Unfortunately, https://forum.opnsense.org/index.php?msg=262791 seems to apply to 26.1 as much as to the 25 series. I have now tried to switch from dnsmasq (which has another bug with SAs, to be reported separately) back to radvd and KEA for DHCPv6, plugging in a carp.d hook script to only let radvd run on the respective master.

This seems stable for my desktop devices, but Android devices, though they consistently get a SLAAC pair of addresses, fail to connect.

Is https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701 supposed to apply to 26.1 kernels? Has the whole patch set been reverted or is it supposed to be fixed?
#2
25.7, 25.10 Series / Re: IPv6 erratically broken fr...
Last post by rmayr - Today at 12:14:39 AM
After finding and reading through https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701, I believe that is pretty much what I am still seeing in OPNsense 25 and 26 releases (state violation leading to traffic from Android devices being dropped after a few minutes, while a pf reload or Android device re-connecting fixes the connection until it drops again a few minutes later).

@franco - was the pf patch series reverted in the OPNsense kernel in 24 and then re-introduced in 25 or 26?
#3
German - Deutsch / Re: RDNNS Problem
Last post by Patrick M. Hausen - March 15, 2026, 11:17:07 PM
Quote from: Maurice on March 15, 2026, 11:07:44 PM@Patrick Telekom Business = viel Geld für schlechtes Peering, oder?

Berechtigte Frage angesichts der Historie aber ich habe mit

- 100 Mbit/s DSL zuhause nie
- 1 Gbit/s Glas im Büro während der üblichen Bürozeiten

irgendwelche Probleme. Also beide Uplink-Geschwindigkeiten scheitern dann nicht irgendwo weiter oben am Peering.

Und die Leitungen sind alle einfach 99% und mehr stabil. Nicht ein Ausfall in Monaten. Plus feste Adressen (/32 plus /56), damit die Möglichkeit, VPNs
einfach ordentlich einzurichten, Monitoring, Remote-Access ... you name it.

Hatte einen kleinen Kunden, Ingenieurbüro der altmodischen Sorte, die hatten mal eine 2 Mbit/s "Standleitung" von uns mit unseren IP-Adressen. Irgendwann dann Telekom-DSL, aber IP weiter von uns über L2TP/ISP-Gate. Dann haben sie den Laden abgesperrt, ganz regulär, Rente ohne Nachfolger und so, wollten aber Kunden noch ein paar Jahre weiter betreuen. Haken daran: das /29 von uns, das brauchten sie unbedingt.

Also hab ich gesagt "kauft euch dieses Device von Deciso, kauft euch bei dem Kollegen, in dessen Keller das Geraffel weiter läuft, eine Telekom Business Leitung, den Rest mach ich dann". WireGuard Tunnel in unser AS, IP von uns, Thema durch.

Man kann ja meckern, aber bei der DTAG funktioniert tatsächlich für mich immer alles.
#4
German - Deutsch / Re: RDNNS Problem
Last post by Maurice - March 15, 2026, 11:07:44 PM
"Track Interface" ist legacy. Stattdessen sollte "Identity Association" verwendet werden.

Grüße
Maurice


@Patrick Telekom Business = viel Geld für schlechtes Peering, oder?
#5
German - Deutsch / Re: RDNNS Problem
Last post by Patrick M. Hausen - March 15, 2026, 10:52:10 PM
Hattest du denn die RAs auf "manuell" gestellt - da ist auch irgendwo noch so ein Schalter.

Ich gebe dir prinzipiell recht, ich mag die ganze "Magie", wie ich das normalerweise nenne, überhaupt nicht. Aber was will man machen, mit Providern, die 2026 "dynamische Prefixe" raus geben? Laut RIPE sollte jede "residential line" also vom Privatkunden bis zum kleinen Büro einfach ein statisches /48 bekommen und aus.

Deshalb habe ich überall Business-Anschlüsse, sonst fasse ich den Mist nicht an. Dann kann man alle internen Interfaces statisch konfigurieren und es funktioniert einfach immer.

Im Grunde ist IPv6 ja *einfacher* zu konfigurieren als IPv4. Wie Clemens Schrimpe immer sagte:

"Wie macht man IPv6?"

"An!"


Nur so 'n paar Gedanken. Tickets zur Verbesserung der Doku sind sicher willkommen, aus den Providern kriegt man den Kram nur mit dem Geldbeutel rausgeprügelt. Alles außer Telekom Business kommt hier üblicherweise nicht uns Büro.
#6
Hardware and Performance / Re: DEC3920 / DEC3940 / DEC396...
Last post by Seimus - March 15, 2026, 10:41:59 PM
Quote from: dirtyfreebooter on March 15, 2026, 08:38:50 PMi'm sorry, this is so completely wrong.

I am speaking about the real performance. The real performance at the end depends at the final implementation and design of all features you will use on OPN. Thats why for example even using the HW sizing provided by the ZA on their pages is not accurate, as it account performance results only for a lab state test without any overhead.

The moment you add, features, implementations and services this performance metric shifts significantly.

Quote from: dirtyfreebooter on March 15, 2026, 08:38:50 PMsomeone is going to buy one eventually and post the info, why not just include it on the product page.

Than suggest it to them, but this results account only for a favorable test case scenario. The final performance result will depend on the final implementation individual to the user.

Regards,
S.
#7
German - Deutsch / Re: RDNNS Problem
Last post by mik_schreiber - March 15, 2026, 10:34:33 PM
Quote from: meyergru on March 14, 2026, 10:25:15 PMWie gesagt, ich hatte definitiv eine ULA (fd00::1) verwendet und das ging.

Hier ging es ja darum, dort explizit etwas hinzuschreiben, was dann so in der /var/etc/radvd.conf auftaucht - und das tut es bei mir. Man sollte das Feld dann leer lassen oder - wenn man keine ULA verwenden möchte, den fe80::1 Trick verwenden (den nutze ich auch für die Default-Route, wenn ich statisch konfigurieren will).

Hat sich inzwischen geklärt - wenn Track Interface eingestellt ist, dann wird anscheinend eine Eingabe bei RDNSS ignoriert.
Aber mal ehrlich, wenn man seit ein paar Tagen bei OPNsense ist - wie soll man das wissen? Logisch ist es auch nicht, wenn die Eingabe erlaub aber dann nicht ausgeführt wird. So wie es aussieht wussten das selbst die Profis nicht auf Anhieb.

Da gibt es noch mehr Stellen - z.B MSS Eingabe die dann einen Wert berechnet der anders als die Eingabe ist.
#8
German - Deutsch / Re: Automatisch erstellte Rout...
Last post by Patrick M. Hausen - March 15, 2026, 10:28:59 PM
@daniel

- Browser Cache gelöscht?
- Nutzt du ein Theme? Mach mal aus und lösch den Cache.
- Stell mal auf Englisch um und lösch danach auch den Cache.

Je nach Ergebnis, dann vielleicht tatsächlich ein Bug-Ticket.
#9
German - Deutsch / Re: Automatisch erstellte Rout...
Last post by drosophila - March 15, 2026, 10:01:26 PM
Seltsam, bei mir ist alles normal, siehe Screenshot.
#10
German - Deutsch / Re: "Lahmes" Internet seit Upd...
Last post by drosophila - March 15, 2026, 09:55:08 PM
Der Trace sieht einigermaßen normal aus bis darauf, dass der Server auf der Gegenstelle langsam ist, aber vielleicht ist das bei telefonica halt so.
Quote from: cottec on March 14, 2026, 11:27:55 PMAlso du meinst einmal adguard rauswerfen und dann testen oder wie?
Im Browser selber hab ich keine Tools

Ich hab an dem DNS Setup 0,0 geändert seit es lahm geworden ist...
Naja, ich sehe keine offensichtlichen Fehler, und bei irgendwas muß man ja mit Testen anfangen. :) Adguard und die DNS-Umleitung ist zwar nicht komplett ungewöhnlich, aber wenn es ein generelles Problem wäre, wären sicher schon mehr Hilferufe aufgetaucht. Und es mag ja durchaus sein, dass die neue Version anders mit derselben Konfiguration umgeht als die Alte. Es kann auch schlichtweg an sowas liegen, dass z.B. jetzt eine DNS-Anfrage gedroppt und nicht geblockt wird, und der Browser deshalb erst in einen Timeout laufen muß. Da ich derzeit meine Werbeblockierungen komplett clientseitig mache (eben über die o.g. Addons, die meisten anderen Programme werden komplett geblockt), kann ich zu Adguard und Pihole nicht allzuviel sagen. :( Vielleicht kann da aber jemand mit Nutzungserfahrung mal über die Regeln schauen; ohne Adblocker in die asozialen Netzwerke zu gehen ist ja keine gute Idee, aber wenn auch die OPNsense-Seite betroffen ist, kann man ja da testen, das sollte ja halbwegs sicher sein.