MultiSSID, IAPP & VLAN

kah · Beitrag von **kah** » 03 Jun 2008, 00:56

Hallo zusammen,

habe hier eine (vermutlich) etwas komplexe Konfiguration. In einem Hotel haben wir mehrere APs, welche per VLAN an einem 1811er hängen, auf dem die PublicSpot Option läuft. Dieser hängt per WAN an einem 1722 mit DSL und ist per Private Port Mode vom Rest des Intranets getrennt.

Zwei der APs sind L54ag Dual Geräte, welche darüber hinaus noch eine Brücke über die Strasse zu einem zweiten Wohngebäude aufbauen. auf beiden Seiten der Brücke existiert das Gast-Netz. Über die Brücke geht auch interner Netzverkehr (VLAN:192; IP:192.168.0.x/24) eines anderen Vlans.

Da ich ein wenig Probleme mit PublicSpot und VLAN hatte, läuft der 1811er ohne VLAN und wird praktisch von einem VLAN fähigen Switch in das getaggte VLAN-Netz der übrigen APs per LAN verbunden. Die APs haben keine eigene IP-Adresse im VLAN-Netz der Hotel-Gäste (Public-Spot; 1811: 172.16.0.1/16+DHCP), sondern nur im der regulären Intranet des Hotels => Konfig ist problemlos möglich, Gast-WLAN-seitig für TCP/IP nicht existent.

Das hört sich alles etwas verrückt an, läuft aber im Prinzip ganz gut.

Jetzt das Problem: Mit einer weiteren SSID (kasse) sollen mobile Gastro-Clients angebunden werden, welche von den Kellnern zum Aufnehmen der Bestellungen am Tisch bedient werden. Diese laufen unter dem Intranet-VLAN. Alles funktionierte soweit ganz gut. Alles getestet; im ganzen WLAN-Bereich Kunden und Gastro-Zugriff möglich.

Nach einer Stunde (nicht genau drauf geachtet) und keiner Änderung fingen die WLAN-Clients an, sich "sehr" ungünstig mit den APs zu verbinden. Obwohl andere APs besser erreichbar waren, verbunden sich die Clients mit z.T. sehr signalschwachen APs. Die Folge waren insbesondere häufige Abbrüche.

Wenn man auf dem Haupt-AP (1811) mit trace + iapp das roaming dokumentiert, kommt da fortlaufend die Meldung:

[IAPP] 2008/06/03 00:17:52,700
IAPP Rx Packet:
-> Src (W)LAN interface unknown, discarding

Was mache ich falsch? Wenn ich die neue SSID wieder deaktiviere, ist der Spuk wieder vorbei (zumindest die Verbindungsprobleme)?

alf29 · Beitrag von **alf29** » 03 Jun 2008, 09:29

Moin,

diese Meldung bedeutet, daß dem IAPP ein Paket ohne Angabe des
Quell-Interfaces vorgeworfen worden ist - wie das auch immer passieren
kann...

IAPP ist für das Roaming selber überhaupt nicht erforderlich, das machen
die Clients völlig eigenverantwortlich. IAPP dient nur dazu, daß die APs
sich gegenseitig 'kennenlernen', damit bei einem Roaming-Vorgang der
neue AP dem alten AP mitteilen kann, daß der Client 'weg' ist - sonst
versucht der alte AP noch eine Weile, Pakete für einen nicht mehr
existenten Client weiterzuleiten.

Warum die sonstigen Probleme aufteten, weiß ich so nicht. Welchen
AP ein Client nimmt, ist erstmal komplett die eigene Entscheidung des
Clients, darauf hat ein AP keinen Einfluß. Wenn nur extrem viele
IAPP-Meldungen komme, deutet das darauf hin, daß irgendwo jemand
'Reflektor' für die IAPP-Multicasts spielt und sie vervielfacht, so daß Du
eine Art Multicast-Sturm bekommst. LANCOMs hatten auch mal so
ein Problem, kontrolliere mal, ob auf allen LANCOMs in der Routing-
Tabelle die Sperroute für Multicasts drin ist (224.0.0.0/224.0.0.0 auf
0.0.0.0).

