[HowTo] FRITZ!Box im IP-Client Moduls mit Gastnetz u. VLAN

averlon

Neuer User
Mitglied seit
1 Jan 2010
Beiträge
7
Punkte für Reaktionen
1
Punkte
3
Hallo,
die FRITZ!Box (hier 7530) kann ja sehr viel. Manche Einstellungen sind in manchen Kombinationen über die WEBUI aber nicht einstellbar, obwohl verfügbar.

So habe ich die FRITZ!Box als IP-Client laufen und wollte sowohl ein VLAN nutzen, als auch ein Gastnetz (LAN + WLAN).
VLAN kann die FRITZ!Box grundsätzlich nicht, zuminest nicht im Bereich LAN u. WLAN - soweit ich das feststellen konnte. Das kann man dann nur über einen Switch lösen, der VLAN beherrscht, was allerdings eine Grundvoraussetzung ist für VLAN.
Update!
Voraussetzung: Ein Switch oder Router/Switch der VLAN kann.
LAN-1 von der FRITZ!Box muss in einen Port des Switch mit VLAN xxx (normales LAN u. WLAN) gesteckt werden
LAN-4 von der FRITZBox brauch ein Kabel zu einem anderen Port des Switch mit VLAN yyy (Guest-LAN u. Guest-WLAN). Damit können die Netze dann z.B. durch FW-Regeln am Router getrennt behandelt werden (sofern der Router das kann). Ich gehe mal davon aus, dass der, der die FRITZ!Box als Client betreibt einen leistungsfähigen Router hat.


Man kann sich eine Sicherung der Konfiguration machen. Die entsprechende Datei mit der Endung ".export" kann dann mit einem Editor bearbeitet werden und später, sofern man die Prüfsumme am Ende der Datei korrigiert hat, wieder importieren.

Wenn man nun im IP-Client Modus auch das Gastnetz aktiviert haben möchte sind folgende Änderungen nötig.

