PublicSpot mit lokaler RADIUS-Authentifizierung - kein User angelegt

[kkr24]

Hallo zusammen,
zwei Lancom 1781VA mit identischer Firmware 10.20.0355RU3 und freigeschalteter PublicSpot-Option.
Der PS ist so eingerichtet, dass in Public-Spot->Anmeldung->Authentifizierung für den Netzwerkzugriff der Anmelde-Modus auf "keine Anmeldung nötig (Login nach Einverständniserklärung) wirken soll.
Die Einverständniserklärung wird von einem Webserver im internen Firmen-Netz geladen. Hierzu ist noch zu sagen, dass beide Lancoms a) den PS-Traffic lokal auskoppeln und ins Internet schicken und b) Traffic über das "normale" Netz der Lancoms geht über einen VPN-Tunnel zur Firmenzentrale.
Um den PS nutzen zu können ist ein Lancom-AP (am anderen Standort sind es mehrere) via Switch am 1781 angebunden.

Diese Konstellation funktioniert komplett für einen der beiden Lancom-Router.

Beim anderen Router ist festzustellen, dass bei aktiviertem Zugang nach Einverständniserklärung im Hintergrund kein Radius-User angelegt wird. Festgestellt a) über Blick in die lokale Radius-Tabelle und b) per trace + radius erkannt, dass Radius-Anfragen nur abweisend beantwortet werden - ohne einen User anzulegen.

Ich habe von beiden Routern LCS-Dateien erzeugt und per Editor (++) Compare miteinander verglichen - 20 Abweichungen.
Es gibt natürlich in den IP-Ranges Abweichungen, im Bereich der PS-Kommandos sind exakt zwei Unterschiede zu finden:
User-Template/Comment enthält den jeweilen Hostnamen und Abs.-Expiry ist bewusst unterschiedlich (ein Testgerät, eines soll produktiv genutzt werden). Abweichend sind die Hostnamen, SNMP-Angaben zum Standort, VPN-Daten bei den IKE-Keys - alles erwartet.

Tja. Und dennoch verhalten sich die Geräte unterschiedlich...

Also wenn da jemand eine Idee hat...

[stefanbunzel]

Guten Morgen kkr24,

ganz spontan würde ich sagen, dass auf dem Router, bei dem Radius (PublicSpot) nicht funktioniert, nicht die PublicSpot-Option aktiviert ist. Wenn ich mich nicht irre ist es doch inzwischen so, dass man auch bei Geräten ohne PS-Option (leider) auch die PS-Menüpunkte in LANconfig und WebConfig sieht und ändern kann, ohne dass sie dann aber funktionieren (oder?).

Also prüfe bitte einmal in LANconfig unter Geräteeigenschaften, ob das Problem-Gerät wirklich über die freigeschaltete Option verfügt.

Viele Grüße,
Stefan

[kkr24]

Hallo Stefan,
die Option wird i.d. Geräteeigenschaften angezeigt.
Ich habe gerade mal geprüft, ob der interne Webserver im internen Netzwerk zur internen IP des Problem-Lancom-Routers access.log-Einträge hat - hat er und die Einträge haben denselben Statuscode (200) wie die Einträge, die ich am Testgerät produziere und sehen auch sonst absolut korrekt aus.

VG
Klaus

[stefanbunzel]

Hallo Klaus,

... dass Radius-Anfragen nur abweisend beantwortet werden - ohne einen User anzulegen.

Dann musst du hier mal weiter prüfen, warum hier "abweisend" geantwortet wird. Passwort + Client-IP korrekt?

Viele Grüße,
Stefan

[kkr24]