Gruß Alfred

kah · Beitrag von **kah** » 03 Jun 2008, 18:01

Danke für die Antwort.

Die Multicast-Sperrrouten sind bei allen APs vorhanden. Das war es leider nicht.

Wenn IAPP nur für das schnelle Erkennen eines "gewechselten" Clients ist, wie kann ich dies Testweise deaktivieren?

Ist das unter (Lanconfig) WLAN->Security-> "Mobile Stationen können zwischen den Basisstationen im lokalen Netz wechseln" zu deaktivieren.

Außerdem habe ich "Stationen überwachen, um inaktive Stationen zu erkennen an". Damit müsste doch dem alten AP auch sehr schnell klar werden, dass der Client verschwunden ist.

Oder ist das unter WLAN-Experten-Einstellung "Soft-Roaming" zu aktivieren bzw. deaktivieren?

Interessanterweise wird auf den übrigen APs im Log der Firwall mit Uhrzeit (ca. als ich die Tests gemacht habe; MultiSSID aktiviert) eine IDS gemeldet:

intruder detection - UDP Paket von 172.16.0.3:2313 => 224.0.1.76:2313 Paket verworfen.

Es scheint also doch irgendwie mit VLAN zu tun zu haben.

alf29 · Beitrag von **alf29** » 03 Jun 2008, 21:12

Moin,

Wenn IAPP nur für das schnelle Erkennen eines "gewechselten" Clients ist, wie kann ich dies Testweise deaktivieren?

Ist das unter (Lanconfig) WLAN->Security-> "Mobile Stationen können zwischen den Basisstationen im lokalen Netz wechseln" zu deaktivieren.

Korrekt.

Außerdem habe ich "Stationen überwachen, um inaktive Stationen zu erkennen an". Damit müsste doch dem alten AP auch sehr schnell klar werden, dass der Client verschwunden ist.

Ja und nein. Prinzipiell merkt der AP mit dieser Einstellung nach einer Minute, daß der Client weg
ist. Wenn der Client jedoch zu einem neuen AP auf dem gleichen Funkkanal gewechselt ist und
noch in 'Funkreichweite' des alten APs ist, dann klappt diese Erkennung nicht unbedingt, weil die
Testpakete beim Client noch ankommen (auch wenn dieser sie verwirft).

Oder ist das unter WLAN-Experten-Einstellung "Soft-Roaming" zu aktivieren bzw. deaktivieren?

Diese Einstellung hat nur eine Bedeutung, wenn das LANCOM selber als WLAN-Client konfiguriert
ist.

Interessanterweise wird auf den übrigen APs im Log der Firwall mit Uhrzeit (ca. als ich die Tests gemacht habe; MultiSSID aktiviert) eine IDS gemeldet:

intruder detection - UDP Paket von 172.16.0.3:2313 => 224.0.1.76:2313 Paket verworfen.

Es scheint also doch irgendwie mit VLAN zu tun zu haben.

Port und Ziel-IP passen zu IAPP. Nach welchen Regeln solche Meldungen in der Firewall
erzeugt werden, weiß ich nicht, es ist aber so, daß das IAPP seine Multicasts repliziert in
allen konfigurierten ARF-Netzen verschickt. Das ist natürlich eigentlich nicht sinnvoll, aber
ich hatte damals von Cheffe nicht die Zeit bekommen, um ein ARF-Netz konfigurierbar zu
machen...

Gruß Alfred

kah · Beitrag von **kah** » 04 Jun 2008, 07:39

OK, danke.

Vielleicht kan ich den 1811er&PublicSpot vernüftig ins VLAN integrieren. Dann sollten die IAPP Pakete problemlose zueinander passen und die IDS Meldungen entfallen.

Zu PublicSpot:
Was ist mit "VLAN-Tabelle"? Als ich das bei Inbetriebnahme probiert habe, funktionierte das meines Erachtens nicht richtig. Daher, geht das?

Wofür steht "Kommunikations-Port"?

