05.04.2018, aktualisiert um 11:32:37 Uhr

2859

PFSense und FreeRadius3 Authentifizierungsproblem

Hallo Zusammen hier im Forum,

ich habe ein Problem bei der Einrichtung von FreeRadius und PfSense.
Da ein Bild mehr als 1000 Worte sagt habe ich mein Lab mal dargestellt.

Die Konfiguration des FreeRadius schaut folgend aus:

Teste ich nun die Auth mit einem Shell Skript bekomme ich folgende Ausgabe:

Über diese Schnittstelle geht es also.

Da ich nun den AP ins spiel bringen möchte habe ich einen weiteren NAS Client hinzugefügt (192.168.2.253)
Teste ich aber die Auth damit bekomme ich folgenden Fehler:
(Für mich irgendwie unlogisch da der Radius auf der .254 hört und der .253 als Client bekannt ist)

Die Konfig vom AP schaut folgend aus: (Aber soweit bin ich gar nicht gekommen, da der Test fehlschlug)

Wo liegt hier der Hase im Pfeffer ?

Vielen Dank schon mal für euren Hirnschmalz.

(PS Außer dem Intellinet ist alles virtuell in der VBox gebaut, daher auch die komischen IP Adressen und die Passwörter )

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 370052

Url: https://administrator.de/forum/pfsense-und-freeradius3-authentifizierungsproblem-370052.html

Ausgedruckt am: 23.12.2024 um 02:12 Uhr

11 Kommentare

Neuester Kommentar

habe ich mein Lab mal dargestellt.

Das ist un heimlich schlecht zu lesen, da du die Bilder FALSCH einsortiert hast !
Du musst nachdem du das Bild mit dem Klick auf das Kamewra Symbol importiert hast unten das **"+"++ klicken um das Bild RICHTIG in den Text einzubinden.
Das hast du vergessen (oder die FAQs nicht gelesen) deshalb tauchen alle Bilder nur kumuliert am Schluß auf und keiner weiß welches Bild zu welchem Abschnitt deiner Beschreibung passt

Das macht dann wenig Spaß.
(Kannst du nachträglich korrigieren !)

Zum Thema findest du hier noch wichtige Tips:
Sichere 802.1x WLAN-Benutzer Authentisierung über Radius
Netzwerk Management Server mit Raspberry Pi
Hilfreich wäre mal wenn du mit dem Tool NT-RadPing mal einen Test auf den Radius machst:
http://www.novell.com/coolsolutions/tools/14377.html
Läuft der durch ?
Es sieht ja so aus als ob die pfSense LAN seitig nicht erreichbar ist für die Radius Requests ?
Hast du ggf. entspr. Firewall regeln am LAN Port die das verhindern ?
Was sagt das FreeRadius Log in der pfSense (Logs) ?? Kannst du dort eingehenden Radius Requests sehen ?
Mal mit Diagnostics -> Packet Capture am LAN Port gessniffert nach eingehenden Radius Requests ? Kommt da was ?

2 Dinge sind unverständlich in der Zeichnung von oben !
Du benutzt eine Router Kaskade mit der pfSense, was soweit ja auch OK ist.
Der AP erreicht den Radius Server auf der pfSense über das lokale LAN 192.168.2.0 /24
Was bitte hat die Bezeichnung "pfSense mit FreeRadius 192.16.1.1" dort für eine Bewandnis ??
Das netzwerk 192.168.1.0 /24 gibt es doch nirgendwo bei dir ??

Hallo aqui,

ich hab die Bilder in der Mittagspause noch einmal neu zugeordnet leider ist die Quali nicht besser geworden.
Das kann ich erst heute Abend erledigen.

Das 192.168.1.0/24 ist eigentlich nur ein Management Netz für die PfSense und ist als LAN bei den Interfaces dort definiert.
In der virtuellen Umgebung ist dieser Adapter auf intern gestellt und ich greife darauf mit einem zweiten virtuellen Linux auf die Web Oberfläche zu.

Die Firewall ist zu Testzwecken komplett offen, das ist daher auszuschließen.

Das Log spricht bei erfolg: radiusd 34089 (65) Login OK: [Markus] (from client intellinet port 0)
Beim zweiten Aufruf über die Schnittstelle WIRELESS bekomme ich keine Meldung.
(Was dafür spricht dass der Radius nicht erreicht wird, aber warum ?)

Danke für die Hinweise, probiere ich heute Abend gleich aus.

leider ist die Quali nicht besser geworden.

Die Quali ist schon perfectly OK. Es ging um die Struktur !

Das 192.168.1.0/24 ist eigentlich nur ein Management Netz für die PfSense

OK, dann leugt das 192.168.2.0 /24 auf einem anderen Interface ?
Beachte das das eine Firewall ist. Auf allen Interfaces die NICHT Default sind also eine Default Regel haben gilt deny any any (alles verboten) wie es bei einer FW ja üblich ist.
Hast du diese regel an dem Port entsprechend angepasst ?

Die Firewall ist zu Testzwecken komplett offen