Hallo Stefan,
Passwort wird bei den lokalen Radius-Servern (127.0.0.1) gar keines verwendet und diese IP (127.0.0.1) ist auch im Public-Spot eingetragen.
Ich habe die Radius-Traces ja auf beiden Lancom-Routern aktiv: beide stellen zunächst die eingehende Anfrage fest, beide stellen fest, dass kein User existiert (gesucht wird offenbar nach der MAC), der funktionsfähige Router loggt dann einen free-User (=User angelegt), der andere Router loggt weitere Anfragen des Clients.
Wenn‘s dumm läuft muss ich doch mal hinfahren und mache einen Reset (ist halt nicht um die Ecke

Gruß,
Klaus

[kkr24]

Ich mag ja keine Threads die dann irgendwann enden - daher die Auflösung des Problems:
heute war ich also vor Ort... Und wie ich da so auf einen Kollegen warte, zücke ich ein MotoG5+ (Android 8.1), suche das fragliche WLAN (der PSK ist identisch dem am Teststandort meines Büros), gelange ins WLAN und es erwartet mich die bekannte Android-Meldung "Im Netzwerk anmelden" (also: alles genauso, wie ich es im Lab erlebt habe und anhand der Config auch erwartet hätte). Es wird definitiv ein Radius-User angelegt.

Ich zücke ein zweites Gerät: Huawei P10 lite (Android 8.0), damit hatte ich schon im Büro keinen Zugang via Captive Portal - und das ist hier genauso.
Das dritte Testobjekt: ein Windows 7-Notebook - kein Zugang.

Mit dem Win7-NB im WLAN des PS versuche ich die Adresse für logout zu ermitteln und erhalte vom DNS (<hostname>.intern) zurück, dass er nichts findet. Und da beginnt es zu dämmern...: logout vs. DNS für Domäne .intern: ich habe also in den Betriebseinstellungen des Public Spot "logout" durch "logout.intern" ersetzt und in den IPv4-Einstellungen eine zus. Stationsauflösung "logout.intern" mit der via Assistenz vergebenen IP 192.168.1.1 angelegt.

Ergebnis: P10lite und NB erhalten die Nutzungsbedingungen dargestellt (wie auch das G5 zuvor schon) - Problem gelöst.

Das G5 scheint sehr entspannt unterwegs zu sein...

Letzter Test: das Smartphone, mit dem der Kollege in den Tagen zuvor getestet hat: ein HTC mit Android 8.x (ich habe leider keine genaueren Daten).
Wiewohl das Gerät mit einer Authentifizierungsmethode "per E-Mail registrieren" die Android "Im Netzwerk anmelden"-Meldung gezeigt haben soll, zeigt das Gerät diese Meldung nun nachhaltig nicht mehr in der Betriebsart "Nur AGBs abnicken" (sorry, ich habe die Maske gerade nicht zur Hand - ich meine die zweite Einstellung zur Anmeldung am PS von oben).
Auch scheint noch etwas in Richtung http/s nicht zufriedenstellend zu sein (s.u.).
Es ist aber, im Gegensatz zur Einstellung zuvor ("logout"), nun mit Einstellung "logout.intern" via Browser an die Nutzungsbedingungen zu gelangen um diese zu akzeptieren und über ein weiteres Browserfenster ist dann der Internetzugriff möglich. Nicht 100% akzeptabel, aber ok.

Was ist die Erkenntnis: die per Assistenz eingerichtete DNS/Stationskennung ist ein Schwachpunkt und der Umstand, dass kein Radius-User angelegt worden ist war nur der Folgefehler (wo zu nichts zugestimmt wird kann auch kein User angelegt werden).

In Sachen https entsprang noch ein Gedankengang:
- der 1781 verfügt über ein selbstsigniertes Zertifikat
- der PublicSpot-Modus läuft daher auf http
- d.h., auch bei Umstellung auf HTTPS-Verkehr zum Aufruf der Nutzungsbedinungen würde es ja wieder zu einer Fehlermeldung im Client kommen, es sei denn, ich installiere ein Zertifikat, welches von einer offiziellen CA kommt - mag in kleiner Stückzahl möglich sein (kostet...), aber: im größeren Stil (wir wollen mehrere Instanzen via Public Spot ausrüsten) ist das nicht zu handeln. Bliebe noch Let's-Encrypt - dafür fehlt leider die Schnittstelle im VPN-Router.

Also ein Problem erkannt und gelöst, ein weitere gefunden und umschifft.

Vielleicht hilft's wem weiter...

Klaus