Guten Tag,
auf einem Lancom L321 mit FW: 8.63.0017 / 25.05.2012 (beta) und vorherigen, funktionierte unsere Radius Authentifizierung (PEAP/MSCHAPV2) - nach Update auf die 8.80 nun nicht mehr.
Spiele ich die 8.63 beta wieder ein, funktioniert dies auch direkt wieder. Hat sich da etwas Grundlegendes geändert?
Ich habe wenige Stunden versucht der Firmware den Radius beizubiegen, ohne Erfolg:
Anfangs nochmal das Radius PWD neu gesetzt und im Radius den Eintrag für den AP rausgenommen und neu gesetzt.
Dann unter Schlüssel1/Passphrase den gleichen "Namen" wie unter Wireless-LAN, 802.1X, Raidus-Server. Auch mal ohne Passphrase und den Radius "DEFAULT" genannt. Die Absende-Adresse mal nicht angepasst, mal auf INTRANET, mal auf die richtige fixe IP - über welche man den AP auch per https erreicht und welche auch im Radius hinterlegt ist.
Unsere weiteren APs funktionierten zu dieser Zeit mit der FW 8.63 mit dem Radius, so dass ich dort keine Fehler sehe.
Unter Systeminformationen, Syslog fand ich leider auch keine hilfreichen Debug/Error Meldungen, wo es genau klemmt.
Alles andere, mehrere essids und vlans funktionieren korrekt. Wenn ich für dies Wireless Netzwerk von 802.11i(WPA)-802.1x auf 802.11i(WPA)-PSK umstelle, bekomme ich auch die erwartete IP. Nur mit unserem Raidus mag diese FW-Version nicht mehr.
Ist da etwas bekannt? Muss ich in meinem Setup etwas umstellen? Wie kann ich weitergehende Debug-Infos liefern?
Vielen Dank.
Benjamin Hagemann
keine Radius Authentifizierung nach Update auf LCOS 8.80
Moderator: Lancom-Systems Moderatoren
-
benjamin.hagemann
- Beiträge: 3
- Registriert: 04 Apr 2013, 16:54
Moin,
Als erstes solltest Du kontrollieren, ob der AP die IP des RADIUS-Servers erreichen kann (RADIUS-Server von der CLI des AP aus anpingen). Im IP haben sich ein paar Sachen bezüglich Routing geändert, z.B. der Vorrang von Sperrregeln für lokale Netze gegenüber einer per DHCP erhaltenen Default-Route.
Wenn der Ping nicht klappt, mit einen iP-Router-Trace herausfinden, wo's klemmt. Wenn der Ping klappt, stattdessen den EAP-Trace einschalten und beobachten, was passiert, während sich der Client per 802.1x anzumelden versucht. Wenn man Meldungen sieht, daß der AP einen RADIUS-Request an den Server schickt, aber keine Antwort bekommt, mußt Du auf dem RADIUS-Server weitersuchen, warum der nicht antworten will. Ansonsten postest Du mal den Trace hier.
Gruß Alfred
Nö...Spiele ich die 8.63 beta wieder ein, funktioniert dies auch direkt wieder. Hat sich da etwas Grundlegendes geändert?
Als erstes solltest Du kontrollieren, ob der AP die IP des RADIUS-Servers erreichen kann (RADIUS-Server von der CLI des AP aus anpingen). Im IP haben sich ein paar Sachen bezüglich Routing geändert, z.B. der Vorrang von Sperrregeln für lokale Netze gegenüber einer per DHCP erhaltenen Default-Route.
Wenn der Ping nicht klappt, mit einen iP-Router-Trace herausfinden, wo's klemmt. Wenn der Ping klappt, stattdessen den EAP-Trace einschalten und beobachten, was passiert, während sich der Client per 802.1x anzumelden versucht. Wenn man Meldungen sieht, daß der AP einen RADIUS-Request an den Server schickt, aber keine Antwort bekommt, mußt Du auf dem RADIUS-Server weitersuchen, warum der nicht antworten will. Ansonsten postest Du mal den Trace hier.
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
-
benjamin.hagemann
- Beiträge: 3
- Registriert: 04 Apr 2013, 16:54
Hallo Alfred,
vielen Dank für die kompetente Antwort. Vom AP aus hatte ich gestern den Radius noch nicht gepingt. Vom Radius selbst konnte ich den AP gestern pingen.
Vom AP kann ich den Radius nicht pingen:
"Network unreachable by localhost"
IP-Router-Trace sagt:
-------------
[IP-Router] 1900/01/01 01:42:44,716
IP-Router Rx (intern, RtgTag: 0):
DstIP: X.X.X.149, SrcIP: Y.Y.Y.66, Len: 84, DSCP/TOS: 0x00
Prot.: ICMP (1), echo request, id: 0x0005, seq: 0x0000
no route => discard frame
------------------
Scheint also wirklich genau in diese Sperrregeln Ecke zu gehen.
Die .66 bekommt der AP per (mac-based) DHCP.
Ich habe über die Webgui unter "LCOS-Menübaum", "Status", "IP-Router", "Eff.-IP-Routing-Tab." nachgeschaut => keine Default Route.
Er hat sich nur eine statische Route zu seinem Default GW gesetzt:
-----
IP-Adresse IP-Netzmaske Rtg-Tag Gateway Gegenstelle Distanz Maskierung Typ
Y.Y.Y.64 255.255.255.192 0 Y.Y.Y.66 INTRANET 0 nein
...
------
Mein Rechner liegt aber in einem andern Subnetz und der Radius liegt auch in einem weiteren Subnetz. Klar, dass der AP diese dann selbst nicht erreicht.
Wie kann ich ihm dies wieder freischalten?
Danke
Grüße, Benny
vielen Dank für die kompetente Antwort. Vom AP aus hatte ich gestern den Radius noch nicht gepingt. Vom Radius selbst konnte ich den AP gestern pingen.
Vom AP kann ich den Radius nicht pingen:
"Network unreachable by localhost"
IP-Router-Trace sagt:
-------------
[IP-Router] 1900/01/01 01:42:44,716
IP-Router Rx (intern, RtgTag: 0):
DstIP: X.X.X.149, SrcIP: Y.Y.Y.66, Len: 84, DSCP/TOS: 0x00
Prot.: ICMP (1), echo request, id: 0x0005, seq: 0x0000
no route => discard frame
------------------
Scheint also wirklich genau in diese Sperrregeln Ecke zu gehen.
Die .66 bekommt der AP per (mac-based) DHCP.
Ich habe über die Webgui unter "LCOS-Menübaum", "Status", "IP-Router", "Eff.-IP-Routing-Tab." nachgeschaut => keine Default Route.
Er hat sich nur eine statische Route zu seinem Default GW gesetzt:
-----
IP-Adresse IP-Netzmaske Rtg-Tag Gateway Gegenstelle Distanz Maskierung Typ
Y.Y.Y.64 255.255.255.192 0 Y.Y.Y.66 INTRANET 0 nein
...
------
Mein Rechner liegt aber in einem andern Subnetz und der Radius liegt auch in einem weiteren Subnetz. Klar, dass der AP diese dann selbst nicht erreicht.
Wie kann ich ihm dies wieder freischalten?
Danke
Grüße, Benny
Moin,
Du mußt unter Setup/IP-Router/IP-Routing-Table die entsprechende Regel löschen, die das Routen privater Netze verhindert. Welche das ist, kann ich Dir nicht sagen, weil Du die oberen Bytes der Adressen ja so hübsch ausge-x-t hast
Bei LCOS 8.62 war es noch so, daß eine per DHCP erhaltene Default-Route höhere Priorität hat als die Sperr-Routen in der Routing-Tabelle. Das ist bei LCOS 8.80 anders, die per DHCP erhaltene Default-Route hat gleiche Prio wie eine per Hand gesetzte Route, also niedriger als die Sperrouten.
Gruß Alfred
Ich bin mir nicht sicher, ob ein per DHCP erhaltenes Default-Gateway dort überhaupt gelistet wird...Ich habe über die Webgui unter "LCOS-Menübaum", "Status", "IP-Router", "Eff.-IP-Routing-Tab." nachgeschaut => keine Default Route.
Du mußt unter Setup/IP-Router/IP-Routing-Table die entsprechende Regel löschen, die das Routen privater Netze verhindert. Welche das ist, kann ich Dir nicht sagen, weil Du die oberen Bytes der Adressen ja so hübsch ausge-x-t hast
Bei LCOS 8.62 war es noch so, daß eine per DHCP erhaltene Default-Route höhere Priorität hat als die Sperr-Routen in der Routing-Tabelle. Das ist bei LCOS 8.80 anders, die per DHCP erhaltene Default-Route hat gleiche Prio wie eine per Hand gesetzte Route, also niedriger als die Sperrouten.
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
-
benjamin.hagemann
- Beiträge: 3
- Registriert: 04 Apr 2013, 16:54
Nabend Alfred,
super, vielen Dank. Das war's. Ich habe
IP-Adresse IP-Netzmaske Rtg-Tag Peer-oder-IP Distanz Maskierung Aktiv Kommentar
10.0.0.0 255.0.0.0 0 0.0.0.0 0 nein nein block private network: 10.x.y.z
entsprechend auf aktiv:nein gesetzt und jetzt tut's
Diese Änderung hab ich wohl im Changelog überlesen.
Dann kann ich ja bald beruhigt ins Wochenende gehen.
Grüße, Benny
super, vielen Dank. Das war's. Ich habe
IP-Adresse IP-Netzmaske Rtg-Tag Peer-oder-IP Distanz Maskierung Aktiv Kommentar
10.0.0.0 255.0.0.0 0 0.0.0.0 0 nein nein block private network: 10.x.y.z
entsprechend auf aktiv:nein gesetzt und jetzt tut's
Diese Änderung hab ich wohl im Changelog überlesen.
Dann kann ich ja bald beruhigt ins Wochenende gehen.
Grüße, Benny
Moin,
bin mir nicht sicher, ob dieses Detail es in das Changelog geschafft hat. Mir war das Problem bekannt, weil darauf auch schon der Admin eines bekannten hannoveraner Verlages reingefallen war
Grüße & schönes Wochenende
Alfred
bin mir nicht sicher, ob dieses Detail es in das Changelog geschafft hat. Mir war das Problem bekannt, weil darauf auch schon der Admin eines bekannten hannoveraner Verlages reingefallen war
Grüße & schönes Wochenende
Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015