OK, dann ist es das schonmal nicht.
Das 192.168.1.1er Interface kannst du pingen aus dem .2.0er Netz ?

Beim zweiten Aufruf über die Schnittstelle WIRELESS

Wieso Schnittstelle Wireless ???
Der AP bzw. die Clients dort authentisieren sich nur über den Kupferport mit dem Radius ! Wireless spielt da keine Rolle !
Nur mal doof nachgefragt. Das Schlüsselpasswort im Radius ist identisch zu dem im AP und enthält keine Umlaute ?
In der FreeRadius Konf ist das als "secret" in der client.conf definiert !

client 192.168.2.0/24 {
       secret          = Geheim123
       shortname       = Testnetz
}  

Meist als "Radius Passwort" dann im AP Setup. Auch die Netzwerk Angabe muss stimmen. Absender ist das .2.0er Netz.
WAS sagt der Test mit NTRadPing ??

Ja die 192.168.2.0 /24 liegt auf einem anderen Interface.
(Das interne Netz der Virtualisierung)

Das Wireless ist nur die Bezeichnung für das Interface (192.168.2.254 Kupfer was zum WIFI AP führt)
Die Firewall regeln habe ich auch angpasst. (Also allow any any)

Bis jetzt arbeite ich nur auf der PfSense, der Intellinet AP ist zwar angesteckt und konfiguriert (Ping geht) aber Auth funktioniert noch nicht.
Daher wollte ich einen Schritt früher anfangen und die Auth über das Command Promt Tool der PfSense testen.
Da bekomme ich mit dem Befehl

radtest Markus 12345 192.168.1.1:1812 0 intellinet

eine positive Antwort.
Mit dem Behel

radtest Markus 12345 192.168.2.253:1812 0 intellinet

jedoch ein Fehler wie oben angezeigt.
Nach meiner Meinung spiegelt das ja eine Simulation wieder von welchem Interface der Radius Request kommt.
Und da bei beiden die Passwörter gleich sind verstehe ich nicht warum die 192.168.2.253 Probleme macht.
Nun habe ich folgenden Befehl getestet:

radtest Markus 12345 192.168.2.254:1812 0 intellinet

Also simuliert aus dem gleichen Netz aber mit dem an der PfSense angeschlossenen Adapter anstelle des simulierten WIFI AP mit der 192.168.2.253.
Dieser funktionier ohne Probleme:

Sent Access-Request Id 41 from 0.0.0.0:23182 to 192.168.2.254:1812 length 76
	User-Name = "Markus"  
	User-Password = "12345"  
	NAS-IP-Address = 192.168.1.1
	NAS-Port = 0
	Message-Authenticator = 0x00
	Cleartext-Password = "12345"  
Received Access-Accept Id 41 from 192.168.2.254:1812 to 0.0.0.0:0 length 20

Ich schaue mit jetzt noch mal das Packet Capture an.

Die Firewall regeln habe ich auch angpasst. (Also allow any any)

Sollte man nicht so machen

Besser ist Source auf LAN_network zu setzen also das lokale Netz. Ist aber kosmetisch und hat mit dem eigentlichen Fehler nichts zu tun.

aber Auth funktioniert noch nicht.

Deshalb ja einen Rechner mit NTRadPing ins selbe Netz und die Authentisierung simulieren

jedoch ein Fehler wie oben angezeigt.

Das liegt am Binding des Radius Servers zur NIC.
Vermutlich hat der Radius nur ein Binding auf die NIC ins .1.0er Netz aber nicht ins .2.0er Netz. Das ist ein Konfig Fehler.
Aber auch egal. Du kannst bei den Devices im .2.0er Netz als Radius Ziel ja auch die .1.1 angeben !! Warum machst du das denn nicht ? Dann sollte es doch klappen.

Dieser funktionier ohne Probleme:

Ist das möglich das du hier einen Fatalen Denkfehler machst ??
Als Ziel für den radius MUSS doch immer die IP auf der pfSense angegeben werden also die .1.1 oder die .2.254 wenn die .245 die FW IP im .2.0er Netz ist !!
Da die AP Adresse anzugeben wäre ja Blödsinn ! Sorry. Der AP ist ja nicht der Radius ! Der AP ist der Client der zum Radius will und der Radius liegt auf der FW, hat also folglich eine FW IP als Ziel.

Jetzt kommt Farbe ins Spiel.
Du hast natürlich recht, wenn ich die 1.1 auf dem WIFI AP als Radius Ziel setzt dann bekomme ich im syslog auch Meldungen.
Also die Pakete erreichen den Empfänger.
Folgendes wird ausgegeben:

Nun muss ich nur noch herausfinden was die Fehlermeldung zu bedeuten hat.
Hast du ne Idee ?
Google hat auf die schnelle nichts gebracht.

Hallo Markus,

im Befehl "radtest" gibt man das Ziel des Access-Request an, die Source-IP kann man nicht angeben. Es ist also alles korrekt, wenn ich deine Ausführungen richtig verstanden habe.

NAME
       radtest - send packets to a RADIUS server, show reply

