Recent posts

#1
26.1, 26,4 Series / Re: OPNCentral: Automatic Cert...
Last post by Stephan M. - Today at 02:44:00 PM
Quote from: RaphaelAlbrecht on Today at 02:25:33 PMI'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.

Thank you, RaphaelAlbrecht, for your response. Of course, we had already tried all of that. We attempted to distribute the certificate centrally in countless configurations.

As a result, we reached the same conclusion as ig-it1342. The distribution only takes place when a setting in the WebGUI has also been changed manually. Only then is the certificate activated accordingly and distributed at the same time. The underlying mechanism works as described in the documentation. The WebGUI is simply provisioned only when any other value has been changed.

This means that I have to access each firewall individually and adjust one of the aforementioned settings so that it differs from the setting in OPNcentral. Only then can I centrally "push" a certificate and configure it at the same time. I would describe this behavior as unintended, since it contradicts the idea of centralized management—namely, being able to manage everything centrally from OPNcentral.

And I believe this unexpected behavior might actually be a bug.


Best regards, 
Stephan M.
#2
General Discussion / Re: WAN out connection Issues
Last post by viragomann - Today at 02:41:31 PM
OPNsense blocks private networks on WAN by default. Also response packets to incoming access on WAN are directed to the upstream gateway (ISP router) by default.

If you want to access OPNsense from WAN or devices behind it, you have to
  • remove the "Block private networks" check in the WAN interface settings,
  • check "Disable reply-to" in Firewall: Settings: Advanced,
  • add proper firewall rules to the WAN interface.

If you cannot ping the routers public IP from OPNsense, but other devices can, there might be still something wrong.
So we need some more details of your setup.

Is OPNsense running virtualized?

Did it get an IP from the routers DHCP?
Check Interfaces: Overview. Does the WAN show a gateway and the default router?

Also check the gateway status in System: Gateways: Configuration. Is the WAN gateway shown up as online?
#3
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`.
#4
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.
#5
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.
#6
26.1, 26,4 Series / Re: Cron scheduled missing?
Last post by RaphaelAlbrecht - Today at 02:25:41 PM
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.
#7
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.
#8
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.
#9
26.7 Series / Re: ZFS over UFS and config re...
Last post by BigFreddy - Today at 02:19:29 PM
Quote from: Patrick M. Hausen on Today at 02:10:07 PM
Quote from: BigFreddy on Today at 02:03:46 PMSo, if you have a config file from the time when UFS was active but you restore it at the time when ZFS is active, it technically shouldn't cause any issues?

No, none at all. The OPNsense configuration is not concerned with the underlying file system. There is even a bootstrap script turning a stock FreeBSD installation into an OPNsense - should you want to install on a RAIDZ2 topology or whatever ...

Thanks for confirming :)
#10
26.1, 26,4 Series / Re: Fatal error: Uncaught Erro...
Last post by BigFreddy - Today at 02:16:44 PM
Quote from: Patrick M. Hausen on Today at 01:23:07 PM
Quote from: franco on Today at 11:13:16 AMMonitoring is not very comfortable in my opinion, but maybe one of the available full blown monitoring tools also found in the plugins has integration for disk health.

Second thread today in which I mention that I already wrote up an easy to follow HOWTO with all bells and whistles included. Extra files on OPNsense are kept to a bare minimum and do not intervene with or might be deleted by an OPNsense update.

https://forum.opnsense.org/index.php?topic=48101.msg242617#msg242617

I seen that post but the mentioned solution requires a second device to setup where I'm looking for something that could run directly on the same firewall itself and perhaps display S.M.A.R.T readings via the dashboard. I did further research online and had trouble finding such monitoring plugin, it's really strange why there is no third party plugin to achieve this, obviously I don't know the limitations around it but generally speaking, it's something that should be possible to do.