MikroTik über LBS steuern | Edomi

[saegefisch]

Hallo allerseits,

nach dem ich letzte Woche endlich den Durchbruch hatte, nun die konsolidierten und geprüften Erkenntnisse in Scripte gelegt aus mehreren Gründen: Natürlich könnte ich Backups machen... Die mache ich natürlich auch. Aber die Scripte sind aus mehreren Gründen viel spannender:

• Ich habe selber viele verschiedene Anleitungen im WWW versucht und an Details immer wieder gescheitert. Irgendwas war immer und in der Kombination mit dem neuen HW-offload des RoutrerOS im RC (beta) war ich nie wirklich erfolgreich. Mit den Videos des RouterForums und viel versuchen bin ich zu einer Lösung gekommen, die nun jeder in 15-30 Minuten(!) selber erfolgreich zum Laufen bringen kann - ohne große Fehlerquellen und ohne Frust. Anpassen kann man danach an seine Bedürfnisse.
• Sie sind für jeden hier im Forum um Faktoren nützlicher, weil jeder sich die Scripte an seine Bedarf anpassen kann, dabei das Prinzip begreift und es jederzeit reproduzieren kann. Die Scripte laden zum experimentieren ohne Sorge um Aussperren, Rückbau,... ein. Zudem: Der Gerätepark der KNXUFer ja ist unterschiedlich RB2011, RB3011, hAP ac, hAP ac lite,... - jeder kann es an seinen Bedarf anpassen - z.B. jedem seine Port-Benennung. Wenn jemand erfolgreich war, dann rate ich natürlich ebenso zu einem Backup des erreichten...
• Die Scripte sind geschnitten: Stellen, an denen es anfangs zu einem disconnect kommen wird (neue MAC-Adresse) oder wo es inhaltlich logisch ist oder wo ein Sachverhalt später regelmäßige Adjustage eines begrenzten Kontexts will, konkret: CAPsMAN, Feste-IP-Adressen, Firewall.
• Um fehlerfrei die Scripte öfter ausführen zu können, beginnen sie stets mit einem Löschteil, der die neuen Objekte zuvor löscht. Damit kann man einspielen, ggf. adjustieren, wieder hoch laden und wieder ausführen. So kommt man auch bei komplexen Änderungen schnell zum Ziel ohne (fehleranfällige) irre Mausklickerei
• Videos und Screenshots sind sehr, sehr hilfreich, aber mit den Scripten kann jeder mit einem RB3011 + x hAP eine lauffähige Landschaft mit VLAN, CAPsMAN in tatsächlich 15 Minuten schaffen nach Reset aller Geräte. Hat bei mir heute 2x zum Test funktioniert...
• Vorher lohnt es natürlich, die Scripte an die eigenen Bedürfnisse anzupassen

Beginnen sollte man mit dem Router (RB3011 o.ä.), WinBox sollte via ether5 angeschlossen sein, weil die Scripte diesen bei RB und hAP zunächst bei VLAN aussparen und so ein Aussperren vermeiden, wenn die Kiste mal zickt. Wenn alles geht, sollte man ether5 manuell von "disable" auf "fallback" oder "check" stellen (je nach Bedarf).

Unterstützende Quellen:
https://blog.effenberger.org (gute Gedanken zum wie und warum, Sicherheit und überhaupt)
https://www.router-forum.de (ohne die Anleitung dort hätte ich es nicht hin bekommen - Danke!)

Voraussetzung: Die Geräte haben RouterOS ab 6.41rc61 oder neuer --> Upgrade über Channel "release candidate" --> ohne Gewähr! Danach jeweils Reset ohne default-Konfiguration. Nachtrag: Die RC-Firmware scheint mir noch nicht so gut (Probleme bei ANmeldung seit Upgrade); veilleicht die besser lassen, bis 6.41 stable verfügbar ist. Die Packages sind aber wunderbar.
Nachtrag 20.12.17: Die Ursache lag wohl am Cache von winbox. Jetzt geht der login wie immer. Es scheint mir derzeit doch nicht mehr nachteilig, den Upgrade durchzuführen, wenn man die Packages auch auf RC-Level heben will.

Upload: File -> Upload aller Dateien zum Gerät
Nacheinander ausführen im Terminal mit

/import verbose=yes <Scriptname>

