Messages

You might miss the tap device setup from

Code Select Expand

/usr/local/etc/rc.syshook.d/start/50-tapstart

Unfortunately this is only a displaying matter.

Okay, I found a proper workaround that would do, preferably https://github.com/opnsense/core/blob/master/src/opnsense/mvc/app/library/OPNsense/Auth/LDAP.php would do the same.

I created /root/.ldaprc with following content:

Code Select Expand


TLS_REQUIRE_CERT TLS_HARD
TLS_CACERTDIR /var/run/certs


I left out the explicit TLS_CACERTFILE cause that name is somewhat dynamic and I didn't want to hardcode it.
I'll open an issue on Github to consider this as an enhancement.

It might be an upstream problem in PHP:
https://bugs.php.net/bug.php?id=73558

Question: Can there be any workaround, e.g. not using LDAP_OPT_X_TLS_CACERTFILE as it is anyway not working as intended? Putting the configured certificates into the global trust store might work.

Hello,

I am trying to add an LDAPS server to the list of authentication options in "System > Access > Servers". More precicely, it is the LDAPS server of Microsoft Azure AD (https://docs.microsoft.com/en-us/azure/active-directory-domain-services/tutorial-configure-ldaps).

This is working absolutely fine on a pfSense machine, users can authenticate in OpenVPN easily.

However, adding the server in OPNsense is a bit of a hassle. When testing the server, this is what the logfile says:

Code Select Expand

opnsense: LDAP bind error [error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (unable to get issuer certificate),Can't contact LDAP server]

The certificate is a self-signed one, created by an internal Sub CA (it was done on the pfSense machine, same way you can do it on OPNsense). However, it seems OPNsense is unable to verify the trust chain for the server certificate while pfSense is.

I installed the entire trust chain into the OPNsense trust store so in general the certificates are there. It just seems that they are not being used.

Can someone help me to find out more and identify the root cause? I am running on latest version 19.7.4_1.


Thanks,
Julian

---

I can confirm it is working again, potentially a peering issue of Vodafone I guess.

Yep, it is working just fine for everything else.

Just changed the screenshot to prove connectivity to another IPv6 website is working .......

Hi,

it is currently not possible to do any updates using IPv6 connectivity.
It seems pkg.opnsense.org is not responding on it's v6 address, connecting to v4 works fine.

Can somebody look into this please?

-Julian

Just wanted to let you know, after upgrading to 19.1.1 everything seems to work. Keep your fingers crossed! :-D

No issues as far as i can tell

Same

awww, people report the reboot issue to be finally fixed for the mainline version.
Sounds promising, might be worth giving it a try. but maybe not mixing it up together with 19.1 migration - just to make sure there is nothing interfering, you never know...

In my opinion, this still sounds like a bug.
"Prefer IPv4 over IPv6" should not mean the daemon shall not listen on IPv6 at all. What I'd expect is that whenever outbound connections are made, IPv4 is preferred. It might be that this is not possible to do properly with Unbound but then a dedicated setting in Unbound should be there for it and the central setting should not be taken into account.

Might be worth opening a ticket for it on Github, but that's up to you guys.

Can somebody help to guide me how to debug this any further, please?