Messages

Hi Franco,

Perhaps this helps.

I tried multiple times to update from 21.1.9_1 to 21.7 without success. Last try I left it overnight ie about 8 hours and did not finish. Just kept adding dots to the log.

Then I changed the mirror to OPNSense (HTTPS,Amsterdam,NL) and the upgrade completed in less than 5 minutes.

The mirror used to be LeaseWeb Amsterdam but I also tried Leaseweb Frankfurt without success.

Regards,
Craig

Hi,

I can confirm the same issue on OPNsense 21.1.2-amd64 with 8x servers.

Launching /usr/local/sbin/opnsense-shell manually works fine.

I also confirmed Maurice fix to go into root user and hit save which worked.

Regards,
Craig

Hello hypemedia,

Have you had success with this request or found a product that can do it?

I have mostly the same situation.

Regards,
Craig

Hi Mimugmail,

So the entire issue was because our LDAP is case sensitive.

I was using cstrydom instead of CStrydom to login.

Ad look and tested for a while and came up with that brilliant deduction.

I would never have thought about it.

Regards,
Craig.

Hi mimugmail,

Apologies for the late reply.

I am busy purchasing a business subscription and support hours for this and a few more issues.

Will give feedback when I know what the heck is going on, even if I was flatheaded.

Thank you very much for trying to help.

Regards,
Craig.

Hi KernelKat,

Resetting the logfiles seemed to fix it.

I can now start syslog-ng again.

OPNSense 20.7

[Aug 12 21:09:10 pta-vpn1-2fa ntpd[19912]: kernel reports TIME_ERROR: 0x2041: Clock UnsynchronizedAug 12 21:09:10 pta-vpn1-2fa ntpd[19912]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized]

Hi mimugmail,

So I set both the local user and the ldap user's otp seed to be the same.

Google authenticator shows the same otp for both users.

local+totp works 100%

ldap+totp fails.

Just ldap works 100%

I would think the totp token is not the problem.


ntpd.log shows this but local+totp still works:


Aug 12 21:09:10 pta-vpn1-2fa ntpd[27650]: ntpd exiting on signal 15 (Terminated)
Aug 12 21:09:10 pta-vpn1-2fa ntpd[27650]: 146.64.x.x local addr 146.64.x.x -> <null>
Aug 12 21:09:10 pta-vpn1-2fa ntpd[27650]: 146.64.x.x local addr 146.64.x.x -> <null>
Aug 12 21:09:10 pta-vpn1-2fa ntpd[57512]: ntpd 4.2.8p15@1.3728-o Tue Jul 28 02:25:36 UTC 2020 (1): Starting
Aug 12 21:09:10 pta-vpn1-2fa ntpd[57512]: Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
Aug 12 21:09:10 pta-vpn1-2fa ntpd[57512]: ----------------------------------------------------
Aug 12 21:09:10 pta-vpn1-2fa ntpd[57512]: ntp-4 is maintained by Network Time Foundation,
Aug 12 21:09:10 pta-vpn1-2fa ntpd[57512]: Inc. (NTF), a non-profit 501(c)(3) public-benefit
Aug 12 21:09:10 pta-vpn1-2fa ntpd[57512]: corporation.  Support and training for ntp-4 are
Aug 12 21:09:10 pta-vpn1-2fa ntpd[57512]: available at https://www.nwtime.org/support
Aug 12 21:09:10 pta-vpn1-2fa ntpd[57512]: ----------------------------------------------------
Aug 12 21:09:10 pta-vpn1-2fa ntpd[19912]: proto: precision = 0.978 usec (-20)
Aug 12 21:09:10 pta-vpn1-2fa ntpd[19912]: basedate set to 2020-07-16
Aug 12 21:09:10 pta-vpn1-2fa ntpd[19912]: gps base set to 2020-07-19 (week 2115)
Aug 12 21:09:10 pta-vpn1-2fa ntpd[19912]: restrict: 'monitor' cannot be disabled while 'limited' is enabled
Aug 12 21:09:10 pta-vpn1-2fa ntpd[19912]: Listen and drop on 0 v6wildcard [::]:123
Aug 12 21:09:10 pta-vpn1-2fa ntpd[19912]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Aug 12 21:09:10 pta-vpn1-2fa ntpd[19912]: Listen normally on 2 vmx0 146.64.x.x:123
Aug 12 21:09:10 pta-vpn1-2fa ntpd[19912]: Listen normally on 3 vmx0 [fe80::250:56ff:fe9a:d3b8%1]:123
Aug 12 21:09:10 pta-vpn1-2fa ntpd[19912]: Listen normally on 4 lo0 [::1]:123
Aug 12 21:09:10 pta-vpn1-2fa ntpd[19912]: Listen normally on 5 lo0 127.0.0.1:123
Aug 12 21:09:10 pta-vpn1-2fa ntpd[19912]: Listening on routing socket on fd #26 for interface updates
Aug 12 21:09:10 pta-vpn1-2fa ntpd[19912]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized
Aug 12 21:09:10 pta-vpn1-2fa ntpd[19912]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized

Installed clean 20.1 - same issue.

If totp was the problem would local+totp not also be broken?

I have confirmed that the vpn server and my mobile with authenticator is 2 second out according to https://time.is/ and our VMWare administrator confirmed that the physical host time is also correct.

So I start again. Just to confirm the sequence:

1. Install opnsense 20.1 and set ip addresses

2. Configure ldap+totp server

3. Import ldap user and create qr code

4. use Tester to verify login.

mimugmail,

what opnsense version do you use with ldap+totp?

Perhaps I can try re-create your setup?

Another test:

1. deleted the ldap-totp server and the imported ldap user.

2. created ldap+totp server

3. imported user

4. generated new secret

5. added qr code to google auth

6. auth fails in tester as before

I did not know the totp server must first be created before creating the qr codes.

I deleted the imported ldap user, re-saved the ldap+totp server (changed code position back to front), then imported user, created qr code, and tested.

Still auth failure.

We use Novell/Microfocus e-Directory for ldap in case it makes a difference...

OpenLDAP template gives the same result.

Apologies mimugmail, my computer blew cpu or motherboard this morning, or I would have tested sooner.

Following your advice:

1. installed fresh 20.1-amd64 from iso on vmware esxi using freebsd 11 template

2. assigned ip addresses - wan + lan (not accessible from internet)

3. assigned port 4443 for admin portal (otherwise it clashes with ssl vpn) and set authentication servers as all local and ldap servers under System -> Settings -> Administration

4. added ldap cleartext server + authenticate successfully with Tester

5. imported 1x user (me), generated qr code and added to google authenticator

6. added ldap + totp cleartext server + authentication failed with Tester

No other modifications done at all.
OPNsense 20.1-amd64
FreeBSD 11.2-RELEASE-p16-HBSD
OpenSSL 1.1.1d 10 Sep 2019

Reset all to defaults, configured just a ldap server + totp with same results.

Reverted snapshot and updated to 20.7 with same results as before... :-\

It still gives the same error, and no ldap query on tcpdump.

No problems without totp.

Could the ldap function that splits the password and totp be the issue?