10 - RB3011 - Ports benennen + RoMon + Grundeinstellung.rsc
--> Portnamen anpassen
--> Systemnamen anpassen
--> !!! RoMON-Passwort: ein WIKRLICH sicheres, langes PW wählen und anpassen !!!!
--> Ausführen -> Reconnect nach Ausführung
--> Der nächste Reboot aktiviert IPv6

11 - RB3011 - Bridges + VLAN + Switch1.rsc
--> VLAN anpassen
--> Ausführen -> vermutlich Neuanmeldung nach Ausführung
--> Danach manuell: Es scheint ein Bug zu sein: Der Switch ohne WAN (bei mir Switch 1) muss manuell auf "switch all ports=yes" gesetzt werden

12 - RB3011 - Bridge Ports + Switch2.rsc
--> VLAN anpassen
--> Am Switch Trunk- und Access-Ports anpassen
--> Bitte Hinweis ganz unten beachten, wenn es kein RB3011 (mit GBit-Ethernet ist)!
--> Ausführen -> vermutlich Neuanmeldung nach Ausführung

20 - RB3011 - Grunddaten + IP.rsc
--> Adressbereich, DHCP-Server,... anpassen
--> ggf. WAN-Port anpassen (DHCP-Client, da bei mir im DMZ hinter Fritzbox)

21 - RB3011 - CAPsMAN.rsc
--> !!! WLAN-Passworter: sicher PW wählen und anpassen !!!!
--> sinnvolle SSIDs wählen

22 - RB3011 - IP feste Adressen.rsc
--> kann sich jeder selber anlegen für seinen Bedarf
/ip dhcp-server lease add server=dhcp-010-int address=192.168.10.xxx mac-address=<deineMAC> comment="<wasauchimmer>"
/ip dns static add address=192.168.10.xxx name="<wasauchimmer>"

30 - RB3011 - Absicherung.rsc
--> alles zunächst auskommentiert; fungiert nur als Ideenegeber --> UNBEDINGT im Nachgang noch für sich selber lösen

31 - RB3011 - Firewall.rsc
--> dient als erster Wurf und Fundgrube - SO NICHT HINREICHEND, erst recht, wenn der Router nicht in einer DMZ liegt!!!
--> Bitte nach dem Ausführen zunächst alle FW-Regeln deaktivieren (nur NAT behalten) --> testen, dass Internetzugang unf CAPsMAN funktioniert
--> Danach kann für sich seine eigene Welt adjustieren... das ist vermutlich never-ending...

Danach nun beliebig viele hAP einrichten. Achtung, hAP ac und hAP ac lite müssen wegen Fast-Ethernet ja/nein unterschiedlich behandelt werden.
In Script 10 für hAP mindestens an das RoMON-PW denken. Dann Scripte 10 - 30 einspielen ähnlich oben. Die Firewall ist naturgemäß bei einem AP schmal und sollte so funktionieren. Für CAP ist es wichtig, dass die hAP ein korrekte Zeit via NTP bekommen haben. Im Zweifel spricht das Log meist hilfreich. Am Ende - wenn alles erfolgreich ist - in allen Geräten für Port ether5 noch im Switch das VLAN aktivieren.

Wenn man testweise alles so lässt PW, Ports,..., dann sollte man tatsächlich nach 15 Minuten mit seinem Smartphone sein VLAN-WLAN wählen und surfen können. Ich hoffe, dass dies dem ein oder anderen zweckdienlich ist und Frust vermeidet. Anders gesagt: Das lesen dieses Posts dauert länger als das Einspielen...

Wenn jetzt endlich der RB bei mir funktioniert, werde ich mir auch den LBS von André mal anschauen. Die obigen Scripte sind aber eher nicht sinnvoll dafür... oder man möchte per edomi jederzeit auf Knopfdruck seinen RB komlett neu aufsetzen können... wiiie cooool ist das dennnnn!

Viel Spaß und viel Erfolg,
Carsten

[coliflower]

Hallo Carsten, Gratulation zum Erfolg ! Das wird sicher einigen helfen :-)
Ich habe keinen MT-Router aber zwei wAP-ac ... melde mich mal zum Thema CAPsMAN.

[Janncsi]

Hallo Carsten,

vielen Dank für die Erstellung der Scripte.

Werde die am WE mal durcharbeiten bzw. abändern für die Nutzung auf einem CRS125

