Messages

Probably, your widget is one-column width. Try expanding it to two columns. That works for me.

Snapshots must be made by the user, they are not automatic. Fairly easy to use and a real lifesaver when things go wrong.

As long as 25.7.11_9 is running fine, hardware issues are unlikely. Nevertheless, if your system has some time, as it appears to be, I would test memory and storage (either hdd or ssd), just to rule that out.

There are mentions to Python 3.13 in this post. OPNsense has this package already upgraded in newer 26.x versions, and it seems that it's still pending in mimugmail repo. I don`t know if that could be an issue, but it seems relevant to me: os-homeassistant-maxit working with an older version than installed when you reach OPNsense 26.x with the newest Python version installed could break things.

Last night I made the mistake of trying to upgrade my system.

Upgrading is not the mistake. Lack of recovery methods is.

Next time, use snapshots at least.

1. OPNsense DHCP usually takes it's own DNS server to offer to the clients in the correct iface, assuming it uses DNSMasq or Unbound as DNS. If your case needs to serve a different DNS, it has to be configured manually.

2. Deselect both options = no auto-register from dynamic nor static DHCP leases.

3. As point 2. is done, manual overrides will give you the way to configure host by host, similar as you would do in a proper local zone.

I think this could be a good approach to solve your need, but I'm just guessing because information given is quite short. Easy to try, though.

This is a simple approach that could solve your needs. Hope it helps.


1. Be sure that your DHCP server is offering the right DNS server to your clients.

2. Uncheck "Register ISC DHCP4 Leases" and "Register DHCP Static Mappings".

3. Create "overrides" in Unbound for the needed hosts and apply/restart.

To create an override for a machine with hostname "mypc.mydomain.internal" and IP "192.168.1.2":

    Host: mypc
    Domain: mydomain.internal
    Type: A (IPv4 address)
    IP address: 192.168.1.2
    Description: Whatever that you understand in the future.

    Leave "Add PTR record" checked (default).

Maybe devs will have finished the MVC migration by then? ;)

Another 13 years? 😱

Don't be so unfaithful!!! XD

Xperienced Xenomorph

A bit of cheating with the first word, but hey!!

My 2 cents.

[security]

DENY UNKNOWN option in ISC is still needed for the more security conscious.

There are two different "ticks" in ISC:
1. Deny unknown clients.
2. Static ARP

If you want to deny addressing configuration if the client doesn't have a reserve: use 1.
If you want to deny any communication from clients without a MAC/IP coincidence: use 2.

None of them can be considered a security feature. MAC spoofing is very easy to do and thinking of this features as "security" can lead to very bad surprises.
Also, implementing "static ARP" is a delicate thing, as you could easily block yourself out. If there are more than one admin, this gets even worse.

The main point: Do no think of this features as security measures!

[Supported]

I have been making some tests installing the BIND plugin in a VM OPNsense and it works as expected, being an authoritative DNS server for our *.internal domains. Unbound makes the "query forwarding" to BIND and it responds correctly (still not tested thoroughly).

I'm considering alternatives to our current config, and installing BIND in all OPNsenses is probably the best option from a functional perspective, but it implies an increment in administration and workload.

I know that DNSmasq can act a authoritative and Unbound can't. But that's not my point. I'll try to explain it better:

What is failing in my current setup is the "query forwarding" from one Unbound to another, and that forwarding is also present with the BIND setup. As I said, I still haven't tested the new setup deeply and with enough time to be sure it will work.

To cover our needs, making "query forwardings" between Unbounds with "overrides" declared is enough, but still unknown why it sometimes fails. Docs say here:

"Register DHCP Static Mappings: Register static dhcpd entries so clients can resolve them. Supported on IPv4 and IPv6."

So static entries from Kea are supposed to work.

But instead of using that approach, I deactivate that option and use "overrides", which should also work (just in case "register mappings" has some issues).

As docs say here, Unbound resolves those names, no problem here.

The only problem is the origin Unbound NOT ALWAYS attending the "query forwarding". When it does, the setup works.

Hope this clarifies my question.

I have put a set of most-needed "overrides" in all five Unbounds to patch the problem for now, but that's very prone to errors and hard to maintain.

I may be missing something somewhere, but that behavior is not consistent. Any suggestion welcome, of course.

I think that what I need are "stub zones", which are not available in the Unbound web config in OPNsense, plus I'd need an authoritative server like BIND per network, which we don't currently run. Probably, that would be the "per the manual" structure.

On the other hand, the config I have mostly works, but it seems there is only one "affected" device, so I assume that it's globally correct and there is some issue with that particular machine/VPN/config/whatever.

I already read the OPNsense docs and the Unbound docs too, but will give them a review again. I will report and, for sure, have more questions to ask.

Yes, kind of. But a little mess for me. Doing this process with some devices is a bit difficult.

Also, I must take care of not forgetting the "no-leases" VLAN existence if I don't use it for a week or so :D

Thanks for your advice. I will try along this week and I'll report.

But one doubt emerges: How are the hostnames being declared?

Based on reservations made in Kea? Currently, this way is functional. Unbound is taking the names from the reservations, so I supposed that the "Register DHCP Static Mappings" was working.

Have to write overrides for all the hosts I need? I use this approach for local networks mostly, not remote.

Just an update with some more information.

I have found Issue from 2024 and an currently opened Issue about this.

My setup also implies VPNs and queries to other Unbounds on OPNsense, which introduces more complexity and perhaps some differences.

As @Patrick suggests in this thread, leaving a subnet with an empty list of pools has the effect desired, the server do not assign an IP to clients without a reservation.

Closing the issue on Github.