OpenWRT auf WRT54GL - WPA mit externem Freeradius
Hallo ihr Lieben,
ich betreibe hier einen Linksys WRT54GL als reine WLAN Brücke mit der OpenWRT Firmware 8.09 mit X-Wrt Webinterface. Auf einem Debian Server mit der IP 10.0.1.4 Subnet: 255.255.240.0 habe ich einen Freeradius-Server laufen. Habe jetzt schon von mehreren Clients ausprobiert und ein Authentifizierung am Radius klappt Problemlos. Der WRT ist im WLAN-Netz nicht zu erreichen, da er an einer getrennten Netzwerkkarte betrieben wird. Im LAN-Netz hat der WRT die IP 10.0.2.1 Subnet: 255.255.240.0. Von der Console aus kann ich den Radius-Server pingen und umgekehrt. Aber der WRT macht keinerlei Kommunikation mit dem Teil (keine Aktivität am Radius beim Einloggen ins WLAN-Netz).
Konfiguration wie folgt:
In der clients.conf ist der WRT eingetragen:
Was mache ich falsch? Müssen eventuell noch Module nachinstalliert werden auf dem WRT?
ich betreibe hier einen Linksys WRT54GL als reine WLAN Brücke mit der OpenWRT Firmware 8.09 mit X-Wrt Webinterface. Auf einem Debian Server mit der IP 10.0.1.4 Subnet: 255.255.240.0 habe ich einen Freeradius-Server laufen. Habe jetzt schon von mehreren Clients ausprobiert und ein Authentifizierung am Radius klappt Problemlos. Der WRT ist im WLAN-Netz nicht zu erreichen, da er an einer getrennten Netzwerkkarte betrieben wird. Im LAN-Netz hat der WRT die IP 10.0.2.1 Subnet: 255.255.240.0. Von der Console aus kann ich den Radius-Server pingen und umgekehrt. Aber der WRT macht keinerlei Kommunikation mit dem Teil (keine Aktivität am Radius beim Einloggen ins WLAN-Netz).
Konfiguration wie folgt:
Mode: Access Point
WDS: Off
ESSID Broadcast: On
AP Isolation: Off
Encryption Type: WPA + WPA2 (RADIUS)
RADIUS IP Address: 10.0.1.4
RADIUS Port: 1812 (auch schon mit Port 1813 probiert)
RADIUS Server Key: radiussecret
MAC Filter: Disabled
WDS: Off
ESSID Broadcast: On
AP Isolation: Off
Encryption Type: WPA + WPA2 (RADIUS)
RADIUS IP Address: 10.0.1.4
RADIUS Port: 1812 (auch schon mit Port 1813 probiert)
RADIUS Server Key: radiussecret
MAC Filter: Disabled
In der clients.conf ist der WRT eingetragen:
client Accesspoint {
ipaddr = 10.0.2.1
secret = radiussecret
require_message_authenticator = no
}
ipaddr = 10.0.2.1
secret = radiussecret
require_message_authenticator = no
}
Was mache ich falsch? Müssen eventuell noch Module nachinstalliert werden auf dem WRT?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 116869
Url: https://administrator.de/contentid/116869
Ausgedruckt am: 21.11.2024 um 14:11 Uhr
14 Kommentare
Neuester Kommentar
Port 1813 ist Unsinn, denn das ist der Port fürs Accounting !
Radius hat früher andere Ports benutzt nämlich 1645 und 1646 (letzterer wieder fürs Accounting).
Du solltest also sicherstellen, das der Freeradius auch auf Port 1812 hört und nicht auf 1645 !
Das kannst du auch sicher mit einem Radius Test Tool ntradping ausprobieren:
http://www.novell.com/coolsolutions/tools/14377.html
Ist das sichergestellt, kann der Fehler nur am OpenWRT liegen.
Am besten hängst du mal einen Wireshark Sniffer zw. OpenWRT und dem Radius und snifferst mal mit was da vom OpenWRT kommt.
DD-WRT schickt de facto Radius Requests raus...
Radius hat früher andere Ports benutzt nämlich 1645 und 1646 (letzterer wieder fürs Accounting).
Du solltest also sicherstellen, das der Freeradius auch auf Port 1812 hört und nicht auf 1645 !
Das kannst du auch sicher mit einem Radius Test Tool ntradping ausprobieren:
http://www.novell.com/coolsolutions/tools/14377.html
Ist das sichergestellt, kann der Fehler nur am OpenWRT liegen.
Am besten hängst du mal einen Wireshark Sniffer zw. OpenWRT und dem Radius und snifferst mal mit was da vom OpenWRT kommt.
DD-WRT schickt de facto Radius Requests raus...
Das könnte ein Grund sein !!
VLANs sind ja komplett isoliert untereinander !
Wenn also dein Radius Server in VLAN a ist und dein AP ind VLAN b dann kommen die niemals zueinander....das ist logisch !
Ein Indiz dafür ist das du am Radius im Debugger Modus keine eingehenden Pakete vom AP siehst.
Das solltest du also besser nochmal checken bzw. einen Router dazwischenhängen der zwischen den VLANs routen kann.
Irgendwie ist auch deine IP Adressierung unverständlich...
Du schreibst einerseits ein Adapter ist im Netzwerk
10.0.0.0 /20 das von 10.0.0.1 bis 10.0.15.254 geht
Dann ist aber die 10.0.2.4 /20 auch in diesem Netzwerk und kann niemals auf einem separaten Adapter liegen, denn der müsste ja folglich in einem anderen IP Netz liegen.
Vermutlich sind das aber nur die beiden LAN Adressen im Bridge Netzwerk.... ?! Wenn ein Ping funktioniert ist die Erreichbarkeit ja gegeben !
VLANs sind ja komplett isoliert untereinander !
Wenn also dein Radius Server in VLAN a ist und dein AP ind VLAN b dann kommen die niemals zueinander....das ist logisch !
Ein Indiz dafür ist das du am Radius im Debugger Modus keine eingehenden Pakete vom AP siehst.
Das solltest du also besser nochmal checken bzw. einen Router dazwischenhängen der zwischen den VLANs routen kann.
Irgendwie ist auch deine IP Adressierung unverständlich...
Du schreibst einerseits ein Adapter ist im Netzwerk
10.0.0.0 /20 das von 10.0.0.1 bis 10.0.15.254 geht
Dann ist aber die 10.0.2.4 /20 auch in diesem Netzwerk und kann niemals auf einem separaten Adapter liegen, denn der müsste ja folglich in einem anderen IP Netz liegen.
Vermutlich sind das aber nur die beiden LAN Adressen im Bridge Netzwerk.... ?! Wenn ein Ping funktioniert ist die Erreichbarkeit ja gegeben !
Irgendwie würfelst du da was wild durcheinander... ??
Benutzt du nun ein VLAN nach 802.1q
http://de.wikipedia.org/wiki/Virtual_Local_Area_Network
bzw.
http://de.wikipedia.org/wiki/IEEE_802.1q
oder
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
...oder bezeichnest du einfach fälschlicherweise, vermutlich aus Unwissenheit über die VLAN Materie, einfach die IPCop Interfaces als "VLAN" ???
Letzteres hätte mit VLANs nichts zu tun und ist lediglich eine falsche, laienhafte Benutzung des Begriffs "VLAN".
Gehen wir also mal davon aus das du damit nur die IPCop Interfaces meinst....
Dann hast du aber ein generelles Problem, denn IP Seitig müsste der WRT AP immer erreichbar sein.
Vermutlich ist die Authentifizierung im Bridge Modus auch schlicht und einfach nur deaktiviert, denn WLAN Bridges müssen sich normalerweise nicht authentifizieren, da sie bei einer LAN to LAN Kopplung für die Endgeräte vollkommen transparent sind !
Vermutlich ist das der einfache Grund.
Um das herauszubekommen schliess einfach einen Paket Sniffer an wie bereits gesagt...dann kannst du sehen ob die WRT Box überhaupt Radius Pakete rausschickt !!!
Das sind 5 Minuten in denen du dann ganz sicher bist als 3 tage hier im Forum zu mutmaßen...
Benutzt du nun ein VLAN nach 802.1q
http://de.wikipedia.org/wiki/Virtual_Local_Area_Network
bzw.
http://de.wikipedia.org/wiki/IEEE_802.1q
oder
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
...oder bezeichnest du einfach fälschlicherweise, vermutlich aus Unwissenheit über die VLAN Materie, einfach die IPCop Interfaces als "VLAN" ???
Letzteres hätte mit VLANs nichts zu tun und ist lediglich eine falsche, laienhafte Benutzung des Begriffs "VLAN".
Gehen wir also mal davon aus das du damit nur die IPCop Interfaces meinst....
Dann hast du aber ein generelles Problem, denn IP Seitig müsste der WRT AP immer erreichbar sein.
Vermutlich ist die Authentifizierung im Bridge Modus auch schlicht und einfach nur deaktiviert, denn WLAN Bridges müssen sich normalerweise nicht authentifizieren, da sie bei einer LAN to LAN Kopplung für die Endgeräte vollkommen transparent sind !
Vermutlich ist das der einfache Grund.
Um das herauszubekommen schliess einfach einen Paket Sniffer an wie bereits gesagt...dann kannst du sehen ob die WRT Box überhaupt Radius Pakete rausschickt !!!
Das sind 5 Minuten in denen du dann ganz sicher bist als 3 tage hier im Forum zu mutmaßen...
Das kann nicht funktionieren, denn der WRT kann keine VLANs routen, da er kein IP Interface pro VLAN hat. Die VLAN Implementation klappt nur auf Layer 2.
Außerdem sind das dann 802.1q tagged VLAN Pakete die aus dem WRT kommen und die versteht dein Switch nicht und droppt sie.
http://de.wikipedia.org/wiki/IEEE_802.1q
Das ist auch ein Indiz warum keine Radius Pakete am Server ankommen.
Die einzige Möglichkeit die du hast ist den IPCop für Radius (TCP 1812) zu öffnen so das die Pakete vom WRT über den IPCop an den Radius Server gehen.
So wird ein Schuh draus !
Außerdem sind das dann 802.1q tagged VLAN Pakete die aus dem WRT kommen und die versteht dein Switch nicht und droppt sie.
http://de.wikipedia.org/wiki/IEEE_802.1q
Das ist auch ein Indiz warum keine Radius Pakete am Server ankommen.
Die einzige Möglichkeit die du hast ist den IPCop für Radius (TCP 1812) zu öffnen so das die Pakete vom WRT über den IPCop an den Radius Server gehen.
So wird ein Schuh draus !
Dann hast du aber generell einen fehler im Setup !!
Wenn WLAN AP und Radius im gleichen Netzwerk sind muss eine Verbindung ja in jedem Falle möglich sein sofern du mit iptables nicht irgendwelche Firewall restriktionen auf dem radius Server eingebaut haben solltest ???
Als Alternative solltest du ggf. mal ein Aug auf Monowall werfen, denn die kann problemlos auch mit VLANs umgehen:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Damit wäre dann eine VLAN Anbindung mit tagged Frames an den AP problemlos möglich !
Wenn WLAN AP und Radius im gleichen Netzwerk sind muss eine Verbindung ja in jedem Falle möglich sein sofern du mit iptables nicht irgendwelche Firewall restriktionen auf dem radius Server eingebaut haben solltest ???
Als Alternative solltest du ggf. mal ein Aug auf Monowall werfen, denn die kann problemlos auch mit VLANs umgehen:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Damit wäre dann eine VLAN Anbindung mit tagged Frames an den AP problemlos möglich !