Übrigens an alle die die Berichte im Netz lesen, dass der CRS125 so wenig Leistung hätte...Der Prozessor und auch die Taktrate ist identisch zum RB2011, welcher ja doch häufig als SOHO-Router genutzt wird. Ich habe den CRS nun mit 7 Vlans, OpenVPN-Server, Capsman und einer recht sicheren Firewall am Laufen und ich komme nicht einmal im Durchschnitt auf 20% Last....da ist genug Reserve für den Heimbedarf.

Also ein 24port Gigabit-Switch mit umfangreichen Routingfunktionen, SFP-Port und nur 15W maximalen Verbrauch...ich bin zufrieden :-P

[Janncsi]

Vielleicht ganz interessant was Mikrotik jetzt herausgebracht hat:

https://www.mikrotik-store.eu/de/mikrotik-mups-mups

Ist ein POE-Injektor inkl. USV-Anschluss und das für läppische 28€
Werde mir wohl 2-3 Stück holen und meinen übergroßen 16fach POE-Injektor in Rente schicken.

[shortyle]

saegefisch besten Dank für die Scripts.
Auch als absoluter Mikrotik Neuling versteht man nach mehrmaligen Lesen was da so alles gemacht wird.
2 Fragen hätte ich aber noch:

1. in einigen Scripts schreibst du "#### erst aufräumen... oder besser nicht, weil man sich sonst selbst abschießt..."
werden diese befehle nun ausgeführt wenn ich das Script unverändert lasse, oder sollte man diese Befehle noch auskommentieren?

2. Du erstellst ja verschiedene VLAN für z.B. mgmt, int, haus, etc. So eine Aufteilung find ich ebenfalls sehr gut, nur fehlt mir die Fanatasie, was da in den einselnen VLAN für Geräte sein sollen
Kannst du mir mal ein Bespiel nennen welche Geräte in den einzelnen VLAN sein könnten.
Bei Haus sicher ein KNX IP Router / bei Media dann SmartTV, Kodi o.ä., NAS / bei mgmt vermutlich das RB + weitere Switche + AP
Aber was "packt" man bei iot (InternetofThings) oder int rein?

Und wo würdest du einen Laptop, iPad, Waschmaschine o.ä. einfügen?

Beste Grüße und Danke nochmal
David

[saegefisch]

Auf die Schnelle:
zu 1.) Script einfach ausführen. Die #### sind nur Kommentare im Script. Kann man halt gut sehen beim ausführen. Und am Anfang räumt das Script eben alle Objektetypen weg, bevor sie neu angelegt werden. Damit kann man die Script - verändert oder unverändert - beliebig oft ausführen, ohne manuell vorher die richtigen Objekte löschen zu müssen. Ich würde diese Teile in den Script unverändert lassen und nur die „nutzdaten“ adjustieren.
kurz: Backup von deinem aktuellen Stand machen (damit kannst du immer zurück), Hirn aus, Gas geben... ))))

2.)
Mgmt = mgmt de Mikrotik Geräte

int = internes lan / Innerer Kreis mit Daten. Hier liegen meine PC (denen ich vertraue), meine NASe. Höchst schützenswert

haus = der IPVerkehr für KNX,DALI,DMX, mein ganzer SMA PV-Krams. Edomi. Höchst schützenswert.

Media = kodi, Sonos. Mediengeräte, denen ich halbwegs vertraue. TV Geräte und BR-Player auch; die bekommen bei mir aber _nie_ Internet. Alles Datenschlampen!

IoT = da habe ich noch nichts drin, aber ich ahne, dass ich mich nicht gegen die Zeit werde stellen können. Ihr wird der ganz Zoo von zumeist nicht Updatefähigem Risiko-Geräten landen. Per default wird dort nichts was dürfen und werde scharfkantig erlauben. Dort würden schlechte Webcams, Echos, alexas, anderer Mist rein kommen - wenn er denn überhaupt zu mir kommt. Noch wehre ich mich standhaft... ich wollte vorbereitet sein... . Ich ahne, das das künftig mehr ist, als uns recht und richtig ist... mein Plan: hochgradig einzuzäunen (just my 2 Cents)

gast = hm, verdammt...habe vergessen, wofür das war...

[saegefisch]

