Lancom WLC und COA

[Der_Gute]

Hallo Zusammen,

ich stehe gerade vor der Situation, dass ich den LANCOM WLC am Packetfence NAC einbinden möchte.
Authentication und Authorization funktionieren soweit auch.
Aktuell stehe ich aber an dem Punkt, dass das NAC dem WLC ja auch mitteilen muss, wenn Clients ihre Zeit verwirkt haben. Hierfür kommt bekanntermaßen COA zum Einsatz.
COA ist auf dem WLC eingerichtet und das NAC ist als Client im WLC hinterlegt. Sieht auch sauber aus. Im Dyn-Auth-Client trace sieht man auch dass die Pakete eingehen.
Im NAC kann ich nun sehr granular konfigurieren, welche Attribute mitgeschickt werden sollen. Im COA ist es ja so, dass umso mehr Attribute, umso spezifischer die Suche.
Was ich aber nicht finde, ist die Antwort auf die Frage, welche Attribute der WLC genau braucht, damit der COA Request sauber aufgeschlüsselt werden kann zu einer Session an einem AP.

Hat da jemand antworten darauf? Lancom mit deren Doku leider nicht

Viele Grüße
Der_Gute

[rotwang]

Mir ist aufgrund Deiner Beschreibung nicht ganz klar, an welches Modul im LANCOM die CoA-Requests gerichtet sein sollen. An das Public-Spot-Modul, das auf dem WLC läuft, oder sollen die WLAN-Assoziationen auf den APs selber getrennt werden? Falls letzeres, dann müßte der WLC die CoA-Requests ja an den einzelnen AP weiterreichen, und ein Forwarding von RADIUS-Paketen in dieser Richtung zwischen APs und WLC existiert m.W. nicht.

[Der_Gute]

Hey,

danke für deine Rückmeldung:
Der Weg generell für 802.1X soll folgender sein:

Client -> AP-> Radius an WLC (so beschriebt es lancom)-> WLC hat einen Forwarder an den Radius Server und der WLC kriegt die responses.
Im Falle des COA ist es ja nur für den WLC Möglich Dyn Authorization und somit COA einzustellen.
Dort habe ich dann den Radius bzw das NAC als Client mit entsprechendem Password hinzugefügt. Vom NAC aus müssen Sessions getrennt werden können. Dies passiert via COA. Das NAC schickt in dem Fall das COA Paket mit den entsprechenden Attributen an den WLC. Der WLC kriegt das auch soweit mit im Trace, kann aber keine Session zuordnen. Dies liegt vermutlich daran, weil das NAC dem WLC nicht genug Futter in form von Attributen gibt.
Der Weg ist daher: NAC-> COA-> WLC-ordnet COA einer Session zu> AP(?)

Public Spot ist da erstmal komplett raus aus der Nummer.
Mir wäre daher geholfen, wenn man mir sagen könnte, welche Attribute konkret in welchem Format der WLC erwartet, damit der das COA einer bestehenden Session eines AP zuordnen kann.

Wenn du es nicht weißt, könntest du mir zb helfen, indem du einen DYN AUTH Client trace auf dem WLC erstellst, ein funktionierendes COA Paket abfeuerst über dein NAC o.ä. und du mir sagst, welche Attribute beim WLC ankommen .

Viele Grüße und vielen Dank vorab!
Der_Gute

[rotwang]

Client -> AP-> Radius an WLC (so beschriebt es lancom)-> WLC hat einen Forwarder an den Radius Server und der WLC kriegt die responses.

Korrekt. Das ist die Richtung, wo die RADIUS-Requests vom AP ausgehen, und der WLC als RADIUS-Proxy/Forwarder/Konzentrator agiert, so dass der 1X-RADIUS-Server nur den WLC als Client "sieht".

Der WLC kriegt das auch soweit mit im Trace, kann aber keine Session zuordnen. Dies liegt vermutlich daran, weil das NAC dem WLC nicht genug Futter in form von Attributen gibt.

Siehst Du denn überhaupt irgendwelche CoA-Sessions auf dem WLC? Wenn man auf einem Standalone-AP auf einer SSID Dyn-Auth einschaltet, dann kann man dort mit einem 'show wlan dynauth' sehen, welche Sessions als Ziel von möglichen CoA-Requests registriert sind. Ich wüsste jetzt nicht, dass es etwas äquivalentes auf dem WLC für von den APs gemeldete, registrierte Clients gibt, oder dass es für CoA-Requests ein Forwarding von RADIUS-Requests in die 'andere Richtung' gibt.

[Der_Gute]