Code:
ar7cfg {
....
*** diese Einstellungen dürften STANDARD sein ***
        ethinterfaces {
                name = "eth0";
                dhcp = no;
                ipaddr = 192.168.178.1;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                dhcpenabled = no;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
                is_guest = no;
                is_hotspot = no;
                multicast_snooping = yes;
                is_public = no;
        } {
                name = "eth0:0";
                dhcp = no;
                ipaddr = 169.254.1.1;
                netmask = 255.255.0.0;
                dstipaddr = 0.0.0.0;
                dhcpenabled = yes;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
                is_guest = no;
                is_hotspot = no;
                multicast_snooping = yes;
                is_public = no;
        } {
                name = "wlan";
                dhcp = no;
                ipaddr = 192.168.182.1;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                interfaces = "ath0", "ath1", "wdsup?";
                dhcpenabled = yes;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
                is_guest = no;
                is_hotspot = no;
                multicast_snooping = yes;
                is_public = no;
        }
        brinterfaces {
...
        } {
                name = "guest";
                dhcp = no;
                ipaddr = 192.168.179.1;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                interfaces = "guest?*", "guest_ct*", "guest_st*";
                dhcpenabled = no;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
                is_guest = yes;
                is_hotspot = no;
                multicast_snooping = yes;
                is_public = no;
        }
...

eth_port_config {
...
        } {
                portnumber = 4;
                power_mode = power;
                config_mode = mode_guestbridge;
                dev = "eth3";
                label = "LAN:4";
        }
        default_guest_ethernet_port = "LAN:4";
...
wlancfg {
...
*** diese Einstellung ist - soweit ich das feststellen konnte - auch im IP-Client Modus über die WEBUI möglich ***
        guest_ssid = "was immer man hier haben will";
...

usercfg {
...
        users2 {
                type = internet_user_guest;
                landeviceUID = 0;
                ip = 0.0.0.0;
                filter_profile_id = 1; *** damit wird das Profil festgelegt - in der WebUI kommt man an die Profile nicht ran ***

Ich übernehme logischerweise keine Garantie für die Konfiguration oder für Fehler die dadurch auftreten. Versteht sich eigentlich von selbst!
 
Zuletzt bearbeitet:
  • Like
Reaktionen: andih
Was ist/wäre denn der Sinn des Ganzen?
 
Ich weiß nicht, ob ich das richtig verstanden habe: Bei mir ist der Router eine Digitalisierungsbox. Wlan verteilen mehrere Fritzboxen (und AVM-Repeater), die alle im Client-Modus laufen. Eine davon ist Mesh-Master. Oben genanntes könnte ich nun nutzen um ein Gastnetz aufzumachen, was bei meiner Konfig eigentlich nicht geht. Allerdings weiß ich nicht ob die Mesh-Clienten das dann auch übernehmen.
 
Du weißt auch nicht, ob da wirklich ein vom eigenen Netz entkoppeltes Gastnetz aufgemacht wird, oder ob da nur ein weiterer Name für "Gastnetz" erzeugt wird. ;)
 
Ich weiß, ich bin ein alter Skeptiker ... aber das erinnert mich (auch von der Wirrnis in #1 - oder kann mir jemand:
Das kann man dann nur über einen Switch lösen, der VLAN beherrscht, was allerdings eine Grundvoraussetzung ist für VLAN.
oder auch:
erklären?) eher ans "Law of Cunningham" als an eine ernsthafte Anleitung zum tatsächlichen und für andere nachvollziehbaren Erreichen eines (mir) unbekannten Ziels.
 
Was ist/wäre denn der Sinn des Ganzen?
Das macht Sinn, wenn man Ubiquity AP besitzt, wo Haupt- und Gastnetz gleichzeitig getrennt laufen können.
Entscheidend ist aber auch wie die TAGs und PVID im Switch gesetzt werden.
Sonst hat #1 wirklich nicht viel Sinn.
 
Was ist/wäre denn der Sinn des Ganzen?
Hi,
nach dem Sinn eines Gastnetzes fragst du ja wahrscheinlich nicht.
Nach meiner Kenntnis kann man ein Gastnetz normalerweise über die WebUI im IP-Client Modus nicht konfigurieren. Zumindest nicht den Teil im LAN-4. Und damit geht das VLAN nicht.
Wann man das haben will um z.B. die Netze zu trennen, dann kenne ich keinen anderen Weg - bin aber für Anregungen offen.

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Allerdings weiß ich nicht ob die Mesh-Clienten das dann auch übernehmen.
Hi,
ich habe einen Repeater im Mesh und der übernimmt das Gastnetz.

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Du weißt auch nicht, ob da wirklich ein vom eigenen Netz entkoppeltes Gastnetz aufgemacht wird, oder ob da nur ein weiterer Name für "Gastnetz" erzeugt wird. ;)
Sagen wir mal so: Zumindest wird dem Gastnetz ein eigener IP-Bereich zugeordnet. Das alleine ist schon eine gewisse Trennung. Den Rest kann dann, wie geschrieben, eine FW des Routers machen. Je nach Konfiguration des Routers bzw. Typ des Routers sind getrennte IP-Bereich von Haus aus getrennt und müssen über Konfiguration bzw. FW gegenseitig "erlaubt" werden. Hängt, so mein Kenntnisstand, vom Router ab.
Aber man kann eben das Gastnetz trennen - wenn man will - und ich will!

Und nebenbei bemerkt kann man damit (die Konfig ist dann etwas anders) auch einen Hotspot aufbauen. Ich weiß, dafür gibt es andere Möglichkeiten mit anderen Geräten und einem Captive Portal, ....., aber es ginge auch nur mit einer FB im IP-Client Modus. Auch das lässt die WebUI, soweit ich das weiß, im IP-Client Modus nicht zu.
 
Zuletzt bearbeitet von einem Moderator:
Das setzt aber schon voraus, daß der "dsld" mit der geänderten "ar7.cfg" (ich habe die auszuführenden Änderungen aber auch nicht wirklich verstanden, insofern kann ich weder die Intention dahinter, noch die Umsetzung beurteilen) auch tatsächlich zwei getrennte (logische) Netze aufspannt, zwischen denen die Box selbst dann nichts "routet" (der "dsld" baut ja aus den Einstellungen in der "ar7.cfg" die passende Konfiguration für den internen Switch in der FRITZ!Box zusammen - insofern ist das mit dem "Routing" (erst recht als "IP-Client") ohnehin so eine Sache bzw. die falsche "Annahme", weil es da eigentlich direkt über den (internen) Switch geht) ... denn ansonsten ist da nichts mit "Gastnetz" (in dem Sinne, daß die Netze tatsächlich getrennt werden) und die Box ist nichts anderes als ein (per LAN-Kabel an LAN4 angebundener) WLAN-AP.

Und um wirklich glauben zu können, daß da - durch diverse Randbedingungen - am Ende eine Konfiguration bei herauskommt, wo 192.168.179.0/24 weder auf 192.168.178.0/24 noch auf 192.168.182.0/24 zugreifen kann, braucht es schon etwas mehr ... z.B. mal einen Auszug aus den Support-Daten mit der gezeigten Konfiguration, wo man (a) die Interface-Konfigurationen (inkl. Routing-Table) und (b) die Konfiguration von (internem) Switch und den logischen Bridges (ich nehme mal an, daß da weiterhin eine "brinterfaces"-basierte Konfiguration gesetzt wird, denn eine Änderung von "ethmode" in der "ar7.cfg" kann ich in #1 nicht erkennen und der Standardwert aus der Vorlage wäre m.W. immer noch "ethmode_bridge") irgendwie erkennen kann.

Ich würde jedenfalls vermuten (ohne eigene Ambitionen, das irgendwie jetzt testen zu wollen), daß es sich nicht um getrennte Netze handelt (was dann den Sinn und Zweck eines Gastnetzes konterkarieren würde) ... ja, ich würde sogar bezweifeln (weil hier die Einstellungen für den Modus "ethmode_bridge" und "ethmode_router" bzw. "ethmode_router_split" fröhlich durcheinander geworfen werden), daß das WLAN-"Netzwerk" bei dieser "ar7.cfg" tatsächlich als Bridge-Interface aus "ath0", "ath1" und "wdsup*" zusammengebaut wird als Interface "wlan" - aber ich wäre ohnehin schon überrascht, wenn ein Eintrag unter "ethinterfaces" bei "ethmode_bridge" überhaupt berücksichtigt wird und wenn/daß es da ein Attribut "interfaces" geben soll (was da für mich gar keinen Sinn ergibt), was der Parser für die Konfigurationsdatei klaglos schluckt.

Mangels 7530 könnte ich das nicht einmal selbst testen (und das Resultat in Form der o.a. Support-Datei prüfen), wenn ich das wollte ... es gibt halt viele "Unstimmigkeiten" in der gezeigten Konfiguration, bis hin zum "Modus" (das überschüssige "l" im Thread-Titel irritiert zusätzlich bzw. läßt auf "Nachlässigkeiten" beim Schreiben schließen, was bei einem "HowTo" sicherlich nicht der Fall sein sollte ... aber das wäre auch geschenkt).

Daher auch meine "Eingangsfrage" ... es macht eben einen gewaltigen Unterschied, WIE man die FRITZ!Box danach genau einsetzen will und welche Geräte man mit ihr (sowohl per Ethernet-Kabel und an welchem Port, als auch per WLAN und mit welcher (von ihr aufgespannten!) SSID) verbinden wollte und es macht ebenfalls einen erheblichen Unterschied, wo und wie man das Ergebnis der eigenen Änderungen überprüft und vor allem getestet hat.

So ein Test macht halt auch nur dann Sinn, wenn man eine "Erwartungshaltung" hat, was sich nach den Änderungen ergeben sollte - nur dann kann man das "Ergebnis" auch entsprechend beurteilen. Insofern teile ich die Skepsis, ob da tatsächlich eine Trennung entsteht, die es für ein "echtes Gastnetz" bräuchte ... wenn das erst noch jede Menge anderer Einstellungen (auch noch an weiteren Geräten als der FRITZ!Box) bedarf, ist der Titel sicherlich sehr irreführend und jemand, der das auf diesem Weg versucht nachzubauen (und dabei irgendeine tatsächlich lauffähige Konfiguration erhält), schießt sich ggf. selbst ins Knie und breitet anstelle eines "Gastnetzes" sein eigenes, internes LAN vor jedem Besucher (und Angreifer) aus.

Ich bin mir auch bei #6 nicht so richtig klar, welchen "Switch" @schnurgly da meint ... ist es tatsächlich auch ein externer, sind wir wieder bei der "unvollständigen Beschreibung/Erklärung" (zumindest sollte man dann noch dazu schreiben, welches Kabel wo hineingehört und welche Einstellungen man an diesem externen Switch (das wäre ja dann wohl einer mit Kabeln, denn einen WLAN-Switch kenne ich nicht) vornehmen müßte) und meint er damit den internen der FRITZ!Box, fehlt m.W. bei den IPQ-Boxen ein Äquivalent zum "switch_cli" der GRX-Modelle, mit dem man dann die eigenen Einstellungen für diesen Switch vornehmen könnte (womit man dann auch nicht mehr an der "ar7.cfg" herumfummeln müßte) - mal abgesehen von der Tatsache, daß Shell-Zugriff hier ja bisher überhaupt keine Rolle spielte.

Das alles macht es (i.V.m. den sehr unvollständigen bzw. sehr widersprüchlichen Angaben in #1) eher schwer durchschaubar und damit auch nur sehr schwer (schon gedanklich) nachvollziehbar ... was letztlich der Grund für die weiterhin vorhandenen Zweifel (bei mir) ist, daß das tatsächlich so funktioniert wie beschrieben bzw. daß das auch tatsächlich zum erwarteten Ergebnis führt. Wenn Du ein anderes Ergebnis erwartest, solltest Du das eben auch so beschreiben, daß andere es verstehen können und sich nicht erst ihren eigenen Reim machen müssen, was man damit eigentlich (ggf. auch erst in Verbindung mit vielen weiteren Gerätschaften und Einstellungen) erreichen wollen könnte.
 
Danke @averlon für die gute Idee und Anleitung. Ich habe bei meinen Mesh-Master nun guest-WLAN über Port 4 am Router (dort läuft auch dhcp server für guest). Funktioniert gut!
Ich habe im Mesh noch einen abgesetzten, über LAN angebundenen repeater. Der erkennt zwar das guest WLAN vom Master via Mesh, ein Gerät bekommt aber via repeater noch keine IP, also kein Link zum router.
Weiss jemand, wie master und repeater kommunizieren? Doch eine Art VLAN?
 
über LAN angebundenen repeater
Du meinst das AVM-Mesh? Das hat erstmal nichts mit der LAN-Brücke zu tun. Du kannst eine LAN-Brücke zwischen zwei FRITZ-Produkten auch ohne AVM-Mesh betreiben. Das AVM-Mesh ist (lediglich) für die Konfiguration und Steuerung untereinander wichtig. In welchem VLAN liegt der als LAN-Brücke konfigurierte FRITZ!Repeater? Hast Du bereits probiert diesen FRITZ!Repeater anstatt über den VLAN-tagging-Switch direkt in die FRITZ!Box zu stecken?
 
Ja, du hast recht. Mesh und LAN-Bridge sind unabhängig. Was ich nicht verstehe ist folgendes: der abgesetzte, als LAN-Bridge angeschlossene Repeater hat ein normales WLAN und das Guest-WLAN. Er hat aber nur einen Ethernet-Port (im Gegensatz zur Fritzbox, bei der man das guest-WLAN auf Port 4 bringen kann). Irgendwie müssen nun die Daten des normalen und des Guest-WLAN beim Repeater über einen einzigen Port. Zur Zeit ist der Repeater nur im "normalen" Netz. Dieses Problem besteht eigentlich auch, wenn wie von AVM vorgesehen, der Router eine Fritz-Box wäre. Ist es bei mir ja bekanntlich nicht.
Nein, den Versuch den Repeater direkt an die Fritzbox zu hängen, habe ich nicht gemacht. Wird später auch keine Option sein.
 
Irgendwie müssen nun die Daten des normalen und des Guest-WLAN beim Repeater über einen einzigen Port.
Das wird über layer2-tunnel gemacht.
Etwas AVM spezifisches, was kein Fremdgerät trennen kann.
 
Danke für die Info. Wohin geht der Tunnel? Normalerweise zur Internet-Router-Fritzbox. Und wenn es die nicht gibt, weil dort eben ein nicht-AVM Produkt ist?
Ich habe insgeheim gehofft, dass zB die FritzBox, welche den Mesh-Master macht und selber auch auf LAN-Port4 ein Guest-Netzwerk hat, als 'Router' fungieren könnte, der den Traffic von diesem AVM-speziefischen Tunnel wieder trennen kann.
 
Zuletzt bearbeitet:
Habe versucht meine Frage so zu überarbeiten, dass sie verständlicher sein sollte
 
Gast-Netzwerk auf einem FRITZ!Repeater geht nur dann, wenn eine FRITZ!Box umherschwirrt. Jedenfalls ist das mein Kenntnisstand. Daher steht eisbaerin vermutlich – ich auf jeden Fall – auf dem Schlauch, was Du genau meinst.
 
Danke für den Link. Ich kenne ihn, leider lösen sie das Problem aber mit besserer Hardware. Bei mir ist das Setup vereinfacht wie folgt:
  • Router ins Internet, der keine Fritzbox ist. Bietet LAN und Guest-LAN an.
  • Fritzbox, welche als IP-Client im Netz hängt (LAN) und WLAN- und Guest-WLAN anbietet (funktioniert dank Port 4 als Guest-LAN (VLAN zum Router)
  • AVM Fritz Repeater 1200, welcher via LAN angebunden ist, da abgesetzt. Er bietet zwar auch ein WLAN und Guest-WLAN an, DHCP und traffic gehen aber 'verloren'
  • Dazwischen noch ein Switch, welcher entsprechend konfiguriert ist.
Deshalb war meine Frage, ob jemand einen Idee hat, wie man den anscheinend proprietären getunnelten Traffic von den WLAN's des Repeaters irgendwie aufteilen kann bzw der Fritzbox zum Aufteilen überlassen kann. Dazu habe ich im Netz leider nichts gefunden.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.