Achso...zu deiner Frage noch : Waschmaschine - im Zweifel erst einmal alles, was nicht sicher Update-fähig ist: IoT!
Erst wenn ich einem Gerät vertraue UND es einen Mehrwert hat, würde ich es in ein anderes VLAN legen. Derlei gehört keinesfalls in das Haus-VLAN. Haus meint wirklich Haus, nicht Haushaltsgeräte; zumindest bei mir. Darin sehe ich ja gerade den Sicherheitsgewinn.

aber: das ist lediglich mein Ansatz. Jeder muss und darf und sollte das für sich, seine Anforderungen und seine Risiko-Einschätzung selber einschätzen und kann gerne das Ganze ganz anders machen.

[Janncsi]

Zur Vlan-Struktur und der Geräteaufteilung....ich gehe grundsätzlich danach vor, welche Teile ich wie und wovor schützen möchte...

Beispiel, wie ich es mache:
VLan99 sind bei mir alle Netzwerkgeräte, welche sich nur aus dem VLan99 aufrufen lassen. Router und Access-Points beispielsweise. Dazu gibt es einen Port am Router, welcher im VLan99 ist und nicht in andere VLans routet und einen MAC-Filter hat, so dass nur 3 Geräte Zugriff erhalten.
VLan10 sind bei mir alle Clients, die normal ins Internet gehen, wie bspw. Laptops oder Handys. Keine große Beschränkung, Standard-Firewall, etc.
VLan20 ist bei mir alles was mit dem Haus zu tun hat: Edomi, KWL, KNX-Router. Von einigen VLans zu erreichen, aber nicht von allen, zudem keine Verbindung nach draussen und wenn, dann nur temporär
VLan30 beinhaltet alle telefonrelevanten Dinge
VLan40 ist alles, was mit Media zu tun hat. Sat-Receiver, TV, FireTV
VLan50 ist mein Heos-System
....

Jedes VLan hat bei mir andere Prioritäten, auch in Bezug auf QoS. VLan20 wird bei mir immer die oberste Priorität für das Haus behalten, VLan50 dagegen kann gerne zwischendurch ausfallen...

Mit dem hiesigen LBS lassen sich übrigens noch ganz andere Dinge realisieren....so kann man bei Abwesenheit oder Urlaub einfach mit Firewall-Regeln, welche Bezug auf einzelne VLans haben, die Sicherheit extrem erhöhen. Bspw. kann bei Abwesenheit das VLan20 nur noch unter den drei Teilnehmern eine Kommunikation erlauben und ist ansonsten nach aussen dicht. Auch ein VLan10 benötigt keinerlei Kommunikation bei Abwesenheit....einfach mal alles droppen was in dem VLan passiert...

[shortyle]

Super, ich danke euch beiden. Hat wieder etwas mehr Licht ins Dunkel gebracht

edit:
eine Frage doch noch. Du schreibst das die 6.41rc61 Probleme machen kann und man auf die stable warten soll. Akutell ist ja die 6.40 stable und RC gibt es die 6.41rc66.
Die scripte sollten aber auch unter der 6.40 laufen, oder?

[saegefisch]

Nein, das wird es nicht, weil es bis 6.40 das Konzept der Master-Ports gibt. Der RC und die kommende Version 6.41 haben diese Option nicht mehr, sondern nutzen eine Funktion, sie sich HW-offload nennt. Es dient dazu, recht einfach und vom Router im wesentlichen selbst erkannt den möglichen Switch-Verkehr (der nicht geroutet werden muss auf Layer 3 = IP) über die Switch-Chips auf Layer 2 laufen zu lassen. Das ist schneller und sparsamer und braucht die Master-Paramete nicht mehr. Man kann das im wesentlichen durch eine geschickte Wahl der Ports unterstützen.
Der Weg von Mikrotik scheint darüber hinaus im Ausblick in Richtung der VLAN an den Bridges zu gehen, was die EInrichtung vereinfachen würde - aber das ist wohl noch Zukuntfsmusik.

Kurz: Nein, für 6.40 können die Scripte als Ideengeber dienen, aber schon im 10er-Script fehlen wesentliche Parameter für die Master-Ports in 6.40. Du kannst Sie aber auf 6.40 leicht anpassen - dazu gibt es viele Beispiele im WWW (z.B. die beiden Links in meinem Beitrag oben). Die Videos im Router-Forum von Mod "CapFloor" z.B. beziehen sich derzeit noch auf 6.40.

