10
Monowall, VLAN - DHCP Problem
Hallo,
ich arbeite gerade an eine Monowall / VLAN Projekt und hab noch ein kleines Problem.
Der Aufbau ist folgender:
Monowall mit 3x VLANS (V10,V20,V30), 1x WAN, 1xLAN für Konfig
Cisco Switch SG200-26
4 Accesspoints mit 3 VLANS
2 PCs, angebunden an VLAN 20
2 PCs, angebunden an VLAN 30
Ich hab also am Cisco Switch und an der Mono die 3 Vlans eingerichtet.
Am Cisco sind die Ports folgendermaßen eingerichtet:
P1 = v1, v20t, v30t, v40t (Port zur Monowall)
P13 = v20 (angeschlossener PC, Problem)
P14 = v20 (angeschlossener PC, Problem)
P19 = v30 (angeschlossener PC, Problem)
P20 = v30 (angeschlossener PC, Problem)
P21-24 = v20t, v30t, v40t (angeschlossen 4x Accesspoint)
Zur besseren Veranschaulichung habe ich die Topologie skizziert:
Nun zum Problem:
Die PCs die an P13,14,19 und 20 angeschlossen sind sind untagged am Cisco eingerichtet, doch leider bekommen Sie von der Mono keine IP über DHCP zugewiesen. Die Geräte die sich über die 4 Accesspoint einloggen bekommen allerdings IPs zugewiesen. Der einigste Unterschied ist meiner Meinung nach dass die APs tagged angeschossen sind und ich bei den Ports 13,14 etc. v1 auf fortbilden gesetzt habe.
Es muss doch möglich sein auch diesen an den Switch direkt anschlossen Geräte eine IP zuzuweisen. Hat Jemand ne Idee??
ich arbeite gerade an eine Monowall / VLAN Projekt und hab noch ein kleines Problem.
Der Aufbau ist folgender:
Monowall mit 3x VLANS (V10,V20,V30), 1x WAN, 1xLAN für Konfig
Cisco Switch SG200-26
4 Accesspoints mit 3 VLANS
2 PCs, angebunden an VLAN 20
2 PCs, angebunden an VLAN 30
Ich hab also am Cisco Switch und an der Mono die 3 Vlans eingerichtet.
Am Cisco sind die Ports folgendermaßen eingerichtet:
P1 = v1, v20t, v30t, v40t (Port zur Monowall)
P13 = v20 (angeschlossener PC, Problem)
P14 = v20 (angeschlossener PC, Problem)
P19 = v30 (angeschlossener PC, Problem)
P20 = v30 (angeschlossener PC, Problem)
P21-24 = v20t, v30t, v40t (angeschlossen 4x Accesspoint)
Zur besseren Veranschaulichung habe ich die Topologie skizziert:
Die PCs die an P13,14,19 und 20 angeschlossen sind sind untagged am Cisco eingerichtet, doch leider bekommen Sie von der Mono keine IP über DHCP zugewiesen. Die Geräte die sich über die 4 Accesspoint einloggen bekommen allerdings IPs zugewiesen. Der einigste Unterschied ist meiner Meinung nach dass die APs tagged angeschossen sind und ich bei den Ports 13,14 etc. v1 auf fortbilden gesetzt habe.
Es muss doch möglich sein auch diesen an den Switch direkt anschlossen Geräte eine IP zuzuweisen. Hat Jemand ne Idee??
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: 182728
Url: https://administrator.de/contentid/182728
Ausgedruckt am: 26.11.2024 um 17:11 Uhr
10 Kommentare
Neuester Kommentar
Was ist "fortbilden" ?? ( v1 auf fortbilden gesetzt habe.) Da ist etwas unverständliches Kauderwelsch ?!
Leider hast du die Cisco Switchkonfig hier nicht gepostet was sehr hilfreich gewesen wäre...
Generell hast du ja alles richtig gemacht, was du ja an den unterschiedlichen sauber funktionierenden WLANs sehen kannst, die in ihren korrespondierenden VLANs ja dann die richtigen IPs bekommen.
Da stimmt also Switchkonfig und DHCP arbeitet auch (wir gehen jetzt mal davon aus das die DHCP Server auf der Monowall laufen und nicht auf dem Switch selber !?)
Die Switchports der PCs in VLAN 20 (13 und 14) müssen alle die folgende Port Konfig auf dem Cisco Switch haben:
switchport mode access
switchport access vlan 20
spanning-tree portfast
Analog dazu die Ports 19 und 20 im VLAN 30:
switchport mode access
switchport access vlan 30
spanning-tree portfast
Gerade das letzte Kommando ist nicht ganz unwichtig, denn ohne portfast (sofern du einen IOS Switch hast) ist der Switchport ca. 40 Sekunden im Blocking Mode und ein Endgerät dort bekommt keine DHCP IP was dein Eindruck gibt das es nicht funktioniert.
Das solltest du also sicherstellen.
Noch eine Gefahr lauert die aber ursächlich nichts mit dem DHCP zu tun hat !
Bedenke das das der Traffic an deinen beiden LAN Ports (192.168.100.0 /24) und auch dem 2ten LAN Port (OPT-1) von den beiden Parent Interfaces, also den physischen Interfaces, immer untagged gesendet wird !
Wenn du diese jetzt jeweils ohne entsprechende Konfig auf einen gemeinsamen VLAN Switch steckst, sind beide Parent Interfaces über das Default VLAN (1) des Switches miteinander verbunden um Layer 2 (also bridged) was auch Sicherheitssicht sehr gefährlich ist !!
Einfach gesagt ist also das physische OPT1 Interface (Parent) 1 zu 1 mit deinem LAN Interface (Konfig) verbunden damit. Das gleiche also ob du ein Kabel von LAN zu OPT1 steckst oder diese Ports über einen Hub/Switch verbindest. Tödlich für eine Firewall aus Sicherheitssicht....
Wenn du einen IOS Cisco Switch hast solltest du das native (default) VLAN an diesem OPT1 Port also zwingend auf einen anderen Wert am Switch setzen, damit dieser Traffic auf dem Trunk mit den VLANs blockiert ist vom default VLAN.
Richte also ein Dummy VLAN z.B. 99 ein und sage an dem Trunkport am Switch der zu OPT1 verbindet "switchport native vlan 99" !
Damit wird der untagged Traffic am OPT1 Interface dann in das Dummy VLAN 99 gesendet und ist isoliert vom VLAN 1 und somit sind beide Interfaces wieder sauber getrennt wie es sein soll bei einer FW.
Auch wenn du auf dem OPT1 Parent Interface (untagged) nichts konfiguriert hast und nur auf den VLAN Child Interfaces dazu (10, 20 und 30) solltest du das immer machen zur Sicherheit !
Leider hast du die Cisco Switchkonfig hier nicht gepostet was sehr hilfreich gewesen wäre...
Generell hast du ja alles richtig gemacht, was du ja an den unterschiedlichen sauber funktionierenden WLANs sehen kannst, die in ihren korrespondierenden VLANs ja dann die richtigen IPs bekommen.
Da stimmt also Switchkonfig und DHCP arbeitet auch (wir gehen jetzt mal davon aus das die DHCP Server auf der Monowall laufen und nicht auf dem Switch selber !?)
Die Switchports der PCs in VLAN 20 (13 und 14) müssen alle die folgende Port Konfig auf dem Cisco Switch haben:
switchport mode access
switchport access vlan 20
spanning-tree portfast
Analog dazu die Ports 19 und 20 im VLAN 30:
switchport mode access
switchport access vlan 30
spanning-tree portfast
Gerade das letzte Kommando ist nicht ganz unwichtig, denn ohne portfast (sofern du einen IOS Switch hast) ist der Switchport ca. 40 Sekunden im Blocking Mode und ein Endgerät dort bekommt keine DHCP IP was dein Eindruck gibt das es nicht funktioniert.
Das solltest du also sicherstellen.
Noch eine Gefahr lauert die aber ursächlich nichts mit dem DHCP zu tun hat !
Bedenke das das der Traffic an deinen beiden LAN Ports (192.168.100.0 /24) und auch dem 2ten LAN Port (OPT-1) von den beiden Parent Interfaces, also den physischen Interfaces, immer untagged gesendet wird !
Wenn du diese jetzt jeweils ohne entsprechende Konfig auf einen gemeinsamen VLAN Switch steckst, sind beide Parent Interfaces über das Default VLAN (1) des Switches miteinander verbunden um Layer 2 (also bridged) was auch Sicherheitssicht sehr gefährlich ist !!
Einfach gesagt ist also das physische OPT1 Interface (Parent) 1 zu 1 mit deinem LAN Interface (Konfig) verbunden damit. Das gleiche also ob du ein Kabel von LAN zu OPT1 steckst oder diese Ports über einen Hub/Switch verbindest. Tödlich für eine Firewall aus Sicherheitssicht....
Wenn du einen IOS Cisco Switch hast solltest du das native (default) VLAN an diesem OPT1 Port also zwingend auf einen anderen Wert am Switch setzen, damit dieser Traffic auf dem Trunk mit den VLANs blockiert ist vom default VLAN.
Richte also ein Dummy VLAN z.B. 99 ein und sage an dem Trunkport am Switch der zu OPT1 verbindet "switchport native vlan 99" !
Damit wird der untagged Traffic am OPT1 Interface dann in das Dummy VLAN 99 gesendet und ist isoliert vom VLAN 1 und somit sind beide Interfaces wieder sauber getrennt wie es sein soll bei einer FW.
Auch wenn du auf dem OPT1 Parent Interface (untagged) nichts konfiguriert hast und nur auf den VLAN Child Interfaces dazu (10, 20 und 30) solltest du das immer machen zur Sicherheit !
Hallo Aqui,
vielen Dank für deine Rückmeldung.
1. "fortbilden" sollte forbidden heißen (Autokorrektur, sry)
2. DHCP läuft auf der Mono
3. Leider finde keine Option "switchport mode access" einzustellen. "switchport access clan 20" finde ich als Einstellung auch nicht, soll aber bestimmt heißen, dass der Port Zugang zu VLAN 20 hat, was ich ja mit "untagged" eingestellt hab:
spanning-tree portfast ist so wie ich das verstehe Global aktiviert:
Ich hab heut Nacht den Switch und die Einstellungen ressetet und daraufhin hat mein DHCP an den Ports wieder funktionioniert. Zur Gefahr von der du Schreibst muss ich mir noch kurz Gedanken machen - möchte das aber gerne noch mal kurz durchsprechen.
Edit: Da ich den Switch neu konfiguriert habe, haben sich meine Vlans leicht geändert, also nicht wundern. Die jetzige Topologie schaut so aus:
Die Konfig des Switches, welches übrigens ein Cisco Small Business Switch ist:
vielen Dank für deine Rückmeldung.
1. "fortbilden" sollte forbidden heißen (Autokorrektur, sry)
2. DHCP läuft auf der Mono
3. Leider finde keine Option "switchport mode access" einzustellen. "switchport access clan 20" finde ich als Einstellung auch nicht, soll aber bestimmt heißen, dass der Port Zugang zu VLAN 20 hat, was ich ja mit "untagged" eingestellt hab:
spanning-tree portfast ist so wie ich das verstehe Global aktiviert:
Ich hab heut Nacht den Switch und die Einstellungen ressetet und daraufhin hat mein DHCP an den Ports wieder funktionioniert. Zur Gefahr von der du Schreibst muss ich mir noch kurz Gedanken machen - möchte das aber gerne noch mal kurz durchsprechen.
Edit: Da ich den Switch neu konfiguriert habe, haben sich meine Vlans leicht geändert, also nicht wundern. Die jetzige Topologie schaut so aus:
Die Konfig des Switches, welches übrigens ein Cisco Small Business Switch ist:
vlan database
vlan 10,20,30,40
exit
voice vlan oui-table add 0001e3 Siemens_AG_phone________
voice vlan oui-table add 00036b Cisco_phone_____________
voice vlan oui-table add 00096e Avaya___________________
voice vlan oui-table add 000fe2 H3C_Aolynk______________
voice vlan oui-table add 0060b9 Philips_and_NEC_AG_phone
voice vlan oui-table add 00d01e Pingtel_phone___________
voice vlan oui-table add 00e075 Polycom/Veritel_phone___
voice vlan oui-table add 00e0bb 3Com_phone______________
interface vlan 1
ip address 192.168.100.221 255.255.255.0
exit
interface vlan 1
no ip address dhcp
exit
hostname switch028633
no passwords complexity enable
username cisco password encrypted 7af78c911d5b48bea1dc2449d9d89513abeb4be5 privilege 15
interface gigabitethernet1
switchport trunk allowed vlan add 10,20,30,40
exit
interface gigabitethernet7
switchport trunk native vlan 30
exit
interface gigabitethernet8
switchport trunk native vlan 30
exit
interface gigabitethernet9
switchport trunk native vlan 30
exit
interface gigabitethernet10
switchport trunk native vlan 30
exit
interface gigabitethernet11
switchport trunk native vlan 30
exit
interface gigabitethernet12
switchport trunk native vlan 30
exit
interface gigabitethernet21
switchport trunk allowed vlan add 10,20,40
exit
interface gigabitethernet22
switchport trunk allowed vlan add 10,20,40
exit
interface gigabitethernet23
switchport trunk allowed vlan add 10,20,40
exit
interface gigabitethernet24
switchport trunk allowed vlan add 10,20,40
exit
interface vlan 10
name V10
exit
interface vlan 20
name V20
exit
interface vlan 30
name V30
exit
interface vlan 40
name "V40-Gastzugang"
exit
Die Gefahr auf die du anspielt ist natürlich auf jeden Fall ein Problem, ich Verstehe zwar das Problem und auch die Lösung, nur ist mir nicht ganz klar wie ich dies einzurichten hab. Ob ich ein IOS Switch habe weiß ich nicht genau, ich habe einen "Cisco Small Business Switch SG200-26"
Meine ganze Hardware läuft in diesem Netz: 192.168.100.x
Switch: 192.168.100.221
Mono-LAN: 192.168.100.220 (Port für die Konfig)
Mono-Opt: 192.168.99.220 (auf dem Opt sind die ganzen VLANs eingerichtet)
Und du sagst jetzt dass die Ports an der Mono untagged an den Switch übertragen wird, sprich man kann relativ einfach auf mein 100er Netz zugreifen, soweit versteh ich das.
Die Lösung wäre also den Port der mit dem Opt Verbunden ist von Default V1 auf V99 zu setzten. Dann müsste es so gelöst sein:
Meine ganze Hardware läuft in diesem Netz: 192.168.100.x
Switch: 192.168.100.221
Mono-LAN: 192.168.100.220 (Port für die Konfig)
Mono-Opt: 192.168.99.220 (auf dem Opt sind die ganzen VLANs eingerichtet)
Und du sagst jetzt dass die Ports an der Mono untagged an den Switch übertragen wird, sprich man kann relativ einfach auf mein 100er Netz zugreifen, soweit versteh ich das.
Die Lösung wäre also den Port der mit dem Opt Verbunden ist von Default V1 auf V99 zu setzten. Dann müsste es so gelöst sein:
Du hast keinen IOS Switch, das sind die Cisco Catalyst Switches also deren "richtige" Switches. Aber egal das geht mit der Billigserie auch keinen Sorge...
Einen kleinen Fehler hast du gemacht:
Alle deine Access Ports an denen nur Endgeräte dran sind hast du weiterhin im Trunk Modus. Das solltest du in jedem Falle ändern in den "Access Mode", das machst du im Menü "Interface Settings". Trunk sind nur die Ports die auch die VLANs tagged übertragen sollen !
Das vorab...
Zum Default VLAN Problem:
Ich hatte da einen Denkfehler gemacht. Das Problem ist zwar faktisch existent betrifft dich aber logischerweise nicht, da dein LAN Port zum Konfigurieren gar kein Trunk ist also hier gar keine default VLANs anliegen.
Den LAN Port hast du vermutlich dediziert in VLAN 30 gesteckt und auch diesen Switch Port dann als Access Port (wichtig ! das darf KEIN Trunk sein deshalb, siehe Hinweis oben !) definiert.
Damit kann es zu der Verbindung der beiden Parent Interface gar nicht erst kommen, vergiss das also erstmal.
Relevant wäre es nur wenn du auch VLANs am LAN Port hättest und auch im Parent IP netz arbeiten würdest. bei dir nicht der Fall !
Also alles gut !
Wenn du nun die Ports entsprechend in den Access Modus änderst und ihnen die korrekten VLANs zuweisst sollte das sauber funktionieren mit dem DHCP !
Frage zum Schluss: Wo stellst du den Telnet Zugang ein für die Text Konfig. Ich habe hier einen SF200-48 der weist mir alle Telnet Versuche ab !
Einen kleinen Fehler hast du gemacht:
Alle deine Access Ports an denen nur Endgeräte dran sind hast du weiterhin im Trunk Modus. Das solltest du in jedem Falle ändern in den "Access Mode", das machst du im Menü "Interface Settings". Trunk sind nur die Ports die auch die VLANs tagged übertragen sollen !
Das vorab...
Zum Default VLAN Problem:
Ich hatte da einen Denkfehler gemacht. Das Problem ist zwar faktisch existent betrifft dich aber logischerweise nicht, da dein LAN Port zum Konfigurieren gar kein Trunk ist also hier gar keine default VLANs anliegen.
Den LAN Port hast du vermutlich dediziert in VLAN 30 gesteckt und auch diesen Switch Port dann als Access Port (wichtig ! das darf KEIN Trunk sein deshalb, siehe Hinweis oben !) definiert.
Damit kann es zu der Verbindung der beiden Parent Interface gar nicht erst kommen, vergiss das also erstmal.
Relevant wäre es nur wenn du auch VLANs am LAN Port hättest und auch im Parent IP netz arbeiten würdest. bei dir nicht der Fall !
Also alles gut !
Wenn du nun die Ports entsprechend in den Access Modus änderst und ihnen die korrekten VLANs zuweisst sollte das sauber funktionieren mit dem DHCP !
Frage zum Schluss: Wo stellst du den Telnet Zugang ein für die Text Konfig. Ich habe hier einen SF200-48 der weist mir alle Telnet Versuche ab !
Hi,
also vorab, ich habe keine Telnetverbdinung, wenn du wegen der Konfig auf die Idee gekommen bist dann muss ich dich enttäuschen, dass ist nur das Backupfile des Switches.
OK, die Trunks stelle ich natürlich um, dass könnte tatsächlich mein DHCP Problem erklären ;)
Dann möchte ich aber noch mal auf die Sicherheit zurückkommen.
Zur Erklärung: Meine Hardware ist im 192.168.100.255 Netz angesiedelt, sprich mein Switch hat 100.220, die Mono 100.221, die APs 100.231-234. Am Switch:
P1 = VLAN Übertragung zur Mono
P2-6 = (nicht benutzt)
P7-12 = VLAN30
P13-20= nicht konfiguriert
P21-24= Vlan 10, 20 und 30 an APs
Und mein LAN Port der Mono (192.168.100.220) geht auf Port 13 am Switch und auf P14 stecke ich mein Notebook ein. Da ich noch relativ unerfahren mit der Einrichtung von Firewalls bin, bin ich mir daher jetzt nicht bewusst ob ich dadurch ein Problem habe - wovon ich jetzt ausgehe weil du davon ausgehst dass ich den dediziert gesteckt habe :/. Das VLAN 30 soll btw. für Mitarbeiter sein, die natürlich keinen Zugang zur Hardware haben dürfen.
also vorab, ich habe keine Telnetverbdinung, wenn du wegen der Konfig auf die Idee gekommen bist dann muss ich dich enttäuschen, dass ist nur das Backupfile des Switches.
OK, die Trunks stelle ich natürlich um, dass könnte tatsächlich mein DHCP Problem erklären ;)
Dann möchte ich aber noch mal auf die Sicherheit zurückkommen.
Zur Erklärung: Meine Hardware ist im 192.168.100.255 Netz angesiedelt, sprich mein Switch hat 100.220, die Mono 100.221, die APs 100.231-234. Am Switch:
P1 = VLAN Übertragung zur Mono
P2-6 = (nicht benutzt)
P7-12 = VLAN30
P13-20= nicht konfiguriert
P21-24= Vlan 10, 20 und 30 an APs
Und mein LAN Port der Mono (192.168.100.220) geht auf Port 13 am Switch und auf P14 stecke ich mein Notebook ein. Da ich noch relativ unerfahren mit der Einrichtung von Firewalls bin, bin ich mir daher jetzt nicht bewusst ob ich dadurch ein Problem habe - wovon ich jetzt ausgehe weil du davon ausgehst dass ich den dediziert gesteckt habe :/. Das VLAN 30 soll btw. für Mitarbeiter sein, die natürlich keinen Zugang zur Hardware haben dürfen.
Nein kein Problem, das ist alles sauber und richtig so !
Port 13 und 14 am Switch müssen als untagged Access Port in einem separaten VLAN sein !! Das ist das einzige ToDo was du zwingend machen musst !
Lege also VLAN 99 z.B. an und nenne das "Konfig" o.ä. und lege 13 und 14 als Access Ports da rein fertig.
Der LAN Port der Firewall ist dann sauber abgetrennt.
Machst du das NICHT hast du in der Tat ein Sicherheitsloch !! Das "Warum" ist leicht erklärt....:
Da Port 13 und 14 nicht konfiguriert sind fallen sie ins default VLAN 1 wo alle nicht konfigurierten Ports arbeiten und verbunden sind ! Soweit so gut !
An Port 1 des Switches ist dein Monowall OPT-1 Port mit den VLANs. Soweit OK, aber das Parent Interface hier, also "vr2" das physische Interface dieses Ports, sendet auch immer untagged Pakete die beim Trunk dann auch im VLAN 1 landen. Die VLANs hieram Port senden ihre Pakete mit ihrem VLAN Tag
Damit ist dann das LAN und der physische OPT-1 Port in einem VLAN verbunden, da deren untagged Pakete der Switch beide ins VLAN 1 forwardet.
Generell merkt man das nicht denn du fährst ja 2 unterschiedliche IP Netze auf den Ports und nutzt meist das native untagged Parent Interface nicht.
Dennoch sind sie aber verbunden. Jemand der sich ins VLAN 1 steckt und eine entsprechende IP vergibt kommt also problemlos an den LAN Port und an den OPT Port was du ja nicht willst...das ist das Problem !
Wie gesagt das bekommst du ganz einfach gefxt indem du den LAN Port in ein dediziertes VLAN legst oder ein weiteres VLAN anlegst und das native VLAN am OPT Port auf dieses VLAN legst.
So trennst du diese wieder sicher !
Du hast es oben schon gemacht, denn wenn du dir den Port 1 ansiehst dann siehst du dort: **10T, 20T, 30T, 40T, 99UP"
das bedeutet 10 Tagged, 20 Tagged, 30 Tagged, 40 Tagged und 99 Untagged werden hier übertragen. Untagged Traffic an diesem Port landet in VLAN 99
Beides führt also zum Ziel und so wie es oben ist ist es richtig !
Port 13 und 14 am Switch müssen als untagged Access Port in einem separaten VLAN sein !! Das ist das einzige ToDo was du zwingend machen musst !
Lege also VLAN 99 z.B. an und nenne das "Konfig" o.ä. und lege 13 und 14 als Access Ports da rein fertig.
Der LAN Port der Firewall ist dann sauber abgetrennt.
Machst du das NICHT hast du in der Tat ein Sicherheitsloch !! Das "Warum" ist leicht erklärt....:
Da Port 13 und 14 nicht konfiguriert sind fallen sie ins default VLAN 1 wo alle nicht konfigurierten Ports arbeiten und verbunden sind ! Soweit so gut !
An Port 1 des Switches ist dein Monowall OPT-1 Port mit den VLANs. Soweit OK, aber das Parent Interface hier, also "vr2" das physische Interface dieses Ports, sendet auch immer untagged Pakete die beim Trunk dann auch im VLAN 1 landen. Die VLANs hieram Port senden ihre Pakete mit ihrem VLAN Tag
Damit ist dann das LAN und der physische OPT-1 Port in einem VLAN verbunden, da deren untagged Pakete der Switch beide ins VLAN 1 forwardet.
Generell merkt man das nicht denn du fährst ja 2 unterschiedliche IP Netze auf den Ports und nutzt meist das native untagged Parent Interface nicht.
Dennoch sind sie aber verbunden. Jemand der sich ins VLAN 1 steckt und eine entsprechende IP vergibt kommt also problemlos an den LAN Port und an den OPT Port was du ja nicht willst...das ist das Problem !
Wie gesagt das bekommst du ganz einfach gefxt indem du den LAN Port in ein dediziertes VLAN legst oder ein weiteres VLAN anlegst und das native VLAN am OPT Port auf dieses VLAN legst.
So trennst du diese wieder sicher !
Du hast es oben schon gemacht, denn wenn du dir den Port 1 ansiehst dann siehst du dort: **10T, 20T, 30T, 40T, 99UP"
das bedeutet 10 Tagged, 20 Tagged, 30 Tagged, 40 Tagged und 99 Untagged werden hier übertragen. Untagged Traffic an diesem Port landet in VLAN 99
Beides führt also zum Ziel und so wie es oben ist ist es richtig !
Wow, danke für diese ausführliche Erklärung - das zeugt von echtem Fachwissen 
Aber dann bin ich ja beruhigt, jetzt muss ich noch die Monowall-Firewall dicht machen und der Aufbau vor Ort kann beginnen - bin schon leicht begeistet von der Monowall und ihren Fähigkeiten.
Jetzt hab ich lediglich noch zwei Punkte die mir nicht ganz klar sind, diese sind zwar unwichtig für den anstehenden Aufbau aber dennoch hätte ich es gerne gewusst.
Ich habe ein VLAN 40 welches über Wlan ausgestrahlt wird und ein VLAN 30 an dem ich über "Acceess Ports" direkt zwei PCs anschließe. Zuerst hatte ich für die beiden PCs auch das VLAN 40 benutz, dann jedoch festgestllt, dass die beiden PCs direkt mit den Geräte über Wlan kommunizieren, also nicht über die Monowall-Firewall - alles auch logisch und nachvollziehbar. Daraufhin hab ich für die beiden PCs ein VLAN 30 eingerichtet und konnte somit den Verkehr über die Firewall regeln. Meine Frage ist jetzt folgende: Kann ich die Geräte die direkt am Swich eingesteckt (und im gleichen VLAN sind wie das über die AccessPoints - Wlan) sind zwingen die Route über Firewall zu nehmen, denn dann würde ich jaein VLAN sparren?
Und zweitens, ich habe mit meine 4 VLANS und meine Physischen LAN insgesammt 5 unterschiedliche Netzte und musste keine einzige NAT-Regel einrichten. Ich komme also egal von welchem VLAN auf alle anderen Netze ---- warum????
Aber dann bin ich ja beruhigt, jetzt muss ich noch die Monowall-Firewall dicht machen und der Aufbau vor Ort kann beginnen - bin schon leicht begeistet von der Monowall und ihren Fähigkeiten.
Jetzt hab ich lediglich noch zwei Punkte die mir nicht ganz klar sind, diese sind zwar unwichtig für den anstehenden Aufbau aber dennoch hätte ich es gerne gewusst.
Ich habe ein VLAN 40 welches über Wlan ausgestrahlt wird und ein VLAN 30 an dem ich über "Acceess Ports" direkt zwei PCs anschließe. Zuerst hatte ich für die beiden PCs auch das VLAN 40 benutz, dann jedoch festgestllt, dass die beiden PCs direkt mit den Geräte über Wlan kommunizieren, also nicht über die Monowall-Firewall - alles auch logisch und nachvollziehbar. Daraufhin hab ich für die beiden PCs ein VLAN 30 eingerichtet und konnte somit den Verkehr über die Firewall regeln. Meine Frage ist jetzt folgende: Kann ich die Geräte die direkt am Swich eingesteckt (und im gleichen VLAN sind wie das über die AccessPoints - Wlan) sind zwingen die Route über Firewall zu nehmen, denn dann würde ich jaein VLAN sparren?
Und zweitens, ich habe mit meine 4 VLANS und meine Physischen LAN insgesammt 5 unterschiedliche Netzte und musste keine einzige NAT-Regel einrichten. Ich komme also egal von welchem VLAN auf alle anderen Netze ---- warum????
Frage 1:
Nein, das geht logischerweise nicht. Dein VLAN 40 und das dazu korrespondierende WLAN (ESSID) arbeiten ja logisch gesehen in einem Netz, das heisst quasi auf "einem Draht". Der WLAN AP arbeitet wie bei allen WLAN APs immer nur als simple OSI Layer 2 Bridge also auf Basis der Endgeräte Mac Adressen.
Fazit:
Endgeräte im WLAN und dem dazu (zur ESSID) korrespondierenden VLAN "sehen" immer alle Geräte direkt, egal ob diese im WLAN sind oder per Kupfer direkt am Switch hängen. Deshalb haben sie ja auch immer das gleiche IP Netzwerk !
Die Firewall kontrolliert nur eine Kommunikation auf dem Layer 3 (also Routing) nicht aber im Layer 2 (Mac Adress, Bridging basierend)
Lösen kannst du das also nur, wie du es schon richtig gemacht hast. Du musst die PCs in einem eigenen VLAN/IP Netz isolieren. So müssen sie über den Router sprich Firewall um mit den anderen netzen zu kommunizieren und du kannst das dann über die Firewall Regeln genau kontrollieren.
Dieses "PC VLAN" darf aber NICHT zu einer WLAN SSID (ESSID) korrespondieren, quasi also nur ein Kupfer VLAN sein. Das PC VLAN muss aber an der Firewall anliegen, klar denn diese muss routen und den Traffic kontrollieren.
So kannst du dann die PCs firewallseitig trennen von den WLANs und auch allen Zugriff und Traffic so sauber kontrollieren.
Hoffe das war jetzt so richtig verstanden was du vorhattest ?!
Frage 2:
Vermutlich (...das ist jetzt nur geraten) da du deine Firewall Regeln nicht beschreibst, hast du auf allen VLAN Interfaces an der FW bzw. den zu diesen Interfaces korrespondierenden Firewall Regeln erstmal zum Testen eine Any zu Any Regel eingesetzt, also das alle IPs aus dem VLAN Netz Überall hin dürfen (any / * auf any/* erlauben).
Da die Firewall Regeln immer nur eingehend, also ins Interface rein, gelten, darf dann logicherweise jeder mit jedem kommunizieren.
Wenn z.B. du keinen Traffic von VLAN 10 ins VLAN 30 erlauben willst, dann musst du eine Firewall Regel erstellen:
Source Adresse: VLAN 10 Netz, DENY/Verboten, Port: any, auf Zieladresse: VLAN 30 Netz, Port: any !
Achtung: Diese Regel MUSS immer zuerst in der Firewall Regel Reihenfolge stehen an dem Interface !!
Warum....???
Bei Firewall ACLs gilt immer grundsätzlich: "First Match wins !"
Hast du also z.B. eine Any zu Any Regel an erster Stelle und an 2ter Stelle deine Verbotsregel von oben, dann ist mit der ersten Regel alles erfüllt und weitere FW Regeln werden NICHT mehr abgearbeitet (First match wins !)
Deine Verbotsregel wird also immer ignoriert obwohl sie im Regelwerk steht...nur eben an falscher Stelle der Reihenfolge !!
Deshalb ist die Reihenfolge der Firewall Regeln so immens wichtig am Interface und du hast in den Regeln ganz rechts die Option die Regel zu verschieben !!
Die Reihenfolge zählt also ganz wichtig bei solchen Regeln !!
Verbotsregeln kommen so also logischerweise immer an den Anfang des Regelwerks auf dem Interface !!
Es gelten also 2 Kardinals Grundsätze bei den Regeln:
1.) Regeln werden nur eingehend abgearbeitet !
2.) Die Reihenfolge zählt (First match wins Prinzip !)
Wenn du das genau beachtest dann funktionieren die Einschränkungen auch absolut sauber und zuverlässig !!
Nein, das geht logischerweise nicht. Dein VLAN 40 und das dazu korrespondierende WLAN (ESSID) arbeiten ja logisch gesehen in einem Netz, das heisst quasi auf "einem Draht". Der WLAN AP arbeitet wie bei allen WLAN APs immer nur als simple OSI Layer 2 Bridge also auf Basis der Endgeräte Mac Adressen.
Fazit:
Endgeräte im WLAN und dem dazu (zur ESSID) korrespondierenden VLAN "sehen" immer alle Geräte direkt, egal ob diese im WLAN sind oder per Kupfer direkt am Switch hängen. Deshalb haben sie ja auch immer das gleiche IP Netzwerk !
Die Firewall kontrolliert nur eine Kommunikation auf dem Layer 3 (also Routing) nicht aber im Layer 2 (Mac Adress, Bridging basierend)
Lösen kannst du das also nur, wie du es schon richtig gemacht hast. Du musst die PCs in einem eigenen VLAN/IP Netz isolieren. So müssen sie über den Router sprich Firewall um mit den anderen netzen zu kommunizieren und du kannst das dann über die Firewall Regeln genau kontrollieren.
Dieses "PC VLAN" darf aber NICHT zu einer WLAN SSID (ESSID) korrespondieren, quasi also nur ein Kupfer VLAN sein. Das PC VLAN muss aber an der Firewall anliegen, klar denn diese muss routen und den Traffic kontrollieren.
So kannst du dann die PCs firewallseitig trennen von den WLANs und auch allen Zugriff und Traffic so sauber kontrollieren.
Hoffe das war jetzt so richtig verstanden was du vorhattest ?!
Frage 2:
Vermutlich (...das ist jetzt nur geraten) da du deine Firewall Regeln nicht beschreibst, hast du auf allen VLAN Interfaces an der FW bzw. den zu diesen Interfaces korrespondierenden Firewall Regeln erstmal zum Testen eine Any zu Any Regel eingesetzt, also das alle IPs aus dem VLAN Netz Überall hin dürfen (any / * auf any/* erlauben).
Da die Firewall Regeln immer nur eingehend, also ins Interface rein, gelten, darf dann logicherweise jeder mit jedem kommunizieren.
Wenn z.B. du keinen Traffic von VLAN 10 ins VLAN 30 erlauben willst, dann musst du eine Firewall Regel erstellen:
Source Adresse: VLAN 10 Netz, DENY/Verboten, Port: any, auf Zieladresse: VLAN 30 Netz, Port: any !
Achtung: Diese Regel MUSS immer zuerst in der Firewall Regel Reihenfolge stehen an dem Interface !!
Warum....???
Bei Firewall ACLs gilt immer grundsätzlich: "First Match wins !"
Hast du also z.B. eine Any zu Any Regel an erster Stelle und an 2ter Stelle deine Verbotsregel von oben, dann ist mit der ersten Regel alles erfüllt und weitere FW Regeln werden NICHT mehr abgearbeitet (First match wins !)
Deine Verbotsregel wird also immer ignoriert obwohl sie im Regelwerk steht...nur eben an falscher Stelle der Reihenfolge !!
Deshalb ist die Reihenfolge der Firewall Regeln so immens wichtig am Interface und du hast in den Regeln ganz rechts die Option die Regel zu verschieben !!
Die Reihenfolge zählt also ganz wichtig bei solchen Regeln !!
Verbotsregeln kommen so also logischerweise immer an den Anfang des Regelwerks auf dem Interface !!
Es gelten also 2 Kardinals Grundsätze bei den Regeln:
1.) Regeln werden nur eingehend abgearbeitet !
2.) Die Reihenfolge zählt (First match wins Prinzip !)
Wenn du das genau beachtest dann funktionieren die Einschränkungen auch absolut sauber und zuverlässig !!
Hallo Aqui,
danke für deine Erneute Antwort.
Zu 1.: Ja das war alles so richtig verstanden. Nur kann ich dir zum Ende hin nicht mehr ganz folgen. Du sagst das PC VLAN muss an der Firewall anliegen, meinst du damit einen weiteren LAN Anschluss an der Mono? Momentan hab ich es so eingerichtet und denke das dies so funktioniert:
Port 24 = Accesspoint = VLAN 20
Port 12 = VLAN 30 "Accessport"
Reicht das zur logischen Trennung? Die Aussage "Das PC VLAN muss aber an der Firewall anliegen" irritiert mich da leicht.
Und zu Frage 2:
Das mit den Regeln ist mir klar, habe früher (viel früher ) diverse Astaro Firewalls aufgebaut und das Prinzip der Abarbeitung der Regeln ist ja immer gleich. Aber durch meine bisherige Erfahrung bin ich der Meinung, dass wenn ich von 192.168.10.255 auf 192.168.20.255 zugreifen möchte ich dies über ein NAT Regel muss.
Aber OK, ich hab natürlich nix dagegen so wie es ist, es ist super alles über die Firewallregeln lenken zu können, hier ein Beispiel meines Gastnetzwerks. Die Kinder testen gerade die Voucher, daher der Minecraft Port
Lediglich hab ich festgestellt, dass ich die Mono manchmal durchbooten muss, wenn ich Regeln lösche oder deaktiviere, das funktioniert leider nicht immer nur durch "Apply Changes"
danke für deine Erneute Antwort.
Zu 1.: Ja das war alles so richtig verstanden. Nur kann ich dir zum Ende hin nicht mehr ganz folgen. Du sagst das PC VLAN muss an der Firewall anliegen, meinst du damit einen weiteren LAN Anschluss an der Mono? Momentan hab ich es so eingerichtet und denke das dies so funktioniert:
Port 24 = Accesspoint = VLAN 20
Port 12 = VLAN 30 "Accessport"
Reicht das zur logischen Trennung? Die Aussage "Das PC VLAN muss aber an der Firewall anliegen" irritiert mich da leicht.
Und zu Frage 2:
Das mit den Regeln ist mir klar, habe früher (viel früher
) diverse Astaro Firewalls aufgebaut und das Prinzip der Abarbeitung der Regeln ist ja immer gleich. Aber durch meine bisherige Erfahrung bin ich der Meinung, dass wenn ich von 192.168.10.255 auf 192.168.20.255 zugreifen möchte ich dies über ein NAT Regel muss.Aber OK, ich hab natürlich nix dagegen so wie es ist, es ist super alles über die Firewallregeln lenken zu können, hier ein Beispiel meines Gastnetzwerks. Die Kinder testen gerade die Voucher, daher der Minecraft Port
Lediglich hab ich festgestellt, dass ich die Mono manchmal durchbooten muss, wenn ich Regeln lösche oder deaktiviere, das funktioniert leider nicht immer nur durch "Apply Changes"
Mit dem "PC VLAN" war lediglich dein "Notebook zum Konfig" Anschluss gemeint ! Also nur das LAN Segment was am "normalen" LAN Port der FW hängt und du hier nur einzig zur Konfiguration benutzt (so wie es aussieht). Das sollte in einem isolierten VLAN liegen und nicht im Defazlt VLAN 1.
Das war damit gemeint. Hast du aber vermutlich auch so gemacht und das ist dann richtig !!
Die Accesspoints werden nur dann tagged angeschlossen wenn sie ESSIDs supporten also mehrere virtuelle SSIDs pro AP die sie dann auf bestimmte VLANs mappen können. Nur dann muss der AP tagged nageschlossen werden. Benutzt du einzelne dumme APs die nur eine simple SSID können werden die natürlich untagged als Accesport angeschlossen. Hast du aber vermutlich auch richtig gemacht.
Frage 2:
"...bin ich der Meinung, dass wenn ich von 192.168.10.255 auf 192.168.20.255 zugreifen möchte ich dies über ein NAT Regel muss. "
Nein, das ist schlicht falsch und technisch nicht richtig !!
Mit NAT hat das nichts zu dun denn zwischen den lokalen Interfaces macht die FW kein NAT !!
NAT wird einzig und allein NUR auf dem WAN Port gemacht sonst nirgendwo !
Zwischen den lokalen Interfaces und VLAN Interface routet die FW ganz normal transparent OHNE NAT. Das kannst du mit einem Sniffer wie dem Wireshark auch sofort selber sehen !
Tipp:
Verwende mal statt der Monowall dessen Schwester pfSense !
http://www.pfsense.org/index.php?option=com_content&task=view&i ...
Sie rennt nach m. Erfahrung etwas stabiler wird besser gepflegt und hat diese Reboot Probleme de facto nicht !
Falls du ein ALIX Board benutzt:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Das war damit gemeint. Hast du aber vermutlich auch so gemacht und das ist dann richtig !!
Die Accesspoints werden nur dann tagged angeschlossen wenn sie ESSIDs supporten also mehrere virtuelle SSIDs pro AP die sie dann auf bestimmte VLANs mappen können. Nur dann muss der AP tagged nageschlossen werden. Benutzt du einzelne dumme APs die nur eine simple SSID können werden die natürlich untagged als Accesport angeschlossen. Hast du aber vermutlich auch richtig gemacht.
Frage 2:
"...bin ich der Meinung, dass wenn ich von 192.168.10.255 auf 192.168.20.255 zugreifen möchte ich dies über ein NAT Regel muss. "
Nein, das ist schlicht falsch und technisch nicht richtig !!
Mit NAT hat das nichts zu dun denn zwischen den lokalen Interfaces macht die FW kein NAT !!
NAT wird einzig und allein NUR auf dem WAN Port gemacht sonst nirgendwo !
Zwischen den lokalen Interfaces und VLAN Interface routet die FW ganz normal transparent OHNE NAT. Das kannst du mit einem Sniffer wie dem Wireshark auch sofort selber sehen !
Tipp:
Verwende mal statt der Monowall dessen Schwester pfSense !
http://www.pfsense.org/index.php?option=com_content&task=view&i ...
Sie rennt nach m. Erfahrung etwas stabiler wird besser gepflegt und hat diese Reboot Probleme de facto nicht !
Falls du ein ALIX Board benutzt:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