Siehst Du denn überhaupt irgendwelche CoA-Sessions auf dem WLC? Wenn man auf einem Standalone-AP auf einer SSID Dyn-Auth einschaltet, dann kann man dort mit einem 'show wlan dynauth' sehen, welche Sessions als Ziel von möglichen CoA-Requests registriert sind. Ich wüsste jetzt nicht, dass es etwas äquivalentes auf dem WLC für von den APs gemeldete, registrierte Clients gibt, oder dass es für CoA-Requests ein Forwarding von RADIUS-Requests in die 'andere Richtung' gibt.

Danke schonmal für die Hinweise .

Spannender Punkt:
auf dem WLC habe ich das NAC ja als Client konfiguriert und in der SSID habe ich den Punkt, das COA zu aktivieren meine ich nicht gesehen. Hab extra nachmal nachgesehen. Dort kann ich lediglich das Radius Profil zuweisen.
Da der WLC der einzige Ort war, an dem ich Dynauth konfigurieren konnte mit dem NAC als client samt Password, habe ich also angenommen, dass der WLC den Hut dafür aufhat und dann eben mit dem AP bzgl. der Sessions spricht. Wenn ich für den AP einen DYNAUTH Client samt passwort registrieren könnte, wäre das aber auch wiederrum nicht so ganz schlüssig, weil das NAC ja das COA Paket an die NAS IP schickt, die in dem Falle ja dann der WLC wäre (works as intended, da er ja die Requests forwarded vom AP).

Es gibt tatsächlich sogar ein DYNAUTH Forwarding, dass man beim WLC konfigurieren kann, jedoch macht das in meinen Augen wenig Sinn, weil man dort jeden AP hinterlegen müsste und der WLC nicht wüsste, auf welcher Basis die eingehenden COA wohin sollen.
Hast du für mich noch weitere CLI Commands (vllt auch für den WLC), die mir beim Debugging helfen könnten? Wenn du von Standalone AP sprichst, meinst du damit einen AP, der sich am WLC registriert? Würde ja dann bedeuten, dass ich mit 'show wlan dynauth' zumindest hinweise sehen müsste.

VIele Grüße
Der_Gute

[rotwang]

Ich habe noch einmal nachgefragt und es ist so, wie ich es im Kopf hatte: das WLAN-Management auf dem WLC unterstützt kein CoA für die in der WLC-Stationstabelle zu sehenden Clients.

Man kann Dyn-Auth auf dem WLC einschalten, aber das ist erst einmal nur ein Listener, der CoA-Requests annimmt, und dann an andere Module im LCOS weiter verteilen kann, die per CoA steuerbare Sessions an ihn gemeldet haben. Und an solchen Modulen gibt es auf einem WLC nur das Public Spot Modul, für eben dieses wurde auch CoA-Support überhaupt ins LCOS eingeführt. Irgendwann kam dann auch noch das WLAN dazu, aber damit ist der WLAN-Stack auf den (LCOS-)APs gemeint, der die WLAN-Sessions an die CoA-Listener-Instanz auf dem AP selber melden kann. Dann müßte Dein NAC direkt mit den APs reden und nicht mit dem WLC.

Im WLC gibt es auch keinen Mechanismus, aufgelaufene CoA-Requests an die CoA-Instanz der gemanagten APs weiterzuleiten. Die Forwarder-Tabelle - das hast Du ja schon festgestellt - erlaubt nur statische Einträge, und erlaubt auch kein Forwarding anhand einer NAS-Id, die man hier brauchen würde, das passt nicht zu der dynamischen Art, wie gemanagte APs sich üblicherweise als RADIUS-Clients am WLC registrieren.

Das dürfte wohl auch der Grund sein, weshalb der WLC in den Netzwerkprofilen den Punkt 'Dyn-Auth' nicht anbietet, der in den lokalen Konfig-Menüs auf den APs in den Netzwerkeinstellungen ja vorhanden ist. Man könnte das CoA damit einschalten, aber es läge für den Nutzer quasi 'unerreichbar' auf den APs.

Wenn du von Standalone AP sprichst, meinst du damit einen AP, der sich am WLC registriert?

Nein, damit meine ich einen ungemanagten AP, d.h. einen der nicht mit einem WLC verbunden ist und seine Konfig alleine aus seinen lokalen Menüs bezieht.

[Der_Gute]

Guten Morgen,

