Messages

Darin, dass es sich dabei um Layer-2-Traffic handelt, den Deine Firewall nicht sieht?

You cannot compare the former Mono price of $600 to today. It was set in early 2025, which where different times in terms of component prices.

The web site does not have a price for the shipping product and YT videos have become spare, the last one was this: https://www.youtube.com/watch?v=7f2BjPPJEWg, stating that the first batch of 1000 machines have been delivered and that Tomaž had a burnout.

I reckon that the price of the real product - if it ever arrives - will be much higher.

Kea sagt damit:

Multi-Threading ist aktiv. Deshalb werden Host-Reservations immer vor dem Lease-Lookup geprüft.

Normalerweise gibt es dafür die Option reservations-lookup-first. Wenn Multi-Threading aus ist, bestimmt diese Option, ob Kea zuerst nach einer statischen Reservation oder zuerst in der Lease-Datenbank sucht. Bei aktiviertem Multi-Threading ignoriert Kea diese Einstellung und erzwingt ersteres. Dadurch soll Locking auf der Lease-Datenbank vermieden werden.

Bei Multi-Threading würde eine etwaige Einstellung "reservations-lookup-first": false einfach ignoriert. Die Warnung ist etwas unglücklich, weil auf OpnSense eben Multi-Threading an ist, die Option wird aber per Default m.W. gar nicht gesetzt.

Ich bin mir nicht sicher, ob Kea "fremdvergebene" Leases bei bloßer Verlängerung anzeigt. Abgesehen davon kann es ja sein, dass Dein Client noch gar nicht wieder gefragt hat, weil die alte Lease noch nicht abgelaufen ist?

Entscheidend ist eigentlich nur, dass Kea läuft und die Option "Firewall rules" aktiv ist, um den Zugriff zu ermöglichen.

Woher glaubst Du zu wissen, dass der Client seine IP nicht vom Kea bekommt? Läuft Kea?

Es kann gut sein, dass Kea von Deinem Client einen Renew-Request für dessen alte IP bekommt, den er eventuell gewährt, obwohl er eine feste Reservierung für eine andere IP hat (oder hatte). So etwas passiert auch gern, wenn der Client zuerst einen Lease bekommt und man den dann in eine feste Reservierung mit einer anderen IP umwandelt - dann muss man erst die alte IP/MAC-Zuordnung aus Kea löschen.

Außerdem kann es so sein, dass "Match client-id" eingeschaltet isr, woraufhin die Reservierungen anhand von Client-IDs und nicht von MACs vorgenommen werden. Dann würde Dein Client eventuell in den Leases auftauchen.

[not]

"drill" without any options explicitly randomizes the nameserver list. For the test you want, you must use "drill -z".

But that probably does not solve your actual issue. When OPNsense itself resolves a name using the servers from resolv.conf, they are normally tried in order, so you already have a kind of fallback there. The same is not guaranteed for DHCP clients to which you hand out a list of DNS servers.

The clients decide for themselves how to deal with a list of DNS servers, and that behavior differs between operating systems. Therefore, handing out AdGuard as DNS1 and Cloudflare as DNS2 does not reliably mean "use AdGuard unless it is unavailable".

If you want a real fallback for your clients, hand out only the address of a local resolver and implement the fallback there. For example, OPNsense's Dnsmasq has the option "Query DNS servers sequentially", which queries upstream DNS servers in the configured order.

Unbound with multiple forwarders would not provide strict primary/fallback ordering, as Unbound selects forwarders based on its own server-selection and RTT logic.

Als mSata gibt es einiges von Transcend. Die Suchkriterien (DRAM-Cache und hohe TBW) sind die selben.

Ja, Power Limits runter, wenn Dein BIOS das erlaubt. N1x0 haben nominell eine TDP von 6 Watt, können aber je nach PL auch mal 20 Watt aufnehmen. Leider wollen die BIOS-Hersteller immer die maximale Performance und stellen manchmal das PL auf 25 Watt. Bei 10 Watt verlierst Du nur minimal Leistung, sparst aber Strom.

Was die SSD angeht: die ab Werk verbauten sind in dreierlei Hinsicht mies:

1. Sie haben eine hohe Stromaufnahme.
2. Sie verwenden Billigchips (QLC) und haben damit eine geringe TBW.
3. Sie sind billig und haben meist keinen DRAM-Puffer, was mehr Schreiboperationen zur Folge hat.

Alle drei Parameter wirken auf die Lebensdauer, aber vor allem 2 und drei kann man sogar mit smartctl auslesen. Besonders bitter wird es, wenn man dann noch RRD auf die SSD und nicht im RAM laufen lässt. Billig-NVMEe sind dann oft schon nach einem Jahr hinüber.

Also:

1. RRD ins RAM verlagern (System: Settings: Miscellaneous "/tmp RAM Disk"
2. Nächste NVME mit DRAM-Cache und hohem TBW kaufen. Siehe Geizhals.de. Ich empfehle die Kingston KC3000.
 

https://github.com/meyergru/iscdhcp_to_kea

(wenn da nicht bereits ein CSV-Export für ISC DHCP existieren sollte)

It depends solely on your ISP if your actual IP changes upon reconnect - there is no way to force this from the client side. You should be able to see that the connection is coming down an up again in the logs, though.

In your first linked thread, Patrick even showed the screen shot and explained where to find it.

In a strict sense, you would need a separate VLAN for any specific device. Most people only separate an "IoT" VLAN.
There are smart switches and networking equipment, where you can even keep devices on layer 2 separate. Unifi can do that on their WiFi networks ("Client Device Isolation", but it inhibits Airplay, Chromecast and others).

If you do not want network access for a single network device, you can block that specifically on OpnSense, even without having VLANs. Note, however, that this would strip a smart TV from most of its prominent features, like streaming.

As long as your device has internet access, it can spy on you even when it cannot reach its neighbors one way or another. As the video shows, the webcams and microphones are accessible from outside.

Please see reply #7 and provide the information requested there. Otherwise, there is little point in further speculation.

This appears to be the already identified caddy-l4 routing bug described in PR #455, rather than merely another insufficient prefetch-buffer size.

If a TLS matcher needs more data because the ClientHello arrived in multiple TCP segments, a subsequent HTTP route can reach a definitive non-match and inadvertently suppress the pending TLS match. Post-quantum ClientHellos make this much more reproducible because they commonly span multiple TCP segments.

This fits your observations exactly: curl and Firefox without Kyber send a smaller ClientHello, whereas current Firefox and Chromium trigger the bug.

As a workaround, try placing all Layer 4 HTTP routes before all TLS/SNI routes. PR #455 specifically identifies that route ordering as a workaround and states that caddy-l4 0.1.2 is affected. IDK if that is possible via the GUI, though... otherwise, Deciso would have to either include the PR or change configuration ordering.

[did]

As for Q1: I do not know. But that does not really matter. Even if DNS is broken immediately after OPNsense boots, the cron job should eventually heal that condition. As I already stated, this should not be your main concern; you can shorten the recovery time simply by running the cron job more frequently.

What your experiments did establish quite convincingly is my earlier point about FQDN resolution causing problems with S2S connections.

Alas, you did not provide any of the diagnostic information I asked for that could actually shed light on what goes wrong when a C2S client cannot resolve DNS.