OpenVPN 25.1 -> LDAP bind error [; Can't contact LDAP server] after upgrade.

[RosIsTer]

As far as I understand the capture result the bind is successful, so the ldap user isn't the problem.

However I'm struggling to understand what happens after that other than the disconnect.

IP ending on 1 is Opnsense, 80 is a domain controller. There are more DCs, but for troubleshooting it's the only one I kept active on Opnsense.

[Patrick M. Hausen]

The LDAP bind should be followed by an LDAP search request, which it did not in your screen shot. Did you try a full authentication or the "tester" in OPNsense?

Maybe something with base DN, LDAP filter or some such ...

[RosIsTer]

Full authentication, so logged out of the web gui and tried to login with an ldap account.

I assume I can rule out a firewall rule anywhere blocking anything if the connection gets established in general. Between Opnsense there's only the packet filter of Opnsense itself and the personal firewall of the Domain controller (which allows LDAP of course).

[Patrick M. Hausen]

Hmmm ... can you try the tester? There must be an LDAP search following the bind ...

[RosIsTer]

No, I'm afraid not, used the tester here. I hope the images are still readable, had to resize them in order to attach them.

Not sure if frame nr. 2 is of any significance.

A note about the configuration page of the LDAP server: The "select" button next to "Authentication containers" works fine and shows me all the entries I'd expect.

I can only emphasize this worked flawlessly until the v25 upgrade. I was used to logging in only with my domain/ldap account, not the local root account. I initiated the upgrade to v25 and right after the reboot I couldn't login anymore.
There were also no changes to the domain controllers.

Just a note: There's also an Apache webserver in the same subnet using LDAP auth for some resources with equal settings - works fine.

[Patrick M. Hausen]

That looks like some extra characters in the search string - to which the server probably correctly responds with "NO_OBJECT". Weird.

I'm sorry, I only run LDAP for OpenVPN without issues so I cannot reproduce it easily. I just happen to know LDAP a bit from years of experience with AD, so I chimed in.

I'd file a bug on github.

[RosIsTer]

Thanks for trying to help!

Probably not a bad idea. I opened a bug report: https://github.com/opnsense/core/issues/8541

[dsvfhiubfdg]

its not a new deployment, its already used in production on older 24.7 releases.

I planed to upgrade and thats the point where i cant because of an update that bricked something, and i am not alone.

With no encryption I cannot reproduce the problem with our test ldap, hopefully it is clear that you should not use it productively, the productive ldap is LDAPS only.



with LDAPS im getting exactly the same on our testing LDAP which speaks LDAPS as well as LDAP.
2025-04-14T10:46:48    Error    opnsense    LDAP bind error [; Can't contact LDAP server]

What do i need to provide so we can debug this more?

[RosIsTer]

I got it to work by emptying the extended query field.

See the linked bug report. It's being further discussed there.

[Patrick M. Hausen]

Now THAT's interesting ... thanks for keeping us informed.

I just had to check - I do use extended query and I do not experience your problem. I use it to limit access to a particular group by matching "memberOf". But I did not put an outer pair of parentheses in the field. Want to try using just "objectClass=person"?

[franco]

Parenthesis shouldn't matter here as sooner or later the query parts are wrapped in extra parenthesis in order to construct the full search string. Apparently case also wasn't the issue so this remains a bit elusive...


Cheers,
Franco

[RosIsTer]

Good ideas.

I did some further tests. Apparently whatever I enter in there will not work if there are outer parenthesis.

So this will not work:
(&(condition1)(condition2))

This does work:
&(condition1)(condition2)

[Patrick M. Hausen]

If the OPNsense code adds another pair of outer parentheses, probably "(filter)" is valid while "((filter))" is not. I could not find a full spec, i.e. EBNF just right now. The LDAP RFC hand simply refers to X.500 and ASN.1, unfortunately, and I'm not going down that rabbit hole just now.

[franco]

I made a note here because some claims regarding wrong defaults and unclear documentation were made... https://github.com/opnsense/core/issues/8541#issuecomment-2808614328

[Patrick M. Hausen]

I added some explanation to what is probably going on.