Messages

[local]

midclt, https://github.com/truenas/api_client, is required for using TrueNAS websocket API.
The script may work after installing it.

I'm sorry but that makes no sense. This has already worked after I had swapped the automation to the new websocket API, it just stopped working at some point. How could it have worked if that tool is needed?

Also, midclt isn't what you linked on github. You linked to a script that calls `midclt` LOCALLY, which in turn is present by default on any TrueNAS install. The whole point of a (websocket) API is that you don't need to install anything locally to use it. And installing it locally doesn't seem possible (as it supposedly talks to a local truenas install). Even then, there's NO chance I'm installing `midclt` on my firewall as that wouldn't survive a config backp/restore AND this is the firs thing the GitHub page says: Software in ALPHA state, highly experimental.

Did this ever get resolved or anyone find out the actual cause?

My problem is that I did setup the (new) websocket cert push, and I know it worked fine as I swapped over to that cert. Now it needed a renew, and for some reason it failed to push, showing the same symptoms as described here.

I do NOT want to run letsencrypt on the TrueNAS box as well. That's the whole point of having it on the router/firewall.

To be more explicit:
The only normally accessible error in the log is this:

Code Select Expand

AcmeClient: AcmeClient: The shell command returned exit code '1': '/usr/local/sbin/acme.sh ...When manually running that command that fails, I get the same errors the others posted (TrueNAS is not ready. and all that). to my knowledge, the TrueNAS API also doesn't need (or allow) any configuration. I'm currently still on 25.10.3.1, but .4 seems available.

So what gives?

[SHOULD]

I don't think I'm explaining the actual issue well enough, let me try to add as much detail as I can:
This isn't a general nameserver problem. It's only a a problem for aliases inside OPNsense, specifically a discrepancy between Dnsmasq and Unbound (with Unbound being the only unexpected one). The DNS setup works correctly on all hosts and the OPNsense, as far as I know and/or can tell, but ONLY the alias resolution is "weird".

First some answeres to your setup questions:

• OPNsense and all clients use the same DNS server, which is currently Unbound running on the OPNsense
• local domain is set for OPNsense via System-Settings-General-Domain
• local domain is set for all clients using DHCP (ISC; option "DNS Server" left empty; defaulting to globally set domain above)
• Upstream DNS servers are set in System-Settings-General-DNS servers, if I want to use them in the DNS
• The option "Do not use the local DNS service as a nameserver for this system" is disabled, so 127.0.0.1 SHOULD be used
• OPNsense seems to correctly use 127.0.0.1 for DNS requests
• Currently Unbound is in use as the DNS resolver, as I recently switched from Dnsmasq
• Unbound option "Register DHCP Static Mappings" is enabled and works correctly
• IPv6 isn't the problem, or even involved. The hostname(s) I'm talking about are in an IPv4 only part of the network.
• Edit: no aliases in unbound or dnsmasq are relevant or used, only hostname registration from DHCP and/or reservations

I don't have much experience with drill/dig (bit too verbose for me usually), but only the classic/old nslookup. Here are some results from various tools. ALL results are identical between running on a client system or run on OPNsense in an SSH session, unless where otherwise noted.

• ping <hostname> works
• ping <hostname>.<localdomain>.<tld> works
• nslookup <hostname> and nslookup <hostname>.<localdomain>.<tld> work and produce identical output:
  
  Code Select Expand
  Server:        <opnsense-ip>
Address:    <opnsense-ip>#53

Name:    <hostname>.<localdomain>.<tld>
Address: <actual-ip-of-hostname>
** server can't find <hostname>.<localdomain>.<tld>: NXDOMAINWhen run on OPNsense via SSH, <opnsense-ip> is instead 127.0.0.1 of course
• nslookup <actual-ip-of-hostname> returns <hostname>.<localdomain>.<tld> correctly
• dig -x <actual-ip-of-hostname> also returns <hostname>.<localdomain>.<tld> correctly
• drill -x <actual-ip-of-hostname> returns <hostname>.<localdomain>.<tld> correctly on clients, but not on OPNsense *
• drill -x <actual-ip-of-hostname> @<opnsense-ip> works correctly (everywhere)
• dig <hostname>.<localdomain>.<tld> returns correct results
• dig <hostname> does NOT return the result, but I assume this is normal?
• drill <hostname> does NOT return the result, but I assume this is normal?
• drill <hostname>.<localdomain>.<tld> works on clients, but not on OPNsense *

For the items with *: For some reason I don't understand, using drill (and ONLY drill) will use the upstream nameservers, and not the local nameservers. No other tool behaves like this, they all correctly use 127.0.0.1 (ping, nsslookup, dig).

Now for the actual description of the problem case again:
When creating an alias of type "Host(s)" in the firewall that contains one or more <hostname>, they do not resolve correctly when using Unbound. When dnsmasq is used as the DNS server/resolver, they do work like that just fine. Again, the only change is the locally running DNS server/resolver. Again: no other host in the network is involved in any way in this either. And when using <hostname>.<localdomain>.<tld> in the alias, both DNS servers resolve them just fine, proving that the correct DNS is in use, or they wouldn't be resolvable either.

Unfortunately I can't trivially switch back and forth as the OPNsense is in production use, and I can't just randomly break (or at least interrupt) the network.

Your clients are supposed to add the domain to any plain hostname before querying the DNS server. They can be told the domain via DHCP.

