14
Lancom VAW 1781 Anfragen weiterleiten
Hallo,
kann mir einer sagen, wie ich das hinbekomme, das der oben benannte Router aus einem "hotspot" Netzwerk Anfragen an eine bestimmte IP in ein anderem Netzwerk weiterleitet?
Quasi möchte ich eine NAS, die in einem geschützten Netzwerk liegt auch temporär aus einem "hotspot"-Netzwerk erreichen können.
Ein VLAN ist nicht erstellt worden, die beiden Netzwerke wurden lediglich durch unterschiedliche "Tags" und IP Adress-Bereiche getrennt.
Danke euch
kann mir einer sagen, wie ich das hinbekomme, das der oben benannte Router aus einem "hotspot" Netzwerk Anfragen an eine bestimmte IP in ein anderem Netzwerk weiterleitet?
Quasi möchte ich eine NAS, die in einem geschützten Netzwerk liegt auch temporär aus einem "hotspot"-Netzwerk erreichen können.
Ein VLAN ist nicht erstellt worden, die beiden Netzwerke wurden lediglich durch unterschiedliche "Tags" und IP Adress-Bereiche getrennt.
Danke euch
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 292013
Url: https://administrator.de/contentid/292013
Ausgedruckt am: 23.11.2024 um 06:11 Uhr
14 Kommentare
Neuester Kommentar
Über einen Routing-Tag Eintrag in die Routing-Tabelle oder eine Firewallausnahme...
https://www2.lancom.de/kb.nsf/bf0ed2a4d2a4419ac125721b00471d85/4dcb3157f ...
Durch diese Aussage sollte es jetzt eigentlich klick bei dir machen 
Jetzt kannst du ja die lokalen Netze welche nicht aus dem Hotspot-Netz erreicht werden sollen ein explizites Routing-Tag zuweisen, und dann zusätzlich für das eine zu erreichende NAS einen Eintrag in die Routing-Table z.B. ala 192.168.1.10/32 mit Routing Tag des Hotspot-Netzes anlegen.
Gruß und guten Rutsch
grexit
https://www2.lancom.de/kb.nsf/bf0ed2a4d2a4419ac125721b00471d85/4dcb3157f ...
Clients aus den Netzen können alle Routen nutzen, die das Routing-Tag 0 haben. Ist das Routing-Tag ungleich 0 und ungleich dem eigenen Schnittstellentag, kann die Route aus diesem Netz nicht genutzt werden.
Jetzt kannst du ja die lokalen Netze welche nicht aus dem Hotspot-Netz erreicht werden sollen ein explizites Routing-Tag zuweisen, und dann zusätzlich für das eine zu erreichende NAS einen Eintrag in die Routing-Table z.B. ala 192.168.1.10/32 mit Routing Tag des Hotspot-Netzes anlegen.
Gruß und guten Rutsch
grexit
Kann mir einer das mal erklären? Irgendwie hab ich den kram mit den Routen nicht gerallt, was die Eingabe in den Feldern betrifft.
Siehe BILD
Also, IP Adresse ist das Ziel laut Hilfe (meine NAS)
Netzmaske fein 255.255.255.255 weil ich nur die EINE Station will
Routing Tag des Hotspots netzes
Dann der Eintrag: Router ->> ??? , rall ich nicht. Die Hilfe meint dazu "Wenn diese Route zu einer anderen Station im lokalen Netz führen soll, geben Sie einfach die IP-Adresse dieser Station ein."
Laut der Hilfe gibt's also zweimal ein Ziel aber kein Quelle?!?!?
Sorry für das dumme Fragen, aber Lancom hat die Übersicht & Einfachheit der Oberfläche irgendwie wirklich vergessen.
Eine Route hat für mich ein Anfang & Ende. Irgendwie kann ich das überhaupt nicht aus den Eingabefeldern erkennen und der ganze Kram "IP Maskierung" rall ich schon gar net mehr.
Siehe BILD
Also, IP Adresse ist das Ziel laut Hilfe (meine NAS)
Netzmaske fein 255.255.255.255 weil ich nur die EINE Station will
Routing Tag des Hotspots netzes
Dann der Eintrag: Router ->> ??? , rall ich nicht. Die Hilfe meint dazu "Wenn diese Route zu einer anderen Station im lokalen Netz führen soll, geben Sie einfach die IP-Adresse dieser Station ein."
Laut der Hilfe gibt's also zweimal ein Ziel aber kein Quelle?!?!?
Sorry für das dumme Fragen, aber Lancom hat die Übersicht & Einfachheit der Oberfläche irgendwie wirklich vergessen.
Eine Route hat für mich ein Anfang & Ende. Irgendwie kann ich das überhaupt nicht aus den Eingabefeldern erkennen und der ganze Kram "IP Maskierung" rall ich schon gar net mehr.
Hängen sowohl das Hotspot-Netz als auch das Netzwerk, in dem das zu erreichende System liegen, am gleichen Router? Wenn ja, bringt dir die Route nichts, der Weg ist schon bekannt. In diesem Fall müsstest du rein mit der Firewall arbeiten.
Wenn das Hotspot-Netz an deinem LANCOM hängt und das zu erreichende Gerät irgendwo abseits des LANCOMs, dann müsstest du die Routing Tabelle und die Firewall zusammen nutzen (Fachbegriff Policy Based Routing, wird auch in der Referenzanleitung von LANCOM beschrieben).
Routen haben im Regelfall kein Anfang und kein Ende. Routen haben nur ein Ende. Wenn ein Anfang mit angegeben wird, ist es wieder Policy Based Routing.
Aber dein Eingangspost liest sich so, dass man als normaler Mensch nur orakeln kann.
LANconfig und WEBconfig ist noch Spielkram, lustig wirds erst, wenn man fließend CLI schreibt auf den Geräten.
Wenn das Hotspot-Netz an deinem LANCOM hängt und das zu erreichende Gerät irgendwo abseits des LANCOMs, dann müsstest du die Routing Tabelle und die Firewall zusammen nutzen (Fachbegriff Policy Based Routing, wird auch in der Referenzanleitung von LANCOM beschrieben).
Routen haben im Regelfall kein Anfang und kein Ende. Routen haben nur ein Ende. Wenn ein Anfang mit angegeben wird, ist es wieder Policy Based Routing.
Aber dein Eingangspost liest sich so, dass man als normaler Mensch nur orakeln kann.
aber Lancom hat die Übersicht & Einfachheit der Oberfläche irgendwie wirklich vergessen
Ist halt keine Fritzbox, die jeder Idiot bedienen kann und können soll. LANCOM ist für professionelle Netzwerke gedacht und wird im Regelfall von entsprechenden Fachkräften eingerichtet. Nur Basisaufgaben, die ständig anfallen, wie das Einrichten einer einfachen Internetverbindung, werden als Assistent angeboten.LANconfig und WEBconfig ist noch Spielkram, lustig wirds erst, wenn man fließend CLI schreibt auf den Geräten.
Zitat von @tikayevent:
Hängen sowohl das Hotspot-Netz als auch das Netzwerk, in dem das zu erreichende System liegen, am gleichen Router? Wenn ja, bringt dir die Route nichts, der Weg ist schon bekannt. In diesem Fall müsstest du rein mit der Firewall arbeiten.
Das stimmt beim LanCom nicht unbedingt denn wenn man den jeweiligen Routen zu den Netzen ein anderes Routing-Tag als 0 zuordnet sieht nur das jeweilige Netz mit dem entsprechenden Schnittstellentag diese Route, s.o..Hängen sowohl das Hotspot-Netz als auch das Netzwerk, in dem das zu erreichende System liegen, am gleichen Router? Wenn ja, bringt dir die Route nichts, der Weg ist schon bekannt. In diesem Fall müsstest du rein mit der Firewall arbeiten.
Wie gesagt reicht aber auch eine simple Firewall-Rule um das zu realisieren, dazu sollte der TO aber mal die vollständige Config posten wie was tatsächlich konfiguriert wurde. Aber so wie sich der TO anhört sollte er das lieber jemandem versierten anvertrauen.
An den TO, bitte Bilder nur hier im Forum hochladen und keine externen Bilder verlinken.
Das stimmt beim LanCom nicht unbedingt denn wenn man den jeweiligen Routen zu den Netzen ein anderes Routing-Tag als 0 zuordnet sieht nur das jeweilige Netz mit dem entsprechenden Schnittstellentag diese Route, s.o..
Soweit richtig, aber die Route wirkt nicht lokal. Mit dem Routingtag kann man die Zugehörigkeit zu einem ARF-Kontext einstellen oder es dazu nutzen, um es mit der Firewall zu referenzieren.Aber solange das Zielnetz lokal am Router anliegt, kommt man von ARF-Kontext zu ARF-Kontext nicht mit einer Route weiter, hier bleibt nur die Möglichkeit, mit Hilfe der Firewall das Tag zu ändern.
Wenn die Route auf ein Ziel verweist, welches über einen weiteren Router oder eine spezielle Gegenstelle zu erreichen ist, kann man über das Routingtag das Routing steuern.
Also Jungs, das mit der Firewall Regel hat geklappt.
Einzig alleine stellt sich mir die Frage, wie folgendes Szenario auftreten kann:
Ich Arbeite in der Firewall mit der Deny-All strategie. Ich hab die "Routing" Regel erstellt und nachdem ich diese die Pakete mit dem korrekten Tag markieren lassen hab, konnte ich aus dem Hotspot auf die andere Seite des Netzwerkes zugreifen. (In Windows ein SMB LW eingebunden)
Zum testen, ob ich alles richtig gemacht habe, habe ich diese Regel deaktiviert.Komischerweise ging der Zugriff immer noch, erst nach einiger Zeit meldete sich Windows mit "Zugriff auf LW nicht mehr möglich".
Schockierender Weise war genau das gleiche bei dem Weg ins Internet. Testweise alle "Allow" Regeln für den Weg vom Spot ins Internet deaktiviert. Es war zwar für das meiste unverzüglich dicht (google suche ging net mehr), aber irgendwie schaffte Youtube, die Kommentare zu den Videos und die Vorschaubilder zu laden. Die Videos selber gingen nicht, aber wie zum Teufel konnten denn die Kommentare geladen werden und links auf der Website die Liste anderer Videos??!
Kann es sein, das die Firewall "Session" bedingt arbeitet? Also, trifft die Regel einmal zu, ist sie solange gültig, bis die Session abläuft?
Und was bezeichnet eigentlich "Session"? Also, welchen Zeitraum? (Die Frage kommt daher, daher ich in dem Trigger/Aktions Feld "Pro Session", "pro Station" und "Global" auswählen kann...)
Das würde mir jedenfalls erklären, warum es solche "leckagen" noch für einen kleinen Zeitraum gibt. Weil irgendwann ging das mit Youtube auch nicht mehr... Reproduzierbar war der Zeitraum allerdings nicht.
Und zum Abschluss: Gibt's irgendwo Schulungsunterlagen von Lancom?
Irgendwie könnte ich hier fragen ohne Ende stellen und das wollte ich euch ersparen :D
Einzig alleine stellt sich mir die Frage, wie folgendes Szenario auftreten kann:
Ich Arbeite in der Firewall mit der Deny-All strategie. Ich hab die "Routing" Regel erstellt und nachdem ich diese die Pakete mit dem korrekten Tag markieren lassen hab, konnte ich aus dem Hotspot auf die andere Seite des Netzwerkes zugreifen. (In Windows ein SMB LW eingebunden)
Zum testen, ob ich alles richtig gemacht habe, habe ich diese Regel deaktiviert.Komischerweise ging der Zugriff immer noch, erst nach einiger Zeit meldete sich Windows mit "Zugriff auf LW nicht mehr möglich".
Schockierender Weise war genau das gleiche bei dem Weg ins Internet. Testweise alle "Allow" Regeln für den Weg vom Spot ins Internet deaktiviert. Es war zwar für das meiste unverzüglich dicht (google suche ging net mehr), aber irgendwie schaffte Youtube, die Kommentare zu den Videos und die Vorschaubilder zu laden. Die Videos selber gingen nicht, aber wie zum Teufel konnten denn die Kommentare geladen werden und links auf der Website die Liste anderer Videos??!
Kann es sein, das die Firewall "Session" bedingt arbeitet? Also, trifft die Regel einmal zu, ist sie solange gültig, bis die Session abläuft?
Und was bezeichnet eigentlich "Session"? Also, welchen Zeitraum? (Die Frage kommt daher, daher ich in dem Trigger/Aktions Feld "Pro Session", "pro Station" und "Global" auswählen kann...)
Das würde mir jedenfalls erklären, warum es solche "leckagen" noch für einen kleinen Zeitraum gibt. Weil irgendwann ging das mit Youtube auch nicht mehr... Reproduzierbar war der Zeitraum allerdings nicht.
Und zum Abschluss: Gibt's irgendwo Schulungsunterlagen von Lancom?
Irgendwie könnte ich hier fragen ohne Ende stellen und das wollte ich euch ersparen :D
Stichwort Statefull Firewall und Connection-Tracking, normales Verhalten solange die Verbindung noch in der Connection-Tracking Table steht und aufgebaut ist.
https://www.lancom-systems.de/docs/LCOS-Refmanual/9.10-Rel/DE/topics/aa1 ...
https://www2.lancom.de/kb.nsf/1275/BB6FD1480986547FC1257433004F0C6B?Open ...
Die Verbindungen lassen sich auch einzeln aus der Connection-Tracking-Table löschen:
https://www.lancom-systems.de/docs/LCOS-Refmanual/9.10-Rel/DE/#topics/aa ...
Gruß grexit
https://www.lancom-systems.de/docs/LCOS-Refmanual/9.10-Rel/DE/topics/aa1 ...
https://www2.lancom.de/kb.nsf/1275/BB6FD1480986547FC1257433004F0C6B?Open ...
Die Verbindungen lassen sich auch einzeln aus der Connection-Tracking-Table löschen:
https://www.lancom-systems.de/docs/LCOS-Refmanual/9.10-Rel/DE/#topics/aa ...
Gruß grexit
Solange eine TCP-Verbindung steht, wird diese nicht erneut geprüft. Eventuelle Firewalländerungen greifen erst für einen Neuaufbau dieser TCP-Verbindung. Ist ein gängiges Verhalten. Alternativ müssten bei jeder Firewalländerung alle TCP-Verbindungen getrennt werden. Kommt durch das Design von TCP. Kein LANCOM-spezifisches Problem.
Bei LANCOM müsste man dazu einfach die Internetverbindung trennen und wieder aufbauen.
Schulungsunterlagen von LANCOM gibt es, aber nicht öffentlich verfügbar sondern nur für Schulungsteilnehmer. Ich bezweifel, dass diese Unterlagen von irgendwem zur Verfügung gestellt werden. Am einfachsten ist es, einfach mal in der LANCOM-KB rumzusurfen und die aktuelle Referenzanleitung zu lesen.
Bei LANCOM müsste man dazu einfach die Internetverbindung trennen und wieder aufbauen.
Schulungsunterlagen von LANCOM gibt es, aber nicht öffentlich verfügbar sondern nur für Schulungsteilnehmer. Ich bezweifel, dass diese Unterlagen von irgendwem zur Verfügung gestellt werden. Am einfachsten ist es, einfach mal in der LANCOM-KB rumzusurfen und die aktuelle Referenzanleitung zu lesen.
OK, danke euch.
Da ich wohl das Glück habe und mit einigen Sprechen kann, die Lancom kennen, noch eine andere Sache.
Ich habe ein Problem mit der IP-Vergabe im Wlan.
Folgendes Szenario: Man authentifiziert sich, bekommt IP und alles rattert 1a durch.
Nun disconnetced man sich. Geht man nun sofort wieder rein, kann es sein, das man beim 3ten mal zwar authentifiziert wird, aber keine IP bekommt. Jedenfalls ist dies bei mehreren Clienten schon passiert. Android z.B. meldet dauerhaft "ip Adresse wird abgerufen" und Apples Macbooks sagen ähnliches.
Ab da hat man halt für eine gewisse Zeit im Wlan verschissen...
In den Syslogs finde ich lediglich nur die Meldungen zu den authentifications, aber nichts vom gescheiterten Zuweisungen etc.
Ist da irgendwo nen "attack" Schutz gegen missbrauch des DHCP Servers? Das WIDS gibt's ja für meine Serie nicht und das Problem ist schon älter...
Hat einer eine Idee?
Weil unter Setup-> DHCP sind derart keine einstellungen zu finden...
Da ich wohl das Glück habe und mit einigen Sprechen kann, die Lancom kennen, noch eine andere Sache.
Ich habe ein Problem mit der IP-Vergabe im Wlan.
Folgendes Szenario: Man authentifiziert sich, bekommt IP und alles rattert 1a durch.
Nun disconnetced man sich. Geht man nun sofort wieder rein, kann es sein, das man beim 3ten mal zwar authentifiziert wird, aber keine IP bekommt. Jedenfalls ist dies bei mehreren Clienten schon passiert. Android z.B. meldet dauerhaft "ip Adresse wird abgerufen" und Apples Macbooks sagen ähnliches.
Ab da hat man halt für eine gewisse Zeit im Wlan verschissen...
In den Syslogs finde ich lediglich nur die Meldungen zu den authentifications, aber nichts vom gescheiterten Zuweisungen etc.
Ist da irgendwo nen "attack" Schutz gegen missbrauch des DHCP Servers? Das WIDS gibt's ja für meine Serie nicht und das Problem ist schon älter...
Hat einer eine Idee?
Weil unter Setup-> DHCP sind derart keine einstellungen zu finden...
Firmware aktuell ?
Ich hatte so ein ähnliches Verhalten mal als Spanning Tree auf dem LanCom aktiviert war.
Du kannst ja auch mal Wireshark neben her laufen lassen um zu sehen was auf der Leitung abgeht und ob die DHCP-Kommunikation korrekt abläuft.
Gruß grexit
Ich hatte so ein ähnliches Verhalten mal als Spanning Tree auf dem LanCom aktiviert war.
Du kannst ja auch mal Wireshark neben her laufen lassen um zu sehen was auf der Leitung abgeht und ob die DHCP-Kommunikation korrekt abläuft.
Gruß grexit
Ja, die Aktuellste Firmware ist drauf und Spanning Tree ist deaktiviert...
Normal ist der DHCP sehr einfach gehalten. Du bekommst eigentlich immer die gleiche IP-Adresse. Bei IPv4 ist es sogar so, dass du mit sehr sehr hoher Wahrscheinlichkeit an jedem anderen LANCOM-Router den gleichen Hostanteil der IP bekommst.
Bist du sicher, dass du am WLAN authentifiziert wirst? Richtig authentifiziert ist ein Client erst, wenn im Syslog der verwendete Benutzername (nur bei WPA-Enterprise) und die erkannten IP-Adressen stehen. Manchmal findet man im Syslog, dass ein Client authentifiziert wurde und kurz danach findet man die Deauthentifizierung.
EDIT: Es gibt eine Stelle, an der man DHCP einschränken kann. Schau mal in den Einstellungen der LAN-Schnittstelle. Wenn du das Gerät nicht zu sehr verdreht hast, müsste es bei dir die BRG-1 sein. Da kann man ein Limit setzen.
Bist du sicher, dass du am WLAN authentifiziert wirst? Richtig authentifiziert ist ein Client erst, wenn im Syslog der verwendete Benutzername (nur bei WPA-Enterprise) und die erkannten IP-Adressen stehen. Manchmal findet man im Syslog, dass ein Client authentifiziert wurde und kurz danach findet man die Deauthentifizierung.
EDIT: Es gibt eine Stelle, an der man DHCP einschränken kann. Schau mal in den Einstellungen der LAN-Schnittstelle. Wenn du das Gerät nicht zu sehr verdreht hast, müsste es bei dir die BRG-1 sein. Da kann man ein Limit setzen.
Ja, ich bin authentifiziert. Lass mich das auch ebend erklären, damit wir nicht aneinander vorbei reden.
Der Prozess sieht ja (so denke ich) wie folgt aus: Gerät handelt mit dem Acesspoint den Key aus. Stimmt dieser, wird der Client eingebucht. Erst dann im Anschluss bekommt der DHCP mit, das er was tun muss.
Mit ein paar Tricks kriegt man jeden Androiden dazu, diesen Prozess anzuzeigen bzw. zu loggen.
Obendrauf ist das Netz noch offen; jedenfalls ist es mir bisher nur dort aufgefallen.
Bemerkbar macht sich der Prozess schon bei dem 2 relogin. Dabei dauert der Prozess der IP vergabe schon merklich länger. (< 10s) . Beim erneuten reloggen gibt's halt den supergau.
Reproduzierbar ist's nicht, es tritt halt zufällig auf. Ich hatte das gestern nur wieder einmal.
Noch zu bemerken war, das ich in diesem Zustand den Käse nur zum Laufen bekomme, wenn der Client per Statische Adresse "Suche" eingeloggt wird. Sollte die grad nicht besetzt sein, so bekam ich wieder eine IP und alles war tutti.
Ich hab's dann noch mal wieder per DHCP probiert, aber der stellte sich wieder auf stur.
Ist das vielleicht eher ein Bug? Vielleicht sollte ich damit mal Lancom kontaktieren???
Wäre es möglich, das der DHCP zwar seine Arbeit getan hat (also IP vergeben), aber diese aufgrund WLAN Störungen durch Nachbarn etc. nicht an dem Clienten weitergereicht wird? (Also das Prinzip, wenn ein Download "hängt", da der Server nicht mehr antwortet aufgrund von Timeout des Download-Client..)?
BTW: Der DHCP ist jedenfalls dort (Schnittstellen -> LAN) nicht eingeschränkt.
Der Prozess sieht ja (so denke ich) wie folgt aus: Gerät handelt mit dem Acesspoint den Key aus. Stimmt dieser, wird der Client eingebucht. Erst dann im Anschluss bekommt der DHCP mit, das er was tun muss.
Mit ein paar Tricks kriegt man jeden Androiden dazu, diesen Prozess anzuzeigen bzw. zu loggen.
Obendrauf ist das Netz noch offen; jedenfalls ist es mir bisher nur dort aufgefallen.
Bemerkbar macht sich der Prozess schon bei dem 2 relogin. Dabei dauert der Prozess der IP vergabe schon merklich länger. (< 10s) . Beim erneuten reloggen gibt's halt den supergau.
Reproduzierbar ist's nicht, es tritt halt zufällig auf. Ich hatte das gestern nur wieder einmal.
Noch zu bemerken war, das ich in diesem Zustand den Käse nur zum Laufen bekomme, wenn der Client per Statische Adresse "Suche" eingeloggt wird. Sollte die grad nicht besetzt sein, so bekam ich wieder eine IP und alles war tutti.
Ich hab's dann noch mal wieder per DHCP probiert, aber der stellte sich wieder auf stur.
Ist das vielleicht eher ein Bug? Vielleicht sollte ich damit mal Lancom kontaktieren???
Wäre es möglich, das der DHCP zwar seine Arbeit getan hat (also IP vergeben), aber diese aufgrund WLAN Störungen durch Nachbarn etc. nicht an dem Clienten weitergereicht wird? (Also das Prinzip, wenn ein Download "hängt", da der Server nicht mehr antwortet aufgrund von Timeout des Download-Client..)?
BTW: Der DHCP ist jedenfalls dort (Schnittstellen -> LAN) nicht eingeschränkt.
Ich kenn das Phänomen, verteilt sich bei mir auf 230 APs deutschlandweit.
Ich hab das Problem im Regelfall aber nur mit einer bestimmten Geräteart (MDE-Geräte von Casio) und nach einem Reset dieser Geräte geht es wieder. Dieses Verhalten zeigen die aber an jedem Typ Access Point.
Wenn das Problem nicht reproduzierbar ist, ist es schlecht. Sonst hättest du einfach mal an zwei Stellen Wireshark laufen lassen können. Einmal am Client auf der WLAN-Schnittstelle und einmal direkt auf dem AP an der WLAN-Schnittstelle. Dadurch könntest du vergleichen, ob z.B. das DHCP Offer am Client angekommen ist.
Hier bei mir zuhause ist mir dieses Problem noch nicht aufgefallen. Aber bei dir ist es auch so, dass du ein WLAN-Modul im Router hast, während ich auf drei APs und einen Router ohne WLAN setze.
Du hast auch geschrieben, du hättest die aktuellste Firmware drauf. Wie ist der genaue Firmwarestand bei dir? Zur Zeit ist es die 9.10.irgendwas RU5. Die wird noch nicht durch LANconfig angeboten sondern gibt es nur über MyLANCOM oder über den FTP-Server. Ob in der 9.10.xyzRU5 gerade irgendwas in der Richtung Probleme macht, kann ich nicht sagen, ich habe ganz andere Firmwarestände auf den Geräten.
Ich hab das Problem im Regelfall aber nur mit einer bestimmten Geräteart (MDE-Geräte von Casio) und nach einem Reset dieser Geräte geht es wieder. Dieses Verhalten zeigen die aber an jedem Typ Access Point.
Wenn das Problem nicht reproduzierbar ist, ist es schlecht. Sonst hättest du einfach mal an zwei Stellen Wireshark laufen lassen können. Einmal am Client auf der WLAN-Schnittstelle und einmal direkt auf dem AP an der WLAN-Schnittstelle. Dadurch könntest du vergleichen, ob z.B. das DHCP Offer am Client angekommen ist.
Hier bei mir zuhause ist mir dieses Problem noch nicht aufgefallen. Aber bei dir ist es auch so, dass du ein WLAN-Modul im Router hast, während ich auf drei APs und einen Router ohne WLAN setze.
Du hast auch geschrieben, du hättest die aktuellste Firmware drauf. Wie ist der genaue Firmwarestand bei dir? Zur Zeit ist es die 9.10.irgendwas RU5. Die wird noch nicht durch LANconfig angeboten sondern gibt es nur über MyLANCOM oder über den FTP-Server. Ob in der 9.10.xyzRU5 gerade irgendwas in der Richtung Probleme macht, kann ich nicht sagen, ich habe ganz andere Firmwarestände auf den Geräten.
