Messages

[not]

Franco,

Thank you, that's an excellent response. 

I had started to think it was not related to a change in DHCP as my first attempt to work around the problem was to lock all three of the isc-dhcp* packages, and the failure mode remained unchanged. 

I will run the opnsense-update tool right away.

Allan

[Have I managed to fuddle/finesse myself into a stable/correct configuration, or do I need to make further changes?]

I just experienced the same problem, but found my own solution (?) before finding this item on the forum. 

This is just a home office firewall, and wasn't getting much attention for a long while.  I had to do several updates in sequence which was all going smoothly.  Then I ran into the problem under discussion. 

As I recall it now, my mitigation went like this (minus all the gratuitous reboots and hair pulling):

I went into /usr/local/etc/pkg/repos/origin.conf and manually changed
url: "pkg+http://pkg.opnsense.org/${ABI}/16.1/latest",
to
url: "pkg+http://pkg.opnsense.org/${ABI}/15.7/latest",

I then rolled pkg back using "pkg bootstrap -f". 

I next locked pkg to the older version (I think it was 1.6.2) and changed the source back to 16.1 and completed the pkg update / pkg upgrade from the root shell.  Finally, I unlocked pkg and allowed it to update itself to the problem version. No problems so far, but maybe the shared lib dep. is still broken and my next update will fail.

This left my system in the following state (once I reached the "no more updates" end condition):

OPNsense 16.1.6-amd64
FreeBSD 10.1-RELEASE-p27
OpenSSL 1.0.2g 1 Mar 2016

I kind of thought I would be at FreeBSD 10.2 at this point as every release note for 16.1 mentions 10.2.

Have I managed to fuddle/finesse myself into a stable/correct configuration, or do I need to make further changes? 

It mostly seems to be running fine right now, but I'm afraid to poke it much until I determine if all these pieces really go together.

This is my first post here. 

I spun up the latest OPNsense two weeks ago and got basic functionality working right away.  The intent is to displace firewall duties from my main server, so that I still have Internet access on my LAN when my main server goes through a fresh-install, major version upgrade Real Soon Now. 

All my client workstations are configured with static DHCP reservations.  Once I entered in all my MAC address / IP associations and clicked the right button, I very nearly had a working DNS server for my local domain.  Two birds for the price of one.

But then on a test switch-over my wiki failed instantly, because wiki.localdomain was set up as a CNAME alias to the real server. 

So I put an explicit host record into the DNS Resolver page for bigfatserver.localdomain with a host alias for wiki.localdomain (in adding this item, I wished "@" was allowed as a synonym for the default domain as in many panel-like DNS administration tools, but I digress). 

Then I saved and reloaded (reloaded ten times over in my fiddling and frustration) and never once did the host alias resolve as a DNS name. 

I tried nslookup and dig in several modes, both with and without FQDN syntax.

If this doesn't work as I wish it to, what the heck is the host alias field for, anyway?  Or is something simply wrong with this feature in this version?  Or are CNAME style records even supported by the managed unbound service at this time?  The documentation of this feature subset is presently fairly thin, to the degree that I can't conclude with certainty what some of the fields are for.

Otherwise, I've had a very good first-time experience.  And I certainly like what I've read so far about the architectural goals and process.