Posted: Wed Jan 28, 2009 11:15 Post subject: [gelöst] Bridge-Problem 802.1q Trunking & DHCP (VWLAN)
Hallo Gemeinde!
Ich habe einen Linksys WRT54GL mit DD-WRT V24 std (SVN revision 11482M NEWD Eko). Der Router ist an eine Firewall angeschlossen und arbeitet als einfacher AP.
Mein Ziel ist es 2 WLANs zur Verfügung zu stellen, die voneinander getrennt arbeiten. Dabei soll ein Netz (Gäste) nur Zugang zum Internet und das andere (intern) zusätzlich Zugriff auf das interne LAN bekommen. Außerdem möchte ich für die Verbindung vom Router zur Firewall nur ein einziges Kabel nutzen, wodurch die Pakete markiert (getaggt) werden müssen. Die Verteilung der IP-Adressen wird per DHCP von der Firewall übernommen. Das erste WLAN soll unter der Adresse 192.168.1.1, das virtuelle unter 192.168.2.1 erreichbar sein. Soweit der Plan...
Folgende Befehle habe ich auf der Konsole durchgeführt:
nvram set vlan0ports="5*"
nvram set vlan2ports="3 2 1 0t 5t"
nvram set vlan3ports="0t 5t"
Demnach sind jetzt alle LAN-Ports im VLAN2 und am Port 0 werden die Pakete von VLAN2 und VLAN3 getaggt.
Danach habe ich das virtuelle WLAN (wl0.1) über eine neue Bridge mit VLAN3 verbunden, damit seine Pakte ebenfalls über den Port 0 (getaggt) verschickt werden können:
Ich bekomme nur für das 192.168.1er Netz IPs von der Firewall zugewiesen, nicht aber für das 192.168.2er. Das Tagging an sich müsste funktionieren, da ich aus dem 1er Netz jeweils die Interfaces des 1er und 2er Netzes an der Firewall anpingen kann. Die DHCP-Funktion des Routers ist deaktiviert.
Kann mir bitte irgendjemand Hinweise (oder vielleicht sogar die Lösung?) geben, warum das virtuelle Netz keine IPs bekommt?
Ich für meinen Teil vermute, dass die Bridge (br1) nicht richtig funktioniert und deshalb keine Pakete an der Firewall ankommen. Aber ich kann mich auch täuschen!
Vielen Dank im Voraus!
Last edited by hans_m. on Fri Feb 20, 2009 8:22; edited 5 times in total
Ich habe hier eine tagged 802.1Q Verbindung zwischen dd-wrt und einem 3COM Switch herstellen können. Es sollte also prinzipiell möglich sein, falls deine Firewall damit umgehen kann. Ich habe aber alles komplett über die GUI konfiguriert (Setup -> VLANs und Setup -> Networking). Btw. - erst ein abschliessender Reboot brachte die VLAN-Konfiguration bei mir zum funktionieren. Daher kann ich zu den Konsolen-Befehlen nicht viel sagen. So ganz blicke ich daher bei deiner Konfiguration nicht durch.
Du müsstest also:
- je einen dd-wrt WLAN-AP an das jeweilige VLAN als untagged VLAN konfigurieren.
- die jeweilgen 802.1Q Trunk LAN Ports als Tagged VLAN untereinander und mit der Firewall verbinden.
Ich kann dir nur empfehlen es auf GUI Ebene nochmal zu probieren (abschliessenden reboot nicht vergessen).
Ja, den Thread habe ich auch schon gefunden.
Nach nochmaligem intensiven lesen und drüber nachdenken bin ich der Meinung, dass meine Konfiguration auch so funktionieren müsste.
Darf ich fragen, an welchen Port du den WHR-HP-G54 gehangen hast?
Die VLANs wurden sowohl auf der Konsole, als auch auf der Web GUI eingerichtet. Die Tabelle auf der Web GUI sieht zur Zeit so aus:
Reboots werden auch nach jeder wichtigen Änderung durchgeführt.
Allerdings bin ich mir noch nicht sicher, ob ich noch einmal extra das Tagging einstellen in der Web GUI muss, da das eigentlisch schon über die Konfiguration der Ports klar sein sollte.
Bei den Befehlen für die neue Bridge wird nichts anderes gemacht, als VLAN3 mit dem virtuellen WLAN (wl0.1) zur Bridge br1 zusammenzufassen.
Das war beim physikalischen WLAN (wl0) nicht nötig, da dieses sowieso mit dem vorhandenen LAN gebridged ist (br0).
Deshalb auch die Vermutung, dass etwas mit br1 nicht stimmt, denn für br0 bekomme ich ja IPs zugewiesen.
Richtig lesen ist ein gutes Stichwort ... ich habe jetzt nach nochmaligen lesen erst mitbekommen, daß du ja keine 2 physikalischen AP's hast, sondern auf einem einzigen 2 WLAN's machen willst ? Ok, damit habe ich keine Erfahrung.
Bei mir hängt ein WRT54G an einem VLAN1&11 getaggten 3COM Switchport. VLAN0 ist WAN, Port1 ist der 802.1Q Trunk zum 3COM Switchport. Port 2&3 sind normales LAN + WLAN und an Port4 bekomme ich IP-Adressen aus meinem anderen Subnetz.
----------W--1--2--3--4
VLAN00--x-------------- none
VLAN01-----x--x--x----- LAN
VLAN11-----x--------x-- none
Tagged-----x------------
Vielleicht hilft es bei dir, wenn du auch erstmal einen LAN Port in dein VLAN3 hängst, um zu sehen, ob du da die richtige IP-Adresse bekommst. Wenn das klappt, guckst du, wie du dein 2tes virtuelles WLAN Netz auf dein VLAN3 gebogen bekommst.
Wenn ich einen zusätzlichen Port mit in das VLAN3 nehme und mich über diesen mit einem LAN-Kabel mit dem Router verbinde, bekomme ich eine (richtige!) IP via DHCP zugewiesen.
Es muss also an der Bridge zwischen VLAN3 und dem virtuellen WLAN liegen! Jetzt kann ich wenigstens die Fehlersuche eingrenzen...
Ich habe jetzt weiter herumprobiert und es liegt definitiv an der Bridge br1.
Wenn ich wl0.1 in die Standard-Bridge (br0) verlege, bekomme ich sofort eine richtige IP zugewiesen.
Hat nicht noch irgendjemand eine Idee? Es ist langsam zum verzweifeln...
Ich habe den Fehler jetzt selbst gefunden. Nachdem ich die Bridge br1 nochmal über das Web-Interface erstellt und konfiguriert habe, ging das virtuelle WLAN auch. Es wurden zwar die bereits getätigten Einstellungen nur ein zweites mal vorgenommen, aber anscheinend braucht die Firmware eine "grafische Bestätigung".
Egal, mein System läuft!
An die Entwickler:
Ich ziehe meinen Hut vor Eurer Leistung und bin sehr dankbar für diese Firmware. Aber vielleicht wäre es möglich irgendwann einmal diese Inkonsistenz zwischen Konsole und Web-Interface abzustellen?
Ihr wisst sicher, wie ich das meine. Es ist einfach extrem nervig an einem solchen Fehler längere Zeit hängen zu bleiben.
Der Vollständigkeit wegen, hier noch die Firewall-Regeln:
# -> isolieren der beiden Bridges br0 und br1
# -> kein Zugriff von einem Netz in das andere
# -> Pakete von br0 nach br1, bzw. von br1 nach br0, werden verworfen
iptables -I FORWARD -i br0 -o br1 -j DROP
iptables -I FORWARD -i br1 -o br0 -j DROP
# -> Gaeste sollen keinen Zugang zum Router bekommen
# -> alle Verbindungen werden fuer TCP und UDP abgelehnt