SYNOPSIS
       radtest  [-d raddb_directory] [-P tcp/udp] [-t pap/chap/mschap/eap-md5] [-x
       ] [-4 ] [-6 ] user password radius-server nas-port-number secret  [ppphint]
       [nasname]

Aha again what learned. Danke für die Erklärung des Befehls.

Ich bin der Sache noch etwas näher gekommen und versuche das noch einmal zusammenzufassen.
Folgende Fehlermeldung bekomme ich:

Apr 5 21:47:21 	radiusd 	15144 	(4) Login incorrect (Failed retrieving values required to evaluate condition): [f0:1e:34:11:3e:6d] (from client WIRELESS port 2000 cli f0:1e:34:11:3e:6d) 

Nun wunderte ich mich wo diese MAC Adresse herkommt ?
Die Adresse gehört zu der Netzwerkkarte an meinem Laptop auf dem die Virtualisierung läuft.
An dieser Netzwerkkarte ist der Wireless AP (Intellinet, da es die einzige Hardware Komponente ist) mit der IP 192.168.2.2 und der Einstellung Netzwerkbrücke (Virtual Box) angeschlossen.

Wenn ich das nun richtig interpretiere fragt der WirelessAP über diese Netzwerkkarte mit Ihrer MAC den Radius Server an ?
Passiert da zwischen Hardware und Virtualisierung etwas was ich nicht verstehe ?
War Netzwerkbrücke die falsche Einstellung ?
Eigentlich sollte diese Netzwerkkarte wie ein Switchport sein und nur durchleiten, aber dann komme ich nicht mehr auf das Web Interface des Wireless AP.
Ein Problem gelöst, und drei weitere tun sich auf...nein

Ich hätte mir noch einen virtuellen Rechner bauen sollen und von dort aus testen so wie Aqui das vorgeschlagen hat aber leider habe ich keine weitere V-Maschine zur Hand und auch kein Image um mir eine zu basteln.
(Bin auf nen Symposium und habe leider nur schlechten Internetzugang aber viel Zeit zum basten

)

Kleiner Nachtrag: 1:53 Uhr
Der Radius hört auf der 192.168.1.1 und auf der 192.168.2.254
Das capturing zeigt aber, dass Radius Pakete(Port 1812) zwar von 192.168.2.253(WIFI AP) am 192.168.2.254 ankommen aber nicht an der 192.168.1.1. Obwohl der AP so konfiguriert ist dass der Radius auf der 192.168.1.1 erreichbar ist.
Aber ich muss doch innerhalb der PfSense nicht routen ? Er kennt ja alle Netze.
Capture für 192.168.2.254.

Bei der 192.168.1.1 sind keine Pakete mit Port 1812 aufzuzeichnen.

über diese Netzwerkkarte mit Ihrer MAC den Radius Server an ?

Die Mac Adresse ist für den Request nur in sofern interessant das sie für die Layer 2 Kommunikation benötigt wird:

Je nach Ziel IP .2.254 oder .2.2 ARPt der Client mit einem Broadcast danach um die Mac rauszubekommen
Es sollte immer der die FW mit ihrer Interface Mac antworten. Das kannst du auch selber ganz einfach mit einem arp -a sehen !

Für die IP Kommunikation im Layer 3 und für die Authentisierung ist es irrelevant.
Ausnahme jetzt mal 802.1x Port Authentisierung mit Mac Passthrough wo Client Macs authentisiert werden.
Wenn dann prüft der Radius nur die IP des Clients ob die erlaubt ist einen Request zu senden. Nicht aber die Mac.

und auch kein Image um mir eine zu basteln.

Ein popeliger 30 Euro Raspberry Pi wäre dein Freund jetzt !!!

Der Radius hört auf der 192.168.1.1 und auf der 192.168.2.254

Das wäre auch zu erwarten...

aber nicht an der 192.168.1.1

Dann hast du wohl doch noch irgendwo ein Problem mit den Firewall Regeln.

Obwohl der AP so konfiguriert ist dass der Radius auf der 192.168.1.1 erreichbar ist.

Warum konfigurierst du ihm die .2.254 nicht ?? Da klappt doch der Radius Zugang ?? Das würde doch das Problem sofort lösen. Abgesehen davon müsste man das Paket nicht einmal innerhalb der Firewall im Kreis schicken was ja auch überflüssig ist ?!

Aber ich muss doch innerhalb der PfSense nicht routen ?

Wie kommst du darauf ? Du musst intern routen vom .2.0er Interface zum .1.0er Interface. Einmal "Durchlauferhitzer" der gar nicht sein müsste.

Ich bin gestern Abend erst dazu gekommen.
Nachdem ich die PfSensen noch einmal von Grund auf konfiguriert hatte hat alles gepasst.
Das Radius ziel des AP ist natürlich die 192.168.2.254.
Auth passt und der Client bekommt auch ein IP.

Ich hatte am Anfang bei der Fehlersuche wohl irgend etwas umgestellt was ich im nachhinein nicht nachvollziehen und Rückgängig machen konnte.
Jetzt passt alles..

Vielen Dank nochmal für die Hilfe.