Ich habe die RADIUS-Anfragen in der OPNSense Firewall auf Port 1812 vom WLAN --> LAN natürlich zugelassen.
Es geht in der Datei offenbar nur darum, welche Clients überhaupt zugelassen werden und welche nicht. Wenn der Eintrag nicht da ist, steht in der freeradius-Log-Datei:
Wed Nov 6 20:17:55 2019 : Error: Ignoring request to auth address * port 1812 bound to server default from unknown client 172.16.16.253 port 34151 proto udp
Hier nochmal der radtest-Command:
radtest meinlogin meinpasswort server 1812 secret_aus_clients.conf
Ich habe mir dazu auf dem unifi-Controller das Paket apt install freeradius-utils nachinstalliert.
Was ich mich also nicht-unifi-Nutzer jetzt noch frage:
was muss ich bei den die APs jetzt eintragen? 1. den radiusserver, 2. ein passwort, reicht das?
welche ports müssen von den APs zum freeradius frei sein, nur der 1812 ?
wenn die APs sich in irgendeinem Netzwerk befinden, (nicht von mir konfigurierbar), muss ich dann trodzem deren IP-Adressen eintragen? Mein Radius läuft ja dann auf der 10.16.1.1/24 und die APs kommen aus z.B. 192.168.10.0/24 - funktioniert das dann überhaupt?
wenn die APs sich in irgendeinem Netzwerk befinden, (nicht von mir
konfigurierbar), muss ich dann trodzem deren IP-Adressen eintragen?
Mein Radius läuft ja dann auf der 10.16.1.1/24 und die APs kommen
aus z.B. 192.168.10.0/24 - funktioniert das dann überhaupt?
kommt darauf an, „wie“ sie von dort kommen.
Mit der IP des Gateways, schätze ich: also muss die IP des Gateways in
die clients.conf, sonst antwortet der radius denen nicht.
Ja, wenn die APs die Authentifizierung machen. Falls das ein WLAN-Controller macht, der die APs verwaltet, dann trägt man das i.d.R. beim Controller ein.
Ich habe UDP/TCP 1812:1814, weiß aber nicht, ob auch weniger ausreichen.
Ja, das geht, aber wie Holger schon sagt, kommt es drauf an, wer genau die Anfrage schickt. Bei uns ist das z.B. unser WLAN-Controller. Den habe ich eingetragen, die IPs der APs nicht. Man kann auch ganze Netzbereiche in der clients.conf angeben - falls du nicht alle IPs eingeben willst.
das ist ja technisch interessant. Ich dachte, ein WLAN-Controller verwaltet nur die APs und bei unifi würde halt die software die APs mit der entsprechenden Firmware und Konfiguration versorgen und andere machen das von Hand. Also am Ende würden alle APs mit dem Radius direkt reden. Auch, dass der unifi-controller ja abgeschalten werden kann sprach für meine Ansicht hier.
Aber wenn ich euch richtig verstehe, dann gibt es WLAN-Controller, die jede einzelne Auth-Anfrage der APs dann übernehmen und am Radius anfragen? So, dass der AP gar nicht den Radius kennen muss bzw. kennt.
Bei welchen WLAN-Controllern ist denn das der Fall, wenn ich fragen darf?
Ich vermute, dass bei uns entweder
a.) jeder AP Radius anfragen muss oder
b.) der WLAN-Controller die pfSense ist, die dazwischen geschalten ist oder
c.) der WLAN-Controller in der Cloud die Radiusanfrage machen würde.
Letzteres wäre datenschutz-, datensparsamkeits- und netzwerktechnisch total widersinnig und würde den letzten Pflock in die Unzulässigkeit unserer Lösung rammen. Dann würde die Anfrage vom AP -> cloud -> LDAP/AD einmal quer durch Deutschland gehen, um in meiner Schule ins WLAN kommen.
d.) Ich vermute mal, dass der Radius natürlich auch auf der pfSense laufen könnte, allerdings hab ich keinen Bock, das Ding nicht unter meiner Kontrolle zu haben. Außerdem will ich nicht ein Passwort meines global-binduser dort stehen haben, dann müsste ich noch einen zweiten Binduser in meinem AD anlegen - geht das?
d.) Ich vermute mal, dass der Radius natürlich auch auf der pfSense
laufen könnte, allerdings hab ich keinen Bock, das Ding nicht unter
meiner Kontrolle zu haben. Außerdem will ich nicht ein Passwort meines
global-binduser dort stehen haben, dann müsste ich noch einen zweiten
Binduser in meinem AD anlegen - geht das?
ja, das geht.
Es muss ja nicht mal ein „globaler“ sein.
Und es muss kein binduser sein: ein normaler Schüler der lehreraccount
sollte auch funktionieren.
das Wort Controller ist ja relativ schwammig. Bei uns hängen die APs in einem(mehreren) vorkonfigurierten VLANs, können mit dem „Controller“ der „in der Cloud“ irgendwo in Frankfurt steht kommunizieren und werden von dort ausgerollt.
Ich hoffe mal aber, dass sie nicht vom controller abhängig sind, d.h. nur funktionieren, wenn auch die Internetverbindung zum Controller hin funktioniert. Ist das bei euch so? Wir haben keine weitere Hardware oder software (so viel ich weiß) in der Schule dafür stehen.
Die Herstellerfirma heißt Ruckus.
VG, Tobias
Ja Wenn der Controller down ist, helfen einem die APs nichts. Die APs sind „dumm“, da der Controller alles regelt. Er regelt z.B. automatisch die Sendeleistung je nachdem, was sich gerade in der Nähe befindet, Verteilt die Clients zw. den APs, Roaming zw. den APs, usw. Wir könnten die APs auch „stand-alone“ betreiben, aber dadurch nimmt nur der Adminaufwand erheblich zu.
ok, wenn der Controller „live“ etwas zu tun hat, wie roaming, dann macht es schon Sinn, dass der Controller die Intelligenz übernimmt, dann müssen die APs ja überhaupt nichts können…
Aber die @Jungs von unifi: Ist das bei Unifi nicht so dazwischen: die APs sind nicht dumm, aber auch nicht „standalone“, sondern sie arbeiten autark (oder miteinander zusammen bei roaming) und der Controller beschickt sie beim nächsten Rollout mit Informationen, wie sie das tun sollen, aber dann kann er sich ja wieder raushalten, muss weder Radius noch Romaing übernehmen.
Oder liege ich hier völlig daneben und auch bei unifi übernimmt der Controller die ganze Intelligenz?
Hi
Bei unifi ist es so, dass im Controller steht: „Wenn du diese Option nutzen willst, muss der Controller die ganze Zeit erreichbar sein!“
Es gibt also beides: die APs können viel ohne den Controller aber eben nicht alles
Genaueres hier:
— > Does the UniFi Network Controller have to run at all times? What happens with the Guest Portal when the Controller is offline?
[Übrigens in Sachen Upgrade des unifi-Controllers und der ganzen Firmware auf allen APs verlinke ich hier nochmal das geniale Script von Glenn R., das ich hier seit vielen Monaten einsetze und das absolut genial seinen Dienst tut! Der Tipp kam seinerzeit hier aus der Community und ist absolut empfehlenswert.]
Unifi bietet dir zwar an das auch mal per App zu konfigurieren, das ist aber eher für einen AP gedacht, nicht für Netzwerke.
Die APs laufen natürlich auch weiter falls der Controller nicht zur Verfügung steht, die ganzen interessanten zentralisierten Features sowie das Raoming fallen dann aber unter den Tisch.
Danke für die ganzen Infos. Dann vermute ich, dass das bei uns auch nicht anders laufen wird.
Umso geiler, dass die dummen AP bei uns soviel Asche kosten. Wie im echten Leben: für die Dummen muss man mehr Energie und Zeit=Geld investieren, die schlauen kommen auch so weiter…
Danke. Ich habe zwei unifi-APs. Die werde ich nach meinem gusto mal konfigurieren. Da brauchts auch kein rooming (sagt die Anschie) ← kennt jemand das digitale Logbuch beim DLF Computer und Kommunikation ? Absolut geil, die Anschie und der Herr Singh…
im Zusammenhang mit Frage zu Zertifikaten bei Freeradius WLAN fällt mir auf, dass weder in der Anleitung noch in euren Posts je erwähnt wird, ob man irgendwo noch ZErtifikate installieren oder wenigstens abnicken oder ignorieren muss.
Also, muss man eurem WLAN-Controller beibringen, dass er dem Freeradius (z.B. auf dem Server) vertrauen muss (durch handling von zertifikaten?).
Nun kann man auf dem Accesspoint ein WPA Enterprise (802.1X) Netzwerk einrichten und den RADIUS-Server mit seiner IP, den Port (1812) und dem eben festgelegten Passwort/Secret konfigurieren. Nun sollte man sich mit seinem mobilen Gerät im WLAN anmelden können.
Meine letzte Frage zu den Zertifikaten (bei dir: aus eigenem Root-CA) könnte man präzisieren: Muss man das ZErtifikat im AP bzw. im WLAN-Controller „akzeptieren“ oder muss das erst der Client am Ende der Kette?
ich habe WPA2-Enterprise vor etwa einen Jahr genau so wie hier beschrieben eingerichtet
es hat auch alles wunderbar funktioniert und ich war zufrieden.
seit dem letzten Update von der LMN gab es schon mal probleme mit dem anmelden aber da hat ein neustart der APs geholfen. Die hatten wohl schluckauf
Jetzt nach dem letzen Update funktioniert es aber gar nicht mehr.
Ich habe erst mal kontrolliert ob sich config dateien geändert haben und ja ich habe eine Änderung in der /etc/samba/smb.conf gefunden da fehle ntlm auth = yes
ganz unten in der datei steht aber das man änderungen ja in der /etc/samba/smb.conf.admin eintragen soll. Dies habe ich auch getan und den ad service neu gestartet leider funktioniert es trotzdem nicht.
Hier ist die Ausgabe aus dem freeradius debug log:
(8) Received Access-Request Id 251 from 172.16.16.5:36544 to 10.16.1.1:1812 length 268
(8) User-Name = "maxmuster"
(8) NAS-Identifier = "b4fbe44d9158"
(8) Called-Station-Id = "B4-FB-E4-4D-91-58:Lehrer-WLAN"
(8) NAS-Port-Type = Wireless-802.11
(8) Service-Type = Framed-User
(8) Calling-Station-Id = "AC-AF-B9-8A-F0-2C"
(8) Connect-Info = "CONNECT 0Mbps 802.11b"
(8) Acct-Session-Id = "DE00678CF62DCA4A"
(8) Acct-Multi-Session-Id = "D2F5F03EBFEC1871"
(8) WLAN-Pairwise-Cipher = 1027076
(8) WLAN-Group-Cipher = 1027076
(8) WLAN-AKM-Suite = 1027073
(8) Framed-MTU = 1400
(8) EAP-Message = 0x02fb002e190017030300230000000000000003b52036f21799bad6526a3fb1f5830d9e00a48f63205b7c76044ea3
(8) State = 0x061eae5701e5b7c8d7443e44b29f7f43
(8) Message-Authenticator = 0x0af41675ca2364f9c54a9c19d95e3ddf
(8) Restoring &session-state
(8) &session-state:Module-Failure-Message := "mschap: Program returned code (1) and output 'The attempted logon is invalid. This is either due to a bad username or authentication information. (0xc000006d)'"
(8) # Executing section authorize from file /etc/freeradius/3.0/sites-enabled/default
(8) authorize {
(8) policy filter_username {
(8) if (&User-Name) {
(8) if (&User-Name) -> TRUE
(8) if (&User-Name) {
(8) if (&User-Name =~ / /) {
(8) if (&User-Name =~ / /) -> FALSE
(8) if (&User-Name =~ /@[^@]*@/ ) {
(8) if (&User-Name =~ /@[^@]*@/ ) -> FALSE
(8) if (&User-Name =~ /\.\./ ) {
(8) if (&User-Name =~ /\.\./ ) -> FALSE
(8) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) {
(8) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) -> FALSE
(8) if (&User-Name =~ /\.$/) {
(8) if (&User-Name =~ /\.$/) -> FALSE
(8) if (&User-Name =~ /@\./) {
(8) if (&User-Name =~ /@\./) -> FALSE
(8) } # if (&User-Name) = notfound
(8) } # policy filter_username = notfound
(8) [preprocess] = ok
(8) [chap] = noop
(8) [mschap] = noop
(8) [digest] = noop
(8) suffix: Checking for suffix after "@"
(8) suffix: No '@' in User-Name = "maxmuster", looking up realm NULL
(8) suffix: No such realm "NULL"
(8) [suffix] = noop
(8) eap: Peer sent EAP Response (code 2) ID 251 length 46
(8) eap: Continuing tunnel setup
(8) [eap] = ok
(8) } # authorize = ok
(8) Found Auth-Type = eap
(8) # Executing group from file /etc/freeradius/3.0/sites-enabled/default
(8) authenticate {
(8) eap: Expiring EAP session with state 0x061eae5701e5b7c8
(8) eap: Finished EAP session with state 0x061eae5701e5b7c8
(8) eap: Previous EAP request found for state 0x061eae5701e5b7c8, released from the list
(8) eap: Peer sent packet with method EAP PEAP (25)
(8) eap: Calling submodule eap_peap to process data
(8) eap_peap: Continuing EAP-TLS
(8) eap_peap: [eaptls verify] = ok
(8) eap_peap: Done initial handshake
(8) eap_peap: [eaptls process] = ok
(8) eap_peap: Session established. Decoding tunneled attributes
(8) eap_peap: PEAP state send tlv failure
(8) eap_peap: Received EAP-TLV response
(8) eap_peap: ERROR: The users session was previously rejected: returning reject (again.)
(8) eap_peap: This means you need to read the PREVIOUS messages in the debug output
(8) eap_peap: to find out the reason why the user was rejected
(8) eap_peap: Look for "reject" or "fail". Those earlier messages will tell you
(8) eap_peap: what went wrong, and how to fix the problem
(8) eap: ERROR: Failed continuing EAP PEAP (25) session. EAP sub-module failed
(8) eap: Sending EAP Failure (code 4) ID 251 length 4
(8) eap: Failed in EAP select
(8) [eap] = invalid
(8) } # authenticate = invalid
(8) Failed to authenticate the user
(8) Using Post-Auth-Type Reject
(8) # Executing group from file /etc/freeradius/3.0/sites-enabled/default
(8) Post-Auth-Type REJECT {
(8) attr_filter.access_reject: EXPAND %{User-Name}
(8) attr_filter.access_reject: --> maxmuster
(8) attr_filter.access_reject: Matched entry DEFAULT at line 11
(8) [attr_filter.access_reject] = updated
(8) [eap] = noop
(8) policy remove_reply_message_if_eap {
(8) if (&reply:EAP-Message && &reply:Reply-Message) {
(8) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE
(8) else {
(8) [noop] = noop
(8) } # else = noop
(8) } # policy remove_reply_message_if_eap = noop
(8) } # Post-Auth-Type REJECT = updated
(8) Delaying response for 1.000000 seconds
Waking up in 0.3 seconds.
Waking up in 0.6 seconds.
(8) Sending delayed response
(8) Sent Access-Reject Id 251 from 10.16.1.1:1812 to 172.16.16.5:36544 length 44
(8) EAP-Message = 0x04fb0004
(8) Message-Authenticator = 0x00000000000000000000000000000000
Waking up in 3.8 seconds.
(0) Cleaning up request packet ID 243 with timestamp +12
(1) Cleaning up request packet ID 244 with timestamp +12
(2) Cleaning up request packet ID 245 with timestamp +12
(3) Cleaning up request packet ID 246 with timestamp +12
(4) Cleaning up request packet ID 247 with timestamp +12
(5) Cleaning up request packet ID 248 with timestamp +12
(6) Cleaning up request packet ID 249 with timestamp +12
(7) Cleaning up request packet ID 250 with timestamp +12
(8) Cleaning up request packet ID 251 with timestamp +12
Ready to process requests
Wenn der Controller down ist, helfen einem die APs nichts. Die APs sind „dumm“, da der Controller alles regelt. Er regelt z.B. automatisch die Sendeleistung je nachdem, was sich gerade in der Nähe befindet, Verteilt die Clients zw. den APs, Roaming zw. den APs, usw. Wir könnten die APs auch „stand-alone“ betreiben, aber dadurch nimmt nur der Adminaufwand erheblich zu.