Messages

The cleanest way is to make sure neither resolver is binding to "any". If DNSmasq is on 0.0.0.0:53, I would assume it can still grab/reply on the VIP in some cases. Bind DNSmasq only to the LAN address you want the family clients to use, and bind dnscrypt-proxy only to 192.168.1.53 and 127.0.0.1. Avoid wildcard listeners for this setup.

You can't really "repair" poisoned ISP answers after the fact, especially fake IP answers. DNSSEC validation only helps if the domain is signed and the resolver actually validates or you validate locally. For DNSmasq forwarding to ISP without putting ISP DNS into OPNsense system DNS: configure DNSmasq with explicit upstream servers, not "system DNS"/DHCP-learned ones. If the GUI doesn't expose exactly what you need, use the custom DNSmasq options for `server=x.x.x.x`.

This does sound like a boot-order/race issue rather than something you're doing wrong, especially since it only happens once the NetBird device is assigned as an interface. At that point OPNsense treats it more like a normal interface during config/interface setup, but NetBird itself still needs working routing/DNS to come up cleanly. If it tries to resolve the control server before the system has a usable path, things can get ugly.

The fallback to default config is the worrying part though — that should not happen just because a tunnel interface cannot start. I'd suggest opening an issue for the plugin/OPNsense side with the boot log and config snippet for the assigned NetBird interface. As a workaround, I'd leave the NetBird interface unassigned for now and use floating/rule aliases if possible, or test with an IP-only control server plus reliable early DNS to confirm whether DNS timing is the trigger.

You can keep AGH as the client-facing DNS on port 53 and use dnsmasq only for DHCP/static leases. In that setup Unbound is still useful if you want OPNsense to do DNSSEC/DoT and act as your local validating resolver. So the usual chain would be: clients → AGH :53 → Unbound :53530 → upstream DoT. dnsmasq does not need to handle DNS unless you specifically want it to.

For static names, add DHCP static mappings in dnsmasq for the MAC/IP/hostname, and make sure AGH can resolve those local names. Depending on your setup, either forward your local domain from AGH to OPNsense/dnsmasq, or let AGH use OPNsense as upstream for that domain. Pick one local domain, e.g. `home.arpa`, and avoid using real public domains or `.local`. Also disable any competing DHCP service so only dnsmasq hands out leases.

In recent versions this was moved/changed, so you're probably not imagining it. The old Cron entry under System may no longer be where it used to be, depending on the edition/version and installed plugins.

First thing I'd check: go to System > Settings > Cron or search the menu for "cron" if your theme has the search box. Also check whether the os-cron package/plugin is still installed under System > Firmware > Plugins. If it's missing, reinstalling that should bring the cron UI back, but it won't necessarily recreate removed jobs if they weren't migrated. If you had custom scheduled tasks, it's worth checking your config backup to confirm whether they're still present there before changing too much.

I'd first check whether the certificate object is actually included in the OPNCentral provisioning payload, not only selected in the GUI. If the target never gets it into the certificate store, the Web GUI assignment can't happen either, so the issue is likely before the final WebGUI config step.

A couple of things worth trying: remove and re-add the certificate selection in the provisioning profile, save/apply, then trigger provisioning again; also confirm the cert includes the private key and is not just a public cert/CA. If possible, test with a newly created/imported dummy certificate to rule out a broken reference to the old cert object. If that still does nothing and there are no logs on either side, this may well be a regression in os-OPNcentral 1.12_2 and should be reproducible for the plugin maintainers.

This one looks more like a version/package mismatch during the intermediate upgrade step than a clear SSD failure. That class exists in the OPNsense base MVC code, so if a migration runs while parts of the old/new files are temporarily out of sync, you can hit errors like this. Since the later major upgrade completed without repeating it, I wouldn't jump straight to "bad mSATA" from this message alone.

What I'd do next: run a health audit from the GUI or console, check SMART data for the drive, and verify packages/config consistency. From console something like `opnsense-update -c` can help check the installation, and SMART will tell you if the disk is actually throwing reallocated/pending sectors or read errors. If everything is clean and the firewall behaves normally after reboot, I'd treat it as an upgrade hiccup and keep an eye on logs rather than replacing hardware immediately.