Yes I'm aware of this, and the local domain is correctly distributed to all clients (who can all resolve local names without the full TLD just fine). But it's not a client problem, but a difference in behaviour when using Dnsmasq vs. Unbount just inside OPNsense, and more specifically how aliases are being resolved. As far as I can tell, the local domain name is used correctly in all other places (as it's of course set in OPNsense, which is where DHCP gets the value from as well), like the examples I gave in the 2nd paragraph starting ith "to be clear".

It might be (and this is my guess) that OPNsense looks up anything written in an alias directly and without potentionally appending it's own 'local' domain (as a 'ping' or 'nslookup' would do). Dnsmasq might just imply the local domain when it receives just a flat name and tries to resolve that as well, while Unbound does not.

Yes! Use both.

I really don't want to complicate my DNS setup even more by involving two DNS servers. Also, if my above guess as to why the two servers behave differently is correct, this wouldn't even help as the request would never reach that 2nd name server: If the request doesn't include 'mydomain.tld' and only consists of 'nextcloud', it wouldn't hit the forwarding rule to the secondary server that is contingent on it.
Additionally, I actually need queries to "mydomain.tld" to be forwarded to the external DNS servers (or resolved through public recursion) if the local lookup fails. This has to do with how I am currently handling IPv4 and IPV6.

if you use your own BIND, and have alias doing internal resolution, and also have Overrides setup for say Unbound...

No overrides are involved, as the IPs aren't static. That's the whole point of having aliases as DNS names, so I can properly use them in the firewall. They already do resolve correctly in all places BUT the aliases of OPNsense (and also resolve there if using Dnsmasq as DNS), hence this request.

Edit: sorry for the late reply to my on question, for some reason I wasn't opted into automatic reply notifcations for my own created topic, which I have now fixed. Again, apologies.

Hi,

when I initially started using OPNsense, I had pretty severe issues with Unbound (not important), so I switched to using Dnsmasq. After using this for a while I switched back to Unbound.
While using Dnsmasq, I was able to have aliases for local hosts just with their local name (f.ex. 'nextcloud'). After switching back to Unbound, these no longer worked and I have to put in their FQDN (f.ex. 'nextcloud.mydomain.tld') having to edit every single local alias. This was particularly unfortunate since I then also switched my locally used domain from 'home.arpa' to a real 'mydomain.tld', and I had to edit all aliases a 2nd time.

To be clear, yes of course the 'mydomain.tld' is set as the local domain for OPNsense, and name resolution (for example in an SSH session) also works just fine with just 'nextcloud', correctly resolving it as 'nextcloud.mydomain.tld' to the corresponding IP.

Is there anything I can do to make aliases work with local names (and implicit domain) again even when using unbound?

Thanks!
Creat

Hi,

I've now had issues keeping my dynamic DNS updated and consistent. The GUI configuration in OPNsense only seems to setup the IPv4 mmonitoring side of ddclient. I have set update url to an IPv6 address, and my provider thankfully will implicitly set the AAAA record when receiving an update request via IPv6. Protocol used is dyndns2.

The problem: I often get new IPs (v4 and v6) daily, but it does happen that only v4 or v6 change on any given reconnect. Since the ddclient configuration generated by OPNsense only monitors IPv4, it'll simply say "yup, IP still the same" and not update anything despite the v6 having changed.

So, is there a built-in way to do this properly?

To be even more specific: when translating the GUI settings into the ddclient.conf, only the 'usev4' and 'ifv4' (I'm monitoring "interface" of course) settings are present. There is no 'usev6' or 'ifv6'. I have other hosts on my network that perform their own updates with a configuration like that, and that works just fine.
As far as I can tell, I calso can't just edit or change that file myself either, as any update to the ddclient package will regenerate it from the GUI config stuff and I will surely forget on the next update to check for that.

Is there some way to allow specifying the v6 stuff or just let me raw text of my own definition?
Would I need a different protocol type (custom GET or something)? But I don't think I can set the monitoring include IPv6 with that either.

Thanks!
Creat

Hi everyone,

I was on the current alpha on the "development" to have a look at the new dashboard (looks nice btw!). I think it was 24.7.1a? sorry, didn't note the exact version, but whatever is available as "Developtment" right now.

Unrelated to being on the alpha, I had to perform a packet capture and wanted to download the result. I could view it just fine inside OPNsense (so the capture itself is fine), but the download would fail with a JSON response of "Unexpected error. Please see the logs".
Unfortunately, I have no idea which logs. I checked the usual ones, but found no mention of anything.

In any case, reverting back to current community stable (24.1.7) and the download of that same capture now works fine.

Side note: please when referring someone to log files, find a way to mention which log files. There are like 20 places for log files, and it is very often completely unclear which one might be the relevant one.

Thanks
Creat

Ok got it, I can just ignore it and it'll be gone next update. It did kinda worry me if something was broken and just didn't matter cause unbound was (currently) not on.

In any case, thanks for the fast response!

I also have the same problem, well kinda? I don't actually use unbound, and it isn't active. So getting errors related to it is a bit odd. One the one hand, it isn't surprising the mounts for it don't exist since I'm no using unbound. It is surprising that upon every WAN-reconnect (and boot, I think) something tries to unmount those non-existant mounts.

This is the exact log message (imagine the time stamp at the start ;) ):

Code Select Expand

Error opnsense /usr/local/etc/rc.newwanipv6: The command '/sbin/umount '/var/unbound/lib'' returned exit code '1', the output was 'umount: /var/unbound/lib: not a file system root directory'

And this is what I get as existing mounts:

Code Select Expand

/dev/gpt/rootfs on / (ufs, local, soft-updates, journaled soft-updates)
devfs on /dev (devfs)
/dev/gpt/efifs on /boot/efi (msdosfs, local)
devfs on /var/dhcpd/dev (devfs)