Messages

Creating a virtual switch (bridge) that manages the VLANs can be a good approach. Then, the client machines networks can be connected as the user needs with no config inside.

When you create a VLAN in OPNsense, it's traffic will be always tagged, so the next hop must be VLAN-aware, either a (virtual)switch or a (virtual)machine. Otherwise, you have the proper Layer 2 segmentation.

I suspect that ISC is retaining the dynamic lease, even after a restart. That is also the behavior you will find in Kea at the moment, but it seems it will have a "Delete lease" button very soon, according to https://github.com/opnsense/core/pull/10019

If you want to migrate from ISC to dnsmasq or Kea, you can export your reserves and import them in the new service. Don't forget to deactivate ISC before activating the new DHCP service. No need to reinstall or re-create a new firewall from scratch.

Assuming that the alias has been created correctly:

interface
      -lan

That implies that the IoT devices resides in the "lan" interface. If they are in a different network, choose accordingly.

direction
      -both

Only direction "in" is needed if you want to prevent the IoT devices accessing outside.

source
      -internet net, internet address

Source should be your IoT devices (the alias you created beforehand).

destination
      -IOT devices (I have set an aliase and direct IP)

Destination should be "Any" if you don't want them to communicate outside their network.

I nearly fell for it.... April Fools.

I suppose that, too, but found this:

https://www.netgate.com/blog/netgate-releases-pfsense-plus-software-version-26.03

And it says "It lays the foundation for the future of pfSense software, including native Linux support."

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.