Freeradius mit mariadb verweigert Authentifizierung

Moin,

ich habe unter einem Hyper-V eine Debian 9 Installation mit freeradius, daloradius und mariadb. Soweit läuft das Ganze wie gewünscht. Dann steht im NAS plötzlich
"Die wiederholten Authentifizierungsversuche von User[MAC] beim Beitreten...schlugen fehl" und eine Anmeldung ist nicht mehr möglich. Im Radiuslog versucht im 30 Sekundenrythmus ein anderer Client sich zu verbinden, was laut Log auch klappt. Diese Client hatte sich auch schon morgens angemeldet, ohne Probleme. Auch andere Clients haben solche Authentifizierungsversuche alle 30 Sekunden fabriziert, aber eben auch nicht immer.


Mon Jul 22 09:52:37 2019 : Auth: (5130) Login OK: [Bernd/<via Auth-Type = eap>] (from client NAS port 0 via TLS tunnel)
Mon Jul 22 09:52:37 2019 : Auth: (5131) Login OK: [Bernd/<via Auth-Type = eap>] (from client NAS port 45 cli aa-bb-cc-dd-ee-ff)
...

...
Mon Jul 22 11:02:53 2019 : Auth: (6345) Login OK: [Bernd/<via Auth-Type = eap>] (from client NAS port 0 via TLS tunnel)
Mon Jul 22 11:02:53 2019 : Auth: (6346) Login OK: [Bernd/<via Auth-Type = eap>] (from client NAS port 96 cli aa-bb-cc-dd-ee-ff)


Zwischendrin reihen sich noch andere Nutzer in diesen 30 sekündigen Takt ein, nutzen dann scheinbar aber die alte WPA2 SSID.

Ich finde nichts aussagekräftiges im radius.log oder NAS. Ich hatte die Speicherverwaltung des Hyper-V in Verdacht, da hier dynamischer Speicher steht und dieser immer mehr fordert, als ich ihm zuweise. Im Debian TOP dann allerdings die kleinste Menge von 1G steht.

Ich vermute durch diese ständige Anmelderei wird der Radius oder etwas anderes belegt und es kommt zu einem Fehlschlag, nicht zu einem reject. Dieser steht aber nicht im radiuslog, nur im NAS. Das NAS gibt aber auch nicht an, dass es den RADIUS nicht erreicht.

Kann mir jemand einen Tip geben, was oder wo ich noch schauen soll?

Als Plan B werde ich den Radius aus der pfsense nutzen und nur die user.conf ohne sql nutzen. Mehr brauchen wir aktuell nicht, wollte mit dem sql nur aussagekräftiger sein bezüglich Bandbreitennutzung.

Danke!

                #
                #  As of version 3.0.5, this configuration item
                #  is deprecated.  Instead, you should use
                #
                #       update outer.session-state {
                #               ...
                #
                #       }
                #
                #  This will cache attributes for the final Access-Accept.
                #
                #  The reply attributes sent to the NAS are usually
                #  based on the name of the user 'outside' of the  
                #  tunnel (usually 'anonymous').  If you want to send  
                #  the reply attributes based on the user name inside
                #  of the tunnel, then set this configuration entry to
                #  'yes', and the reply to the NAS will be taken from  
                #  the reply to the tunneled request.
                #
                #  allowed values: {no, yes}
                #
#               use_tunneled_reply = no
use_tunneled_reply = yes