Und: Ich konnte meine login-Probleme nun auch woanders verorten - daher sehe ich nun kein Problem mehr, neben den Packages auch die Firmware anzuheben. Am Ende gilt dazu aber immer: JEDER ist dafür selbst verantwortlich, was er tut. Ich kann dazu weder raten, noch abraten. Ich kann nur von meinen Erfahrungen berichten. Erfahrungen machen muss letztlich jeder selber. Und: IMMER Backup vorher. Und bei produktiven Systemen ggf. warten, bis 6.41 im stable bereit steht.

[stonie2oo4]

Habt ihr eigentlich nen eigenen Benutzer für den LBS angelegt?
Wäre ja denk ich mal sicherer als den Admin-Benutzer zu nehmen.
Wenn ja, was für "Policies" würde dieser benötigen. Reicht "api" hier aus?

Unter Services hatte ich alles außer Winbox und ssh deaktiviert. Jetzt gibts da "api" und "api-ssl".
Funktioniert mit dem LBS beides? Ist es dann besser "api-ssl" zu verwenden oder ist es egal, da es ja vom eigenen Lan aus kommt?

Gruß und frohe Weihnachten

[saegefisch]

Nachtrag zu meinen Scripten: Bei meinem 1. Wurf habe ich das Aufräumen irgendiwe völlig (unsinnig) überkonstruiert. Habe meine Scripte jetzt vereinfacht; jeder kann sich die Scripte für sich und die anderen Scripte auch anpassen. Am Beispiel von "31 - RB3011 Firewall.rsc" sieht das bei mir jetzt so (viel schlanker) aus:

#### erst aufräumen...
{:log info "Remove IP FIREWALL ADDRESS-LIST before creation - Script Start"
:foreach obj in=[/ip firewall address-list find] do={
                 /ip firewall address-list remove $obj }
:delay 3
}
#### aufgeräumt!
#### erst aufräumen...
{:log info "Remove IP FIREWALL FILTER before creation - Script Start"
:foreach obj in=[/ip firewall filter find action!=passthrough] do={
                 /ip firewall filter remove $obj }
:delay 3
}
#### aufgeräumt!

[saegefisch]

...aber auf der anderen Seite dachte ich, dass man mit "Torch" und Fleiß das Thema Firewall für die VLAN lösen kann - denn ohne ergibt VLAN ja überhaupt keinen Sinn. Doch nun zerschelle ich an der Firewall:

• Die Netzmasken für die DHCP-Server der VLAN habe ich von /24 auf /16 geändert, da sich die Geräte sonst nicht sehen. Richtig? Gedanke wäre: Das muss sein, damit sich die Geräte VLAN-übergreifend technisch sehen können. Alles andere soll in der FW alles gedropped werden, außer aktiv erlaubter Verkehr z.B. von VLAN010 nach VLAN020, aber nicht von VLAN020 nach VLAN010.
• Wenn ich z.B. ein 192.168.10.10 (VLAN010) und ein 192.168.20.11 (VLAN020) an einem Switch habe, dann sehe ich in Torch nicht einmal den Traffic, obwohl die beiden sich sehen (Ping, SMB). Es ist ja gewünscht, dass der VLAN-interne Traffic auf Switch-HW läuft. Aber wie stelle ich sicher, dass VLAN-übergreifender Traffic auch über die FORWARD-Regeln der FW laufen und nicht daran vorbei. Oder habe ich falsch geschaut?
• Wenn die die beiden Geräte z.B. am RB und am hAP anschließe, dann sehen sich die beiden nicht gar nicht (weder Ping, noch SMB) und sehe schon wieder kein Traffic in Torch am Trunk-Port zwischen hAP und RB. Ich nahm an, der Verkehr würde über den Trunk vom hAP an den RB gehen und würde dort über die FW laufen. Und wenn man ihn nicht aktiv dropped, dann sollten sich beide Geräte an Ihren VLAN010 und VLAN020-Access-Ports auch sehen können. Oder habe ich falsch geschaut?

Bin für einen Tipp dankbar, wo mein Gedankenfehler liegt...

[jonofe]

Ist zwar schwierig sich in eine komplett unterschiedliche Konfiguration reinzudenken, aber hier mal das was mir beim Lesen deiner Punkte durch den Kopf ging:

• Den ersten Punkt habe ich nicht verstanden. Warum ist die netmask wichtig dafür, dass sich die VLANs sehen? Ich vermute dies ist nur nötig, weil die Kommunikation direkt über den Switch HW Chip läuft, richtig? Denn ansonsten würde das Routing ja sicherstellen, dass sie sich sehen. Oder?
• Das du in Torch nichts siehst liegt ggf. daran, dass die Kommunikation über den Switch HW Chip läuft und nicht über den Router und der Router die Pakete dann gar nicht sieht.
• Beim dritten Punkt könnte es am fehlenden Routing im RB liegen. Wenn dort ein Paket von VLAN10 (hAP) zu VLAN20 (RB) ankommt, muss der Router natürlich wissen, wohin er es Routen soll. Eigentlich sollte diese Routes ja dynamisch angelegt werden. Das könntest Du in /ip route prüfen. Außerdem ist wichtig, dass das default Gateway für die VLAN korrekt ist, d.h. 192.168.10.1 für VLAN10 und und 192.168.20.1 für VLAN 20. Weiterhin muss in der forward chain der traffic von VLAN10 zu VLAN20 und umgekehrt erlaubt sein, aber das ist ja der Fall, wenn ich dich richtig verstanden habe.

Wie gesagt, sind nur Vermutungen auf Basis meines gesunden Halbwissens.

In diesem Sinne: Frohes Neues

[saegefisch]

Hey André,

vielen Dank für Deine Gedanken - ich wünschte, ich hätte auch nur einen kleinen Teil Deines gesunden Halbwissens...

• Die DHCP-Server liefern bereits für jedes VLAN nach meinem Verständnis korrekte GW-Daten an die Clients und hAP. Ich komme aus allen VLAN korrekt ins WWW inkl. DNS auf Port 53. Und per FW kann ich das auch für jedes VLAN oder einzelne IP unterbinden/erlauben --> sollte sauber funktionieren.
• Grundsätzlich möchte ich von den höherwertigen VLAN in die niederwertigen VLAN zugreifen können, nicht aber anders herum. Z.B: vom "inneren Zirkel" auf meine Kodi-Clientes, die aber nicht auf meinen inneren Zirkel.
• Die VLANs resultieren durch die DHCP-Server letztlich in IP-Adressebereichen - nicht zuletzt an den Access-Ports - daher auch die Netzmasken-Relevanz (nach meinem Verständnis): VLAN010 -> 192.168.10.1/24 | VLAN020 -> 192.168.20.1/24 | ...
• Zur FW: Nach meinem Verständnis ist erst einmal alles erlaubt im RB. Wenn ich alle FW-Regeln deaktiviere, müsste ich von VLAN zu VLAN kommunizieren können (wenn die Netzmaske der Clients groß genug ist). Da ich in der FW am Ende jeder Chain immer einen Drop vorsehe ist hingegen nur genau das erlaubt, was ich zuvor als Regel erlaube. Aber zu meinen 2. und 3. Spiegelstrich: die FW scheint ja gar nicht gefragt zu werden.
• Zur Netzmaske: Nach meinem Verständnis muss z.B. ein Windows-PC 192.168.10.10 eine /16-Netzmaske haben, damit er einen anderen PC 192.168.20.11 sehen kann. Die übliche /24 würde das sonst verhindern, selbst wenn der Router die beiden erfolgreich routen würde. Damit sich die beiden sehen können, muss beides erfüllt sein: Der Router routet und die Netzmaske der Clients unterbindet nicht das gegenseitige Sehen, oder? Und weiter denke ich nicht, dass das etwas mit dem Switch oder der Switch HW zu tun hat (die machen ja eigentlich Layer 2). Und darum bin ich ja so überrascht, dass der Inter-VLAN-Traffic im Switch zu laufen scheint, den VLAN ist doch Layer 3 - dachte ich.
• Im 2. Punkt vermute ich genauso wie Du: Läuft über Switch HW. Aber wie kann ich erreichen, dass nur VLAN-intern über Switch HW läuft, aber inter-VLAN zwangsweise geroutet wird und damit die FW auch erreicht?
• Zum 3. Punkt: Wie gesagt, ins WWW wird korrekt aus jedem VLAN geroutet, egal ob der Client am RB oder einem hAP (LAN oder WLAN) angebunden ist. Daher nahm ich an, dass es nicht an fehlenden Routen liegen kann, die ja offensichtlich durch den Trunk-Port vom hAP zum RB funktionieren. Fakt ist aber, dass die beiden Clients ins WWW können, sich eben nicht sehen, wenn einer am RB und einer am hAP angebunden ist.