das hilft schonmal weiter, wenn auch nur technisch bedingt .
Angenommen wir akzeptieren, dass der WLC keine Sessions auf den APs identifizieren kann und deswegen COA an den WLC nutzlos ist und wir schauen nun direkt auf die APs, hätten wir folgenden Stand:
Der AP schickt die Radius requests direkt an das NAC und kriegt auchs eine Replies direkt. Das habe ich schon getestet und das funktioniert.
Wo müsste ich denn dann konfigurieren, dass das NAC als Client für den AP fungieren kann? Ich habe dafür keine Option gefunden, die das ermöglicht. Ich müsste dann ja eine IP (die des NAC) und ein Password hinterlegen können.
Prinzipiell wäre ich damit eigentlich auch glücklich, wobei es da natürlich zu Schwierigkeiten kommen würde, wenn der Client sich via Roaming bewegt.

Des Weiteren eine Frage zur Einschätzung:
Kann der WLC denn Sessions auf dem AP via Radius Disconnect schließen? Das käme meiner Anforderung auch schon recht nah, auch wenn es einen Abzug in der B-Note gibt.

Vielen Dank jedenfalls schonmal dafür, dass du dir die Zeit nimmst
Der_Gute

[rotwang]

Der AP schickt die Radius requests direkt an das NAC und kriegt auchs eine Replies direkt. Das habe ich schon getestet und das funktioniert.
Wo müsste ich denn dann konfigurieren, dass das NAC als Client für den AP fungieren kann? Ich habe dafür keine Option gefunden, die das ermöglicht. Ich müsste dann ja eine IP (die des NAC) und ein Password hinterlegen können.

Du müßtest erstens auf den APs das DynAuth-Modul anschalten, so wie Du das auf dem WLC gemacht hast. Auf der CLI unter Setup/RADIUS/Dyn-Auth. Zweitens müßtest Du unter /Setup/Interfaces/WLAN/Network für die Netze die Option 'Dyn-Auth' anschalten. Das ist eine Tabelle, deren Inhalt der WLC mit seinen Profilen teilweise übersteuert, aber nicht vom WLC bereit gestellte Punkte sollten sich lokal konfigurieren lassen. Wenn Clients sich auf SSIDs mit aktivem Dyn-Auth eingebucht haben, solltest Du die zugehörigen CoA-Sessions auf dem AP mit einem 'show wlan dynauth' sehen können.

Das alles gilt nur für APs, die wie der WLC mit LCOS laufen (L-..., LN-...). Zu LX-APs und ob die irgendwelche CoA-Fähigkeiten haben, kann ich nichts sagen, das ist eine komplett andere Codebasis.

Kann der WLC denn Sessions auf dem AP via Radius Disconnect schließen? Das käme meiner Anforderung auch schon recht nah, auch wenn es einen Abzug in der B-Note gibt.

Nein, wie gesagt, RADIUS-Requests gehen zwischen APs und WLCs nur in einer Richtung. Was Du schauen könntest, ob Du auf dem WLC einen Client trennen kannst, indem Du ein 'delete' auf den entsprechenden Eintrag in der Tabelle 'Status/WLAN-Management/Station-Table' machtst. Zumindest LCOS-APs unterstützen das auf ihrer (lokalen) WLAN-Stationstabelle.

Unabhängig davon: Wenn es nur um ein Zeitlimit geht, dann schickt man im RADIUS-Accept doch einfach ein Attribut 'Session-Timeout' mit dem Zeitlimit mit und als 'Termination-Action' ein 'Default'. Dann kümmert der AP sich selber darum, dass die Verbindung nach der Zeit getrennt wird.

[Der_Gute]

Danke für die Erläuterung Ich vermute aber dass hier die Stumpfen APs im Einsatz sind, die eine Abhängigkeit zum WLC haben, da das CLI der APs auch recht beschränkt ist.
Der Sessiontimeout ist natürlich Valide und es stimmt was du sagst. Über Accounting teilt der AP ja auch dem NAC mit wenn der Client nicht mehr verbunden ist
Worum es mir konkret geht, wo es beim WLAN relevant werden könnte:
Captive Portal und Guest ist so ein Thema. COA wird da gerne verwendet, um nach einer Registrierung die Rolle des Clients neu zu evaluieren.
Zunächst kriegt der Client eine Rolle, bei der ein DNS Forwarding erzwungen wird auf das Captive portal mit sehr restriktiven Berechtigungen im Netzwerk.
Über die Registrierung wird dem Client dann im NAC die richtige Rolle zugewiesen. Wie soll der AP denn sonst mitbekommen, dass da gerade ein Rollenwechsel bzw. VLAN Change stattfindet?

Ich weiß was du jetzt sagen wirst:
Nutz doch einfach das Captive Portal vom Lancom .
Ich bin ehrlich: Technisch sicherlich machbar! Aber eigentlich gehört das Thema für mich in Richtung NAC, da es theoretisch auch LAN Guest User mit Captive Portal geben kann.

Viele Grüße
Dennis