Messages

Thanks Franco for letting us know. I haven't seen this "error" since I started to use OPNsense some 6~7 years ago...
It's good to know nothing serious is there to worry about.

Same here. Unclear which log to check to see what went wrong. Other than that it seems to run fine...

I found this error

user root failed authentication for sshd on OPNsense\Auth\Services\System via OPNsense\Auth\LDAP

could this be the case?

Hi Cedric,

dig and ping is what I have used in the first place. The dig answer is that it would not resolve my internal subdomains except the one I've added in resolv.conf
The AUTHORITY SECTION: shows the name server of the provider where my domain is registered.

mydomain.com.          2418    IN      SOA    ns1.anony.nl. hostmaster.mydomain.com. 2100000175 14400 3600 604800 86400

This tells me that OPNSense does not look for my internal DNS in the first place.

Yes, this is the first entry in resolv.conf
hereafter other nameservers like 8.8.8.8 are present as well as my internal DNS server.

For some reason the hosts file is renewed automatically and removing my manual added entry and results actually into a no solution to the problem. I found an old thread where Franco advises to use an Unbound override and that solved the issue of not being able to ping my local DNS server from the console as it also resolved NGINX passing the "nginx -t" test command successfully.
Having resolved the issue for now I'm still puzzled as to why this all happened after the upgrade and making an override for all my internal addresses in not an option. I must say that this problem only exists for requests from OPNSense itself. The other networks attached to this firewall do not show this problem.

Today I've upgraded to 25.1.9_2. After the upgrade my local hosted website was no longer approachable through the OPNSense Nginx proxy server. Investigating what the problem was by pinging my local webserver url from the console the error is "cannot resolve [my website's url]: Name does not resolve" Hereafter I've tried a bunch of other local url's and all were not resolved. Conclusion can only be that OPNSense no longer is using my local DNS server to resolve local addresses. I ended up to resolve the issue for now was to input the internal url into the /etc/hosts file to make my website available for the outside world.
I can't figure out as to why this situation occurred after the upgrade to 25.1.9_2.
Any ideas?

Started to doubt myself so I dived into it somewhat deeper. I digged up old config xml files and figured that in the very beginning in my early steps into OPNsense I had un-ticked the "Password protect the console menu" option likely not knowing what I was doing at the time. The very early backup of the config xml contains <disableconsolemenu>1</disableconsolemenu>. Therefor I was used to the console menu at boot for about 5 years. Only the very last backup this line is no longer present in the config but I really cannot remember ticking the option and this likely happened unintentionally, hence my confusion.
Anyway thanks a lot for bringing this to my attention and sorry for the fuzz.

@Franco
As I am confused as well. I never ticked this option but it was ticked on both machines after the upgrade.

@ Patrick M. Hausen
Thanks, that was it! Is this a new feature? using OPNsense for 5 years now and never saw this feature. If it was there all the time than it has been ticked by the upgrade.

Today I've upgraded 2 similar servers to version 25.1.5_5 and both don't show the console menu after boot-up anymore like use to be but goes right away to the login prompt.
Is this a new feature or a bug?

Just bringing this problem again under attention since there has not been a response thus far.
Is this problem related to https://forum.opnsense.org/index.php?topic=45606.0?
It's clear from post 45606.0 that some changes were made regarding the LDAP implementation but possibly I have missed what the consequences are for already existing LDAP users. Do I need to re-create all the existing LDAP users?

Just upgraded to 25.1 and ran into this problem. LDAP bind error [; Can't contact LDAP server].
I have tested the LDAP connection prior to the update and it was still operational.
This happened on 2 machines, one after the other. Where #2 is for backup purposes.
Using the OPNSense tester results in:
The following input errors were detected:
    Authentication failed.
    error: User DN not found

I checked the connectivity from the console:
nc xx.xx.x.x 389 -v -w 10 and the response is:Connection to xx.xx.x.x 389 port [tcp/ldap] succeeded!
So what is wrong with the upgrade?
Added on Sunday 2-2-2025:
Forgot to mention that this is related to OpenVPN.
I've created for some users a local password, added local database to instance settings of OpenVPN and these users are now able to login.

My own fault. Forgot to input the associated subnet addresses in the parameter's field.

Encounter this problem on a fresh 24.7.1 install having multiple WoL cron jobs defined.
Configd_20240821.log entries are:
Waking up host B4:99:Bx:Bx:Ex:Dx followed by returned exit status 1 and next by message ... ['B4:99:Bx:Bx:Ex:Dx' ''] returned Error (1). Same goes for the other WoL jobs.
Running the manually the Wake on LAN service in the GUI performs well and the log entries are just Waking up host B4:99:Bx:Bx:Ex:Dx and no exit status 1 or Error (1).
Other Cron jobs for Letsencrypt and Proofpoint seem to run fine.

I encounter the same problem as it looks like.
I had lots of (13: Permission denied) entries in /var/log/nginx/latest.log and after altering the rights of the /var/log/nginx folder those entries were gone and log lines were stored properly in the belonging log files.
You wrote that the /var/log/nginx rights were root:wheel that differs from mine which were root:staff.
Log entries are written by nginx as user www which is as expected. I haven't tried a reboot yet but if the case is that this is changed back after every reboot that would be very inconvenient.

[SOLVED] because I've got it to work but [NOT SOLVED] because I don't understand why.
After a hairpulling night I decided to assign another user and that worked right away(???).
So next I added all the users who should have VPN access and all worked fine with the proper assigned IP address.
After a deep thought I remembered that the only difference I could think of was that with the first account I struggled with I had generated the client Certificate in System->Trust->Certificates and NOT using the System-> Access->Users page option used for the other clients. Not that I believe it matters but for completeness I should say that all users are imported from a LDAP server.
So I unlinked in the Cert of my first troublesome user in the System-> Access->Users page and created a new client Cert from the same page. Exported the config and voila it worked as should.
Now I'd like to understand why a Cert generated  in System->Trust->Certificates caused this problem. This maybe something for the developers to sort out.