Messages

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

Thanks, that rules out both of my DNS-related guesses.

In particular, the fact that restarting Unbound does not help, while restarting the inbound WireGuard instance does, strongly suggests that the problem is not DNS itself but the runtime state of the WireGuard interface after boot.

Also, I would not necessarily assume that your two observations have the same cause:

1. "Configuring WireGuard" taking a long time during boot may well be caused by S2S peers whose endpoints have to be resolved. That is to be expected, because the DNS of the endpoints is not yet resolvable and only gets corrected on first run of the cron job.

2. The C2S clients being unable to use the firewall itself as DNS afterwards is probably a separate problem with the C2S WireGuard interface not being initialized correctly.

So I would compare the actual WireGuard state before and after restarting the inbound instance.

While the problem exists, please show:

Code Select Expand

ifconfig wgX
wg show wgX
netstat -rn -f inet

Then restart only the affected inbound WireGuard instance and show the same three commands again.

In particular, check whether the configured tunnel IP address of the firewall is actually present on `wgX` in the broken state. If that address is missing or wrong, it would explain the symptoms very nicely: routed traffic through the tunnel may still work, while DNS to the firewall's own WG address cannot.

Another useful test while it is broken would be:

Code Select Expand

tcpdump -ni wgX port 53
and then try a DNS lookup from the client.

If the DNS packets arrive on `wgX`, we know that the tunnel itself transports them and can concentrate on local delivery/interface configuration instead of DNS.

At this point I would first look at the before/after difference rather than try another workaround.

[do not bind any services to specific interfaces]

Well, now I got you. I suspect this might be one of two cases:

1. You have bound your DNSmasq or Unbound to specific interfaces. In that case, when Unbound starts up, the WG interface does not yet exist and cannot be bound. You can test if this is the case by "sockstat -4 -6 -l | grep :53" and looking at which interfaces WG listens on when your error condition exists. If that is the case, you can avoid it by using "ALL" (nor no) interfaces to have the DNS service bind to 0.0.0.0. This is explained often throughout the forum: do not bind any services to specific interfaces. Besides, this is here: https://forum.opnsense.org/index.php?topic=42985.0, point 32.

2. If you are using Unbound, there is another known possibility: the automatically generated ACL for the WireGuard network may be missing after boot because the WG interface does not yet exist when the Unbound configuration is generated.

This has been reported before:
https://github.com/opnsense/core/issues/4142

Check /var/unbound/access_lists.conf while the problem exists and see whether your WG subnet is present. If it only appears after restarting Unbound, that is the cause.

Unlike the interface binding problem, the simple workaround here is to add an explicit ACL for the WireGuard client network under Services -> Unbound DNS -> Access Lists instead of relying on the automatically generated interface ACL.

This second case should only matter if your Unbound ACL default action is set to Deny or Refuse. With the default action set to Allow, the automatically generated interface ACL should be irrelevant (see: https://forum.opnsense.org/index.php?topic=42985.0, point 0). The old ticket was created when there where specific interface rules created (namely, in 2020).

For S2S connections, the cron job helps. For C2S, there should be nothing keeping your Wireguard server from starting, because the peer does not have to have an endpoint, so there is no DNS to be resolved that could keep the instance from coming up?

The "Renew DNS for Wireguard on stale connections" cron job had a problem with that specific DNS outage on startup, but it has been fixed recently, now taking care of it correctly.

This fix is in the CE version, but can manually be applied to the BE as well.

Outbound NAT is legacy, its rules should be migrated to SNAT and it will eventually go away completely (use the search):

https://forum.opnsense.org/index.php?topic=52261.0

The Outbound NAT page is essentially only there because the setting for Automatic, Hybrid, Manual and Disable NAT was still there, which is admittedly (and obviously) confusing. The last changes duplicated the mode setting to the SNAT page as well, so you can ignore Outbound NAT and have no rules left there (i.e.: migrate them to SNAT).