RED 15w wird nicht erkannt als Access Point

Hallo zusammen,

wir haben unsere REDs nicht in einem separaten Netzwerk sondern unter der Schnittstelle "Internal" hinzugefügt.
Meine neue RED15w erhält zwar eine IP aus unserem lokalen Netz und auch der Traffic zwischen UTM & RED funktioniert wunderbar aber ein ausstehender AP wird mir nicht angezeigt :-(

Kann es sein, dass in dieser Konstellation dies nicht funktioniert?

Hallo,

haben Sie einen DHCP-Server für die Netzwerke hinter dem RED eingerichtet? Dies ist erforderlich damit die interne Brücke des REDs eine IP aus dem getunnelten Netzwerk beziehen kann. Sonst kann sich der wireless daemon, der auf dem RED läuft nicht mit dem Wireless controller auf der UTM verbinden und der AP wird nicht angezeigt...

Korrigieren sie mich bitte, wenn ich mich fachlich falsch ausdrücke...

Als DHCP-Server fungiert unser Windows-Domaincontroller. Auf diesem kann ich auch sehen, dass die RED15w eine IP aus unserem internen Netz bekommen hat. Wie gesagt, ich habe für die REDs kein eigenes Netz auf der UTM angelegt sondern die REDs der Schnittstelle "Internal" hinzugefügt da ich möchte, dass übergreifend unser Netz 192.168.45.XXX genutzt wird....

In welchem Modus wird das RED betrieben? (Wenn es im Transparent/Split betrieben wird, muss der DHCP-Server option 234 mit der UTM-IP übermitteln). Wäre es ihnen möglich, eine kleine Topologiegrafik ihres Setups zu zeichnen? Das erleichtert das Verständnis ungemein und beugt Missverständnissen vor.

Wird im Modus Standard/Vereint betrieben - daher habe ich die Option 234 auf dem DHCP nicht gesetzt. In meiner Schnittstelle "Internal" habe ich noch den Ethertype 88B7 gesetzt - der hatte gefehlt... Trotzdem wird mir kein ausstehender AP angezeigt. An der RED selbst schließe ich einen defekt aus, da ich diese zum Test an einer anderen UTM hatte, wo die RED dann in einem eigenen Netz bzw. in einer eigenen Schnittstelle war.

Anbei mal meine Topologie....

Danke für die Grafik. Jetzt wird mir einiges klarer. Dieses Setup stellt in der Tat ein Cornercase dar, den ich bei der Entwicklung des RED15w nicht vor Augen hatte. Da der Code des RED15w jedoch sehr generisch ausgelegt ist, sollte auch dieses Szenario unterstützbar sein:

Da hier die DHCP-Lease von einem anderen DHCP-Server als der, der auf der UTM läuft, ausgeliefert wird, ist das setzen der DHCP-Option 234 auch in diesem Szenario notwendig. Mittels der Option 234 wird den Access Points und auch der RED15w Wirelesskomponente mitgeteilt, an welcher IP-Adresse sich der UTM-Wirelesscontroler befindet. In dieser Grafik wäre das 192.168.45.254. Wenn Sie diese Option mit diesem Wert durch den DHCP-Server den Sie außerhalb der UTM betreiben mit ausliefern, sollte sich der Access Point im RED am Controler melden. Stellen Sie auch sicher, dass dieses Netzwerk in den erlaubten Netzwerken in der Wireless Sektion gelistet ist.

Dabei ist Voraussetzung, dass sich das RED-Tunnelendpunktinterface (redSXX) auf der UTM zusammen mit dem eth-Interface in ihrem lokalen UTM-Netz in einer Brücke befinden. (Layer 2). Die Grafik sieht so aus als wäre das bereits der Fall...

Danke für die Grafik. Jetzt wird mir einiges klarer. Dieses Setup stellt in der Tat ein Cornercase dar, den ich bei der Entwicklung des RED15w nicht vor Augen hatte. Da der Code des RED15w jedoch sehr generisch ausgelegt ist, sollte auch dieses Szenario unterstützbar sein:

Da hier die DHCP-Lease von einem anderen DHCP-Server als der, der auf der UTM läuft, ausgeliefert wird, ist das setzen der DHCP-Option 234 auch in diesem Szenario notwendig. Mittels der Option 234 wird den Access Points und auch der RED15w Wirelesskomponente mitgeteilt, an welcher IP-Adresse sich der UTM-Wirelesscontroler befindet. In dieser Grafik wäre das 192.168.45.254. Wenn Sie diese Option mit diesem Wert durch den DHCP-Server den Sie außerhalb der UTM betreiben mit ausliefern, sollte sich der Access Point im RED am Controler melden. Stellen Sie auch sicher, dass dieses Netzwerk in den erlaubten Netzwerken in der Wireless Sektion gelistet ist.

Dabei ist Voraussetzung, dass sich das RED-Tunnelendpunktinterface (redSXX) auf der UTM zusammen mit dem eth-Interface in ihrem lokalen UTM-Netz in einer Brücke befinden. (Layer 2). Die Grafik sieht so aus als wäre das bereits der Fall...

Vielen vielen Dank erstmal für die Rückmeldung!

Bevor ich mich ans testen mache... Ganz alltäglich ist mein Szenario in dem Fall nicht, oder? Wäre es von Haus aus schon sinnvoller, die REDs in ein eigenes Netz zu packen und den "normalen" weg zu gehen?

Ihr Szenario entspricht nicht ganz dem wofür die Modis gedacht waren. Da jedoch unser/mein Anspruch ist, Software so generisch wie möglich zu halten, um möglichst viele Anwenderszenarien auch abseits der konkreten Spezifikation des Handbuches zu unterstützen, würde ich jetzt nicht sagen, dass man das auf keinen Fall tun sollte. Es ist nur so, dass diese Szenarien nicht explizit getestet wurden. Es kann also durchaus sein, dass sich beim Verhalten außerhalb der Spezifikation in zukünftigen Releases etwas ändern könnte. In diesem konkreten Fall um den es jetzt hier geht, halte ich eine Verhaltensänderung in naher Zukunft aber für sehr unwahrscheinlich. Wenn es Ihnen ihre Arbeit erleichtert den MS DHCP zu verwenden und es funktioniert, dann können Sie diesen Weg ruhig beschreiten...