Was bedeutet "Server-Datenbank-liefern"?

Danke für Deine Antworten.

alf29 · Beitrag von **alf29** » 04 Jun 2008, 08:42

Moin,

Zu PublicSpot:
Was ist mit "VLAN-Tabelle"? Als ich das bei Inbetriebnahme probiert habe, funktionierte das meines Erachtens nicht richtig. Daher, geht das?

Diese in der 7.52 neue Tabelle dient dazu, auf einem bestimmten LAN/WLAN-Port, auf dem
Public Spot prinzipiell aktiv ist, dessen Gateway-Funktion auf bestimmte VLANs einzuschränken.
Wenn diese Tabelle nicht leer ist, werden nur die Pakete durch den Public Spot geleitet, deren
VLAN-Id in dieser Tebelle aufgeführt ist. Nützlich ist das Feature in erster Linie, wenn die
Public-Spot-Authentifizierung irgendwo zentral und nicht direkt auf den einzelnen APs passiert
wie z.B. beim Einsatz eines Kontrollers. Auf diese Weise kann man Public Spot und das
Management über das gleiche Interface am WLC laufen lassen. Du hast leider nicht
geschrieben, was Du mit dieser Tabelle machen wolltest, darum kann ich Dir nicht näher sagen,
wo u.U. Dein Problem liegt.

Wofür steht "Kommunikations-Port"?

Das ist ein UDP-Port, auf dem das Gerät externe Befehle zur Freischaltung bzw. Sperrung
einzelner MAC-Adressen entgegennimmt. Benötigt wurde diese Funktion bei einigen Projekten,
bei denen von der Public-Spot-Funktion des APs nur der Redirect auf die Login-Seiten genutzt
wurde und die eigentliche Authentifizierung über ein externes Gateway läuft.

Was bedeutet "Server-Datenbank-liefern"?

Das bedeutet, daß das Gerät die lokale Benutzertabelle im Public-Spot-Modul über den
eingebauten RADIUS-Server zur Verfügung stellt. Ist z.B. nützlich, wenn man mehrere
Geräte mit Public Spot hat, die Benutzerdatenbank aber irgendwo zentral pflegen will, ohne
einen externen RADIUS-Server aufstellen zu müssen.

Gruß Alfred

kah · Beitrag von **kah** » 04 Jun 2008, 17:33

Danke für die Infos. Habe es jetzt komplett mit VLAN umgesetzt. Die Gast VLAN-Id ist im Public Spot eingetragen. Jetzt läuft alles. Den APs habe ich doch interne IP-Adressen spendiert, jetzt laufen auch die IAPP-Pakte ohne IDS durch.

Ein Punkt noch, der mir zu den LanTools (7.52.007) aufgefallen ist: Wenn man einen eingeschränkten PSPOT-Assistent-User (dem man vorher per Web-Interface den Zugriff auf den Public-Spot-Assistenten gewährt hat) und zwischendurch per Lantools die Config verändert, werden die Rechtezuweisungen auf 0 zurückgesetzt => kein PSpot Assistent mehr möglich.

Dies geht erst wieder, nachdem man per Webinterface die Rechte neu gesetzt hat. Aber ich glaube das nicht ganz problemfreie Zusammenspiel zwischen 7.52 LCOS und den Tools ist an vielen Stellen schon bekannt.

Danke!!!

Enno26 · Beitrag von **Enno26** » 08 Jul 2008, 19:03

Hallo,

da dieses Thema ähnlich ist und ich so keinen neuen Tread aufmachen muss frag ich einfach mal hier:

ich hab nen 1722 an den per Lan ein L54 g angeschlossen ist, nun habe ich mir für den L54g die Public Spot Option besorgt.

Meine Frage ist nun:
Wie muss ich genau vorgehen um zu erreichen das die derzeitigen Nutzer weiter normal per wlan ohne anmelde Seite online gehen können, die Public Spot Nutzer nur das Internet nutzen können und ansonsten keinen Zugriff auf das lokale Netzwerk haben? Leider gibt es hierfür keine Anleitung :/
Gruss
Enno