Error: Ignoring duplicate packet, LDAP performance

[Alan DeKok]

> On Feb 28, 2020, at 4:53 AM, uj2.hahn at posteo.de wrote:
> 
> Hi, freeradius team!
> I know, this "Ignoring duplicate packet" topic has been discussed for a long time again and again.

  It's almost always a slow database.

> Everything works fine, there are no user complaints so far.
> BUT: The central Meraki dashboard has a built-in test function to check all managed NAS if they are able to communicate
> with radius server. So I have to provide an existing user/password and the dashboard triggers each NAS to check for
> freeradius authentication with same credentials.
> In this scenario I run into the "Ignoring duplicate packet" issue (see freeradius log part below)

  Why is that user special?  i.e. what is different about that user account, versus the normal user accounts?

> which let the Meraki dashboard reports some NAS as failing. The count of failing NASs and the failing NASs are varying .
> However when I disable the LDAP post-auth section everything is fine.

  Then something in LDAP is blocking FreeRADIUS.

  And what are you doing with LDAP in the post-auth section?

> Wed Feb 26 14:21:05 2020 : Info: rlm_ldap (ldap): Opening additional connection (17641), 1 of 30 pending slots used
> Wed Feb 26 14:21:05 2020 : Info: rlm_ldap (ldap): Deleting connection (17640) - Was referred to a different LDAP server

  That's useful information.

> I'm pretty sure the root cause is related to general network and/or LDAP performance.

  Yes.

> Actions I will take are:
> - let network admin check the network and DC/AD server performance
> - review my freeradius LDAP queries if they are specific enough (reducing the amount of data they generate)

  What are you doing with LDAP in the post-auth section?  That's good to know.

> But I have some questions to freeradius team related to that:
> I have a single freeradius server and a single DC/AD server.

  Your LDAP server doesn't think so.

> 1) Why does freeradius open and close LDAP connections pretty often? Isn't one permanently open connection good enough?

  See the logs above.  The LDAP server is telling FreeRADIUS to look up the information in a different LDAP server / domain.

  The same machine might serve both domains, but the LDAP APIs require us to completely rebind / tear down the connections.

> 2)  What does this message mean: Info: rlm_ldap (ldap): Deleting connection (17640) - Was referred to a different LDAP server
>      There is just one LDAP server!

  Then configure it to *not* send referrals.

  Or, read mods-available/ldap, and look for "referrals".  You can configure FreeRADIUS to ignore the referral request.

  But, ignoring referrals will likely just make the LDAP query fail.

>      I started  a debug session and found this matching part in debug log:
> 
>     (25) ldap: User object found at DN "CN=jasmin hahn,OU=Schueler,DC=moritz,DC=local"
>     (25) ldap: EXPAND (samaccountname=%{mschap:User-Name})
>     (25) ldap:    --> (samaccountname=jasmin-hahn)
>     (25) ldap: Waiting for bind result...
>     (25) ldap: Bind successful
>     (25) ldap: Performing search in "DC=moritz,DC=local" with filter "(samaccountname=jasmin-hahn)", scope "sub"
>     (25) ldap: Waiting for search result...
>     rlm_ldap (ldap): Rebinding to URL ldap://ForestDnsZones.moritz.local/DC=ForestDnsZones,DC=moritz,DC=local
>     rlm_ldap (ldap): Waiting for bind result...
>     rlm_ldap (ldap): Rebinding to URL ldap://DomainDnsZones.moritz.local/DC=DomainDnsZones,DC=moritz,DC=local
>     rlm_ldap (ldap): Waiting for bind result...
>     rlm_ldap (ldap): Rebinding to URL ldap://moritz.local/CN=Configuration,DC=moritz,DC=local

  Your LDAP server is referring the query to a different AD domain.  That's pretty clear.

> 3) In my special case (self test by Meraki dashboard) I check same user from all NASs within a short timeframe.
>     So freeradius should provide always same feedback. Could the freeradius flow be shortened by a cache mechanism?

  There's a "cache" module which can be configured to cache information.  See mods-available/cache

  Alan DeKok.