Radius Server in UCS 5.0 startet nicht

Apps & App Center
#1

Hallo Leute,

wie mir scheint, hat sich der Radius bei mir nach dem Update auf 5.0 ziemlich unschön verabschiedet.

Ein bisschen Debugging hat ergeben, dass das Verzeichnis ‘sites-enabled’ in /etc/freeradius/3.0 abhanden gekommen ist. Da es vor dem Upgrade noch funktioniert hat, schiebe ich jetzt mal ganz frech dem Update die Schuld in die Schuhe.

Nach dem Erstellen des genannten Verzeichnisses motzt der Radius nur noch wegen fehlendem EAP Modul herum, was sich durch anlegen der fehlenden Symlinks (default, inner-tunnel) noch lösen lässt.

Hoffe es hilft jemandem.

lg
Rei

Nach dem Upgrade auf UCS 5.0
#2

Ich denke, dass ich das Problem nachvollziehen kann - nur welche Symlinks sind gemeint? :thinking:
Also was genau von wo nach wo?

#3

in ‘sites-enabled’ sind symlinks zu den Configs die in ‘sites-available’ liegen. Debian-Eigenheit um zB auch bei Webservern mal Seiten offline zu nehmen.

root@ucs:~# ls -als /etc/freeradius/3.0/sites-enabled/
insgesamt 8
4 drwxr-xr-x 2 root    root    4096 Mai 25 22:48 .
4 drwxr-xr-x 9 freerad freerad 4096 Mai 25 22:42 ..
0 lrwxrwxrwx 1 root    root      26 Mai 25 22:48 default -> ../sites-available/default
0 lrwxrwxrwx 1 root    root      31 Mai 25 22:48 inner-tunnel -> ../sites-available/inner-tunnel
1 Like
#4

Danke, ich habe wie blöd in mods-available geschaut… :+1:

#5

Hat’s geholfen? Ich hab’ nämlich hier 'ne Weile gebraucht da mein ISP einen Ausfall hatte als mein Radius down war…

#6

Ja - Radius startet jetzt - vielen Dank!

Allerdings kann ich mich noch nicht damit verbinden… Ich habe vor einen halben Jahr neue Access-Points gekauft und da etwas an den Einstellungen in ‘clients.conf’ verändert und natürlich alles wieder super dokumentiert… :roll_eyes:

#7

Jetzt würde mich interessieren was die Logs sagen… Startet der Radius zumindest?
systemctl status wäre da ein Anfang sowie mal in /var/log nach FreeRadius Zeug suchen

#8

also man findet ja ganz komfortabel /var/log/freeradius die log-files…:

Sat May 29 19:26:32 2021 : Auth: (9)   Login OK: [bernd] (from client vigor903 port 0 via TLS tunnel)
Sat May 29 19:26:32 2021 : Auth: (10) Login OK: [bernd] (from client vigor903 port 0 cli <MAC>)
Sat May 29 19:28:49 2021 : ERROR: (18) eap: ERROR: rlm_eap (EAP): No EAP session matching state 0x02bc8b8604b492b8
Sat May 29 19:28:49 2021 : ERROR: (18) eap: ERROR: rlm_eap (EAP): No EAP session matching state 0x02bc8b8604b492b8
Sat May 29 19:28:49 2021 : Auth: (18) Login incorrect (eap: rlm_eap (EAP): No EAP session matching state 0x02bc8b8604b492b8): [bernd/<via Auth-Type = eap>] (from client vigor903 port 0 cli <MAC>)

Das waren die letzten Fehlermeldungen, die ich finde… Ab kommt nur noch:

Sat May 29 20:12:03 2021 : Info: rlm_ldap (ldap): Closing connection (16): Hit idle_timeout, was idle for 336 seconds
Sat May 29 20:12:03 2021 : Info: rlm_ldap (ldap): Closing connection (15): Hit idle_timeout, was idle for 335 seconds
Sat May 29 20:12:03 2021 : Info: rlm_ldap (ldap): Closing connection (17): Hit idle_timeout, was idle for 335 seconds
Sat May 29 20:12:03 2021 : Info: rlm_ldap (ldap): Opening additional connection (18), 1 of 32 pending slots used
Sat May 29 20:12:03 2021 : Info: Need 2 more connections to reach min connections (3)
Sat May 29 20:12:03 2021 : Info: rlm_ldap (ldap): Opening additional connection (19), 1 of 31 pending slots used
Sat May 29 20:12:03 2021 : Auth: (88)   Login OK: [bernd] (from client vigor903 port 0 via TLS tunnel)
Sat May 29 20:12:03 2021 : Auth: (89) Login OK: [bernd] (from client vigor903 port 0 cli <MAC>)

Allerdings bekomme ich noch keine IP-Adresse an mein iPhone geliefert.

#9

Poste mir mal bitte deine radius config. Vielleicht kann ich was erkennen.
Dazu kommt noch: Hast du genug Cores für die Threads? Packet Loss am Netz?

Für mich sieht das so aus als müsstest du den Cache bzw das Timeout etwas tweaken (cleanup_delay and friends)

#10

Also wenn die ganzen Rauten raus sind bleibt es übersichtlich:

root@ucs-01:/etc/freeradius/3.0# cat clients.conf
# -*- text -*-
##
## clients.conf -- client configuration directives
##
#######################################################################
#
client localhost {
        ipaddr = 127.0.0.1
        proto = *
        secret = testing123
        require_message_authenticator = no
        secret          = testing123
}


client default {
       ipaddr          = 198.168.xy.0/24
       secret          = ***secret***
}

Im Moment denke ich eher, dass es an meinem DHCP-Server oder AP liegt, da die IP-losigkeit gerade auch ein SSID ohne Radius befällt… (?)

#11

Sorry, mein Fehler - radiusd.conf

#12

Ha, das sieht ganz interessant aus, aber auch ganz ok - oder?

root@ucs-01:/etc/freeradius/3.0# cat radiusd.conf

prefix = /usr
exec_prefix = /usr
sysconfdir = /etc
localstatedir = /var
sbindir = ${exec_prefix}/sbin
logdir = /var/log/freeradius
raddbdir = /etc/freeradius/3.0
radacctdir = ${logdir}/radacct

name = freeradius

confdir = ${raddbdir}
modconfdir = ${confdir}/mods-config
certdir = ${confdir}/certs
cadir   = ${confdir}/certs
run_dir = ${localstatedir}/run/${name}

db_dir = ${raddbdir}

max_request_time = 30

cleanup_delay = 5

        destination = files

        colourise = yes

         file = ${logdir}/radius.log

 checkrad = ${sbindir}/checkrad

security {
        status_server = yes
}

proxy_requests  = yes
$INCLUDE proxy.conf
$INCLUDE proxy.conf.debian

$INCLUDE clients.univention.conf

$INCLUDE clients.conf

thread pool {
        start_servers = 
        max_spare_servers = 10

        max_requests_per_server = 0

        auto_limit_acct = no
}

instantiate {
}

policy {
        $INCLUDE policy.d/
}

$INCLUDE sites-enabled/
#13

An den Werten wirst du wahrscheinlich geschraubt haben.

#14

:smiley: nicht dass ich wüsste…
wobei die max_request_time = 30 könnte schon sein…

Was hättest Du da erwartet?

Aber die gute Nachricht ist - Radius-Anmeldung funktioniert nun.
Tatsächlich ist der univention-dhcp auf dem backup node nicht gelaufen.

#15

Frag lieber nicht :slight_smile:

#16

:slightly_smiling_face: na gut - dann Danke nochmal für die Lösung oben und fürs Mitdenken.

#17

Die Lösung hier macht zwar dass der LDAP-Server wieder läuft und ich erhalte nur noch
“(6) Login OK:” -Meldungen. Jedoch funktioniert das irgendwie sowohl mit meiner pfsense, als auch mit meinem unifi-AccessPoint nicht.

#18

Darf der User überhaupt einloggen? Schau das bitte mal nach, ob bei dem Benutzer beim radius ein Haken gesetzt ist

#19

Ja der user hat das häckchen bei “Radius -> Netzwerkzugriff erlaubt” ich glaube sonst gäbe es das “Login OK” auch nicht.

#20

Dann vermute ich mal den Fehler auf der Seite der pfsense. Hat das Ding irgendwas in den logs?

Mastodon