26
Getrennte WLAN Zugänge für Gäste und Mitarbeiter (WLAN-AP, VLAN-Switch, monowall)
Obwohl ich hier bereits sehr gute Beiträge zum Thema gefunden habe, will es doch nicht so richtig hinhauen mit der Lösung.
Dazu kommt noch die Tatsache, dass in meinem Fall die Gäste nicht nur Internetzugriff erhalten sollen, sondern auch Zugriff auf ein lokales Training/Schulungsnetz.
Gewünscht:
"drahtlose" Mitarbeiter verbinden sich über SSID1, werden über RADIUS authentifiziert und haben Zugriff auf alle Netze (Produktiv, Traning, Internet)
"drahtlose" Gäste verbinden sich über SSID2, landen auf die Captive Portal Webseite und haben nach Eingabe eines gültigen Vouchercode Zugriff auf das Tranings-LAN und das Internet
Folgende Netze sind vorhanden:
-Produktiv Netz für Mitarbeiter
-Trainig Netz für Training/Schulung
Beide Netze getrennt/gekoppelt durch eine Firewall/Router, der die Verbindung zum Internet über ein DSL Modem zur Verfügung stellt.
Folgende Hardware ist vorhanden:
Wireless Access Point, Konfiguration:
SSID1 mit VLAN10 für Mitarbeiter
SSID2 mit VLAN11 für Gäste
(das mapping SSID-VLAN übernimmt das Gerät selbstständig)
VLAN Switch, Konfiguration:
Port2 (als Trunk deklariert, mit VLAN10 und 11 getagged) verbunden mit dem Access Point
Port8 (als Trunk deklariert, mit VLAN10 und 11 getagged) verbunden mit einem der physikalischen Interfaces des Servers
Server: ESX Server mit 4 virtuellen interfaces (lnc0-ln3), die monowall läuft als VMware Appliance
Ich habe zuvor in einer vereinfachten WLAN Testumgebung (ohne VLAN, nur mit WAN und LAN interface, DHCP Server auf LAN Interface, DHCP Client auf WAN interface) die monowall samt Voucher Funktion erfolgreich getestet.
Jetzt habe ich aber auf der monowall zwei VLAN interfaces mit jeweils aktivierten DHCP Server eingerichtet.
Aber dort scheitert es schon. An die kommen die IP requests des drahtlosen Gast oder Mitarbeiter nicht an.
Die Firewall der monowall habe ich für Testzwecke komplett geöffnet.
Ich hänge noch zwei Grafiken an.
...und so sieht die Konfiguration der interfaces momentan aus:
<--LAN interface lnc0, mit statischer IP aus und für den Zugriff auf das Produktivnetz
<--TLAN interface lnc3, mit statischer IP aus und für den Zugriff auf das Trainingsnetz
<--WAN interface lnc1, mit statischer IP für den Zugriff auf das Internet
<-- Firmennetz <-- | monowall | --> switch --> access point --> drathlose Clients
-->WLAN interface lnc2 mit statischer IP, als parent interface für die interfaces VLAN10 und VLAN11
-->VLAN10 interface mit statischer IP und aktivierten DHCP Server
-->VLAN11 interface mit statischer IP und aktivierten DHCP Server
Jetzt stellt sich natürlich für mich auch die Frage, ob ich die interfaces so benutzen kann/darf, ich weiche ja damit vom ursprünglichen Konzept/Zweck der LAN und WAN interfaces.
Wo liegt ansonten Eurer Meinung nach der Fehler?
Kann mir jemand auch Tipps zu routing(monowall) und gateway(monowall, access point) Einträge geben?
Ich danke Euch im voraus für Eure Unterstützung!!!
"drahtlose" Mitarbeiter verbinden sich über SSID1, werden über RADIUS authentifiziert und haben Zugriff auf alle Netze (Produktiv, Traning, Internet)
"drahtlose" Gäste verbinden sich über SSID2, landen auf die Captive Portal Webseite und haben nach Eingabe eines gültigen Vouchercode Zugriff auf das Tranings-LAN und das Internet
Folgende Netze sind vorhanden:
-Produktiv Netz für Mitarbeiter
-Trainig Netz für Training/Schulung
Beide Netze getrennt/gekoppelt durch eine Firewall/Router, der die Verbindung zum Internet über ein DSL Modem zur Verfügung stellt.
Folgende Hardware ist vorhanden:
Wireless Access Point, Konfiguration:
SSID1 mit VLAN10 für Mitarbeiter
SSID2 mit VLAN11 für Gäste
(das mapping SSID-VLAN übernimmt das Gerät selbstständig)
VLAN Switch, Konfiguration:
Port2 (als Trunk deklariert, mit VLAN10 und 11 getagged) verbunden mit dem Access Point
Port8 (als Trunk deklariert, mit VLAN10 und 11 getagged) verbunden mit einem der physikalischen Interfaces des Servers
Server: ESX Server mit 4 virtuellen interfaces (lnc0-ln3), die monowall läuft als VMware Appliance
Ich habe zuvor in einer vereinfachten WLAN Testumgebung (ohne VLAN, nur mit WAN und LAN interface, DHCP Server auf LAN Interface, DHCP Client auf WAN interface) die monowall samt Voucher Funktion erfolgreich getestet.
Jetzt habe ich aber auf der monowall zwei VLAN interfaces mit jeweils aktivierten DHCP Server eingerichtet.
Aber dort scheitert es schon. An die kommen die IP requests des drahtlosen Gast oder Mitarbeiter nicht an.
Die Firewall der monowall habe ich für Testzwecke komplett geöffnet.
Ich hänge noch zwei Grafiken an.
...und so sieht die Konfiguration der interfaces momentan aus:
<--LAN interface lnc0, mit statischer IP aus und für den Zugriff auf das Produktivnetz
<--TLAN interface lnc3, mit statischer IP aus und für den Zugriff auf das Trainingsnetz
<--WAN interface lnc1, mit statischer IP für den Zugriff auf das Internet
<-- Firmennetz <-- | monowall | --> switch --> access point --> drathlose Clients
-->WLAN interface lnc2 mit statischer IP, als parent interface für die interfaces VLAN10 und VLAN11
-->VLAN10 interface mit statischer IP und aktivierten DHCP Server
-->VLAN11 interface mit statischer IP und aktivierten DHCP Server
Jetzt stellt sich natürlich für mich auch die Frage, ob ich die interfaces so benutzen kann/darf, ich weiche ja damit vom ursprünglichen Konzept/Zweck der LAN und WAN interfaces.
Wo liegt ansonten Eurer Meinung nach der Fehler?
Kann mir jemand auch Tipps zu routing(monowall) und gateway(monowall, access point) Einträge geben?
Ich danke Euch im voraus für Eure Unterstützung!!!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 159369
Url: https://administrator.de/contentid/159369
Printed on: April 24, 2024 at 12:04 o'clock
26 Comments
Latest comment
Nur einmal vorab gefragt und bevor wir ins Eingemachte gehen:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Hast du dir detailiert und vollständig durchgelesen ??
Danach funktioniert sowas in der Regel auf Anhieb !! Wenn man denn wirklich alles genau liest und befolgt bei der Einrichtung !!
Nur soviel vorab: Deine Konfig bzw. das was du an rudimentären Infos oben uns hier zur Verfügung stellst sieht in der Basis Konfig soweit erstmal richtig aus ! Und JA natürlich kannst du die Interfaces so benutzen...warum sollte das nicht gehen !!
Bedenke das alle neuen Interfaces und das beinhaltet auch VLAN Interfaces immer vollständig gesperrt sind !!!
Die Monowall ist eine Firewall und da ist sowas üblich.
Du musst also IMMER erst vorher mit einer FW Regel auf dem entsprechenden Interfae den Zugang eröffnen !!
Das ist auch genauso im Tutorial beschrieben !! Siehe:
"Um aufkommenden Frust erst einmal kleinzuhalten kann man eine einfache "Scheunentor" Regel aufsetzten, die erstmal alles erlaubt...."
und die Infos die dort stehen !!
Nochwas zu den VLAN Interfaces: Das Parent Interface landet immer untagged am Switch entspricht also bei der Masse der VLAN Switches dem VLAN 1, das auch immer untagged per Definition am tagged Port anliegt.
Deine VLANs 10 und 11 dürfen also nicht auf einem Parent Interface liegen und auch nicht zum Default VLAN des Switches gehören sondern dedizierte VLANs sein. S
So wie du es oben beschreibst scheint das aber bei dir der Fall zu sein...nur nochmal als Hinweis !
Nochwas: Stelle sicher das deine Interfaces (Man sieht an den Macs das du alles in einer VM nutzt !!) sicher mit tagged Frames nach 802.1q umgehen können sonst scheiterst du schon daran.
Ggf. macht ein vorab Test mit physischer HW erstmal Sinn um nicht über Probleme zu stolpern die allein VM bedingt sind !!
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Hast du dir detailiert und vollständig durchgelesen ??
Danach funktioniert sowas in der Regel auf Anhieb !! Wenn man denn wirklich alles genau liest und befolgt bei der Einrichtung !!
Nur soviel vorab: Deine Konfig bzw. das was du an rudimentären Infos oben uns hier zur Verfügung stellst sieht in der Basis Konfig soweit erstmal richtig aus ! Und JA natürlich kannst du die Interfaces so benutzen...warum sollte das nicht gehen !!
Bedenke das alle neuen Interfaces und das beinhaltet auch VLAN Interfaces immer vollständig gesperrt sind !!!
Die Monowall ist eine Firewall und da ist sowas üblich.
Du musst also IMMER erst vorher mit einer FW Regel auf dem entsprechenden Interfae den Zugang eröffnen !!
Das ist auch genauso im Tutorial beschrieben !! Siehe:
"Um aufkommenden Frust erst einmal kleinzuhalten kann man eine einfache "Scheunentor" Regel aufsetzten, die erstmal alles erlaubt...."
und die Infos die dort stehen !!
Nochwas zu den VLAN Interfaces: Das Parent Interface landet immer untagged am Switch entspricht also bei der Masse der VLAN Switches dem VLAN 1, das auch immer untagged per Definition am tagged Port anliegt.
Deine VLANs 10 und 11 dürfen also nicht auf einem Parent Interface liegen und auch nicht zum Default VLAN des Switches gehören sondern dedizierte VLANs sein. S
So wie du es oben beschreibst scheint das aber bei dir der Fall zu sein...nur nochmal als Hinweis !
Nochwas: Stelle sicher das deine Interfaces (Man sieht an den Macs das du alles in einer VM nutzt !!) sicher mit tagged Frames nach 802.1q umgehen können sonst scheiterst du schon daran.
Ggf. macht ein vorab Test mit physischer HW erstmal Sinn um nicht über Probleme zu stolpern die allein VM bedingt sind !!
Hallo aqui,
vielen Dank für deine Antwort!
Ja, Tutorial habe ich durchgelesen (echt Klasse), nur deswegen bin ich überhaupt "soweit" gekommen.
Ich hatte bereits für alle monowall interfaces die "Scheunentor" Regel aufgesetzt.
Der letzte Punkt mit den VLANs macht mich etwas zu schaffen....
Tatsache ist, die NIC des ESX Servers (auf dem die monowall läuft) hat nur einen Port frei (der andere geht zur Firewall\Router Appliance). Über diesen einen freien Port wird sie per LAN-Kabel mit dem CISCO VLAN Switch verbunden.
Ich "täusche" also mit Hilfe von vmware der monowall 4 Netzwerkports für seine interfaces lnc0 bis lnc4 vor.
Interface lnc2 habe ich WLAN genannt und darauf VLAN10 on lnc2 und VLAN11 on lnc2 deklariert.
Deswegen nenne ich lnc2 ein "parent interface".
Laut Konfiguration des Switches wird:
VLAN10: tagged für Port 2 und 8
VLAN11: ebenfalls tagged für Port 2 und 8
VLAN1: untagged für alle Ports
Somit werden über Port 2 (zum AP) und Port 8 (zur monowall) des Switches die VLANs 1, 10 und 11 transportiert.
So gesehen, was ist damit gemieint "das parent interface soll untagged auf dem switch landen"?
Und wo sollen sonst die VLANS 10 und 11 liegen? Ein parent interface muss ich in der monowall ja nehmen.
vielen Dank für deine Antwort!
Ja, Tutorial habe ich durchgelesen (echt Klasse), nur deswegen bin ich überhaupt "soweit" gekommen.
Ich hatte bereits für alle monowall interfaces die "Scheunentor" Regel aufgesetzt.
Der letzte Punkt mit den VLANs macht mich etwas zu schaffen....
Tatsache ist, die NIC des ESX Servers (auf dem die monowall läuft) hat nur einen Port frei (der andere geht zur Firewall\Router Appliance). Über diesen einen freien Port wird sie per LAN-Kabel mit dem CISCO VLAN Switch verbunden.
Ich "täusche" also mit Hilfe von vmware der monowall 4 Netzwerkports für seine interfaces lnc0 bis lnc4 vor.
Interface lnc2 habe ich WLAN genannt und darauf VLAN10 on lnc2 und VLAN11 on lnc2 deklariert.
Deswegen nenne ich lnc2 ein "parent interface".
Laut Konfiguration des Switches wird:
VLAN10: tagged für Port 2 und 8
VLAN11: ebenfalls tagged für Port 2 und 8
VLAN1: untagged für alle Ports
Somit werden über Port 2 (zum AP) und Port 8 (zur monowall) des Switches die VLANs 1, 10 und 11 transportiert.
So gesehen, was ist damit gemieint "das parent interface soll untagged auf dem switch landen"?
Und wo sollen sonst die VLANS 10 und 11 liegen? Ein parent interface muss ich in der monowall ja nehmen.
ja, der vmware esx server kann mit tagged frames umgehen
OK, technisch ist dagegen nichts zu sagen. Wenn die Hardware mit tagging umgehen kann sollte das kein Thema sein mit dem lnc2 Interface und es ist natürlich auch ein Parent Interface für die VLAN 10 und 11 Interface...da liegst du absolut korrekt !
Du solltest also erstmal strategisch Schritt für Schritt vorgehen um diese Konfig zu testen:
Angenommen das sind die IPs 10.1.1.254 /24 (Parent), 10.1.10.254 /24 (VLAN-10) , 10.1.11.254 /24 (VLAN-11)
Nun hängst du den Cisco Switch mit folgender Port Konfig an den lnc2 Port: (VLANs 10 und 11 natürlich eingerichtet !)
interface FastEthernet0/1
description Tagged Link zur M0n0wall, Port lnc2
spanning-tree portfast
switchport mode trunk
switchport trunk encapsulation dot1q
!
interface FastEthernet0/10
description Enduser Ports in VLAN 10
switchport access vlan 10
spanning-tree portfast
!
interface FastEthernet0/11
description Enduser Ports in VLAN 11
switchport access vlan 11
spanning-tree portfast
!
interface FastEthernet0/12
description Enduser Ports im Default VLAN
switchport access vlan 1
spanning-tree portfast
!
Ist das geschehen steckst du jetzt nacheinander einen Laptop am besten mit laufendem Wireshark und statisch eingestellter IP 10.1.1.1 /24 erstmal in den Switch Port 12 im Default VLAN.
Dann versuchst du die Monowall anzupingen (10.1.1.254)
Klappt das Laptop und statisch eingestellter IP 10.1.10.1 /24 in den Switch Port 10 im VLAN-10...gleiche Prozedur mit Ping
Analog mit VLAN 11 und 10.1.11.1
Um ganz sicher zu gehen solltest du den Ping Test zusätzlich über die Monowall Management Web Konsole auch in die andere Richtung auf den angeschlossenen Laptop ausführen !! (ICMP erlauben in der lokalen Laptop Firewall)
Wenn das alles klappt, dann kannst du dir erstmal sicher sein das die Erreichbarkeit der Monowall sauber funktioniert.
Im nächsten Schritt aktivierst du dann die DHCP Server auf der Monowall in beiden VLANs und wiederholst den Test mit dem Laptop und dynmaischer IP Vergabe.
Solltest du einen L3 fähigen Cisco Switch haben richte einfach in allen VLANs 1, 10 und 11 ein vlan interface ein und vergebe die statischen IP Adressen dort.
Dann kannst du direkt vom Switch bzw. dessen Konsole zur Monowall pingen und der Test ist direkter ohne Laptop.
Erst wenn das alles klappt, dann kommt das eigentliche Finetuning mit den Accesslisten, Captive Portal usw.
Du musst aber zuallererst sicherstellen das die IP Connectivity sauber funktioniert.
Du solltest also erstmal strategisch Schritt für Schritt vorgehen um diese Konfig zu testen:
- Testweise statische IP auf dem Parent Interface lnc2 direkt (nur für den Testaufbau !)
- statische IPs auf den Monowall Interfaces VLAN 10 und VLAN 11, ok wirst du eh schon gemacht haben
- Auf allen 3 Interfaces die "Scheunentor" FW Regel und erstmal alles erlauben.
Angenommen das sind die IPs 10.1.1.254 /24 (Parent), 10.1.10.254 /24 (VLAN-10) , 10.1.11.254 /24 (VLAN-11)
Nun hängst du den Cisco Switch mit folgender Port Konfig an den lnc2 Port: (VLANs 10 und 11 natürlich eingerichtet !)
interface FastEthernet0/1
description Tagged Link zur M0n0wall, Port lnc2
spanning-tree portfast
switchport mode trunk
switchport trunk encapsulation dot1q
!
interface FastEthernet0/10
description Enduser Ports in VLAN 10
switchport access vlan 10
spanning-tree portfast
!
interface FastEthernet0/11
description Enduser Ports in VLAN 11
switchport access vlan 11
spanning-tree portfast
!
interface FastEthernet0/12
description Enduser Ports im Default VLAN
switchport access vlan 1
spanning-tree portfast
!
Ist das geschehen steckst du jetzt nacheinander einen Laptop am besten mit laufendem Wireshark und statisch eingestellter IP 10.1.1.1 /24 erstmal in den Switch Port 12 im Default VLAN.
Dann versuchst du die Monowall anzupingen (10.1.1.254)
Klappt das Laptop und statisch eingestellter IP 10.1.10.1 /24 in den Switch Port 10 im VLAN-10...gleiche Prozedur mit Ping
Analog mit VLAN 11 und 10.1.11.1
Um ganz sicher zu gehen solltest du den Ping Test zusätzlich über die Monowall Management Web Konsole auch in die andere Richtung auf den angeschlossenen Laptop ausführen !! (ICMP erlauben in der lokalen Laptop Firewall)
Wenn das alles klappt, dann kannst du dir erstmal sicher sein das die Erreichbarkeit der Monowall sauber funktioniert.
Im nächsten Schritt aktivierst du dann die DHCP Server auf der Monowall in beiden VLANs und wiederholst den Test mit dem Laptop und dynmaischer IP Vergabe.
Solltest du einen L3 fähigen Cisco Switch haben richte einfach in allen VLANs 1, 10 und 11 ein vlan interface ein und vergebe die statischen IP Adressen dort.
Dann kannst du direkt vom Switch bzw. dessen Konsole zur Monowall pingen und der Test ist direkter ohne Laptop.
Erst wenn das alles klappt, dann kommt das eigentliche Finetuning mit den Accesslisten, Captive Portal usw.
Du musst aber zuallererst sicherstellen das die IP Connectivity sauber funktioniert.
vielen Dank, werde ich morgen früh bei der Arbeit testen und dann melde ich mich wieder
Ergänzung zur Hardware:
Cisco Switch SRW2016 (soweit ich recherchieren konnte, L3 fähig)
Cisco Access Point WAP4410N
Cisco Switch SRW2016 (soweit ich recherchieren konnte, L3 fähig)
Cisco Access Point WAP4410N
OK, das ist kein IOS basierender Switch und auch kein L3 Switch (L2 only siehe Datenblatt !) aber das ist kein Nachteil. Das Routing soll ja auch die Monowall machen und eben nicht der Switch. Der AP ist ja eh unkritisch in deinem Design !
Das VLAN Setup des Switches und die Port Zuweisungen musst du dann über das Web Interface machen ! Siehe Kapitel 5:
http://www.cisco.com/en/US/docs/switches/lan/csbms/srw2048/administrati ...
Wichtig ist das du das VLAN Setup des Switches absolut wasserdicht testest vorher ! Wenn du hier einen Fehler machst, dann funktioniert auch der Rest nicht.
Um den tagged Link der nachher zur Monowall geht vorab zu testen hilft dir ggf. ein PC mit einer Netzwerkkarte die tagging fähig ist wie z.B. Intel:
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
Damit kannst du die Switchkonfig wasserdicht testen.
Du musst dich auf die Switchkonfig verlassen können sonst suchst du dir ggf. bei den anderen Fehlermöglichkeiten einen Wolf !
Das VLAN Setup des Switches und die Port Zuweisungen musst du dann über das Web Interface machen ! Siehe Kapitel 5:
http://www.cisco.com/en/US/docs/switches/lan/csbms/srw2048/administrati ...
Wichtig ist das du das VLAN Setup des Switches absolut wasserdicht testest vorher ! Wenn du hier einen Fehler machst, dann funktioniert auch der Rest nicht.
Um den tagged Link der nachher zur Monowall geht vorab zu testen hilft dir ggf. ein PC mit einer Netzwerkkarte die tagging fähig ist wie z.B. Intel:
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
Damit kannst du die Switchkonfig wasserdicht testen.
Du musst dich auf die Switchkonfig verlassen können sonst suchst du dir ggf. bei den anderen Fehlermöglichkeiten einen Wolf !
So, die VLAN und Switchkonfiguration ist jetzt sauber gelaufen!
Ich hatte ein durcheinander bei der Zuordnung der physikalischen und virtuellen interfaces erzeugt.
Ich werde das Thema vmware sobald ich Zeit habe hier noch ausarbeiten.
Aktueller Stand:
Das Laptop kriegt nun abhängig von der gewählten SSID eine IP Adresse (für VLAN10 eine aus dem 192.168.110.0 und für VLAN11 eine aus dem 192.168.111.0 Netz).
AP arbeitet also auch sauber (mapping SSID-VLAN).
VLAN10 ermöglicht den Zugriff ins interne Netz, Internet und Schulungsnetz, VLAN 11 ins Schulungsnetz und Internet.
Jetzt hatte ich das Captive Portal auf dem VLAN11 interface der monowall aktiviert (darüber sollen ja die Besucher sich anmelden können), der blockiert mir aber dort den kompletten Verkehr...
Ich kriege zwar eine IP aus dem 192.168.111.0 Netz, kann aber nichtmal das zuständige VLAN11 interface (Gateway) der monowall anpingen...?
Auf welchem interface soll sonst das captive Portal aktiviert sein?
Es gilt:
-->WLAN lnc1 interface mit statischer IP, als parent interface für die interfaces VLAN10 und VLAN11
-->VLAN10 opt3 interface mit statischer IP und aktivierten DHCP Server
-->VLAN11 opt4 interface mit statischer IP und aktivierten DHCP Server
Ergänzung:
Meine Vermutung:
In den Captive Portal Einstellungen habe ich die Option "local user manager" eingestellt und einen test Benutzer angelegt, damit sich keiner durch einfaches klicken auf den Anmelde-Button sozusagen "voucherlos" anmeldet.
Vouchers für den Internetzugriff habe ich erzeugt und funktionieren auch.
D.h aber, das VLAN11 interface lässt jeglichen Verkehr nur nach Voucher oder User Authentifizierung zu und ich verriegle mit dieser Einstellung jeden nicht authentifizierten Verkehr, also auch ein einfaches ping über die Kommandozeile?
2. Ergänzung
Vermutung bestätigt
Tippe ich im Browser die IP des Gateways, also des VLAN11 interfaces, öffnet sich die login Seite des captive portal.
Gebe ich dort einen gültigen voucher ein, komme ich an die Konfigurationsseite der monowall.
"Tür" geöffnet, dann funktioniert auch das pingen aus der Kommandozeile...
(Username=vouchercode)
Wie kriege ich es hin, dass nur das pingen über das Interface mit aktivierten Captive Portal ohne Benutzer oder Voucherauthentifizierung durchgelassen wird?
Wie unterbinde ich den Zugriff auf die monowall Konfigurationsseite aus dem VLAN11 (Gästezugang)?
Ich hatte ein durcheinander bei der Zuordnung der physikalischen und virtuellen interfaces erzeugt.
Ich werde das Thema vmware sobald ich Zeit habe hier noch ausarbeiten.
Aktueller Stand:
Das Laptop kriegt nun abhängig von der gewählten SSID eine IP Adresse (für VLAN10 eine aus dem 192.168.110.0 und für VLAN11 eine aus dem 192.168.111.0 Netz).
AP arbeitet also auch sauber (mapping SSID-VLAN).
VLAN10 ermöglicht den Zugriff ins interne Netz, Internet und Schulungsnetz, VLAN 11 ins Schulungsnetz und Internet.
Jetzt hatte ich das Captive Portal auf dem VLAN11 interface der monowall aktiviert (darüber sollen ja die Besucher sich anmelden können), der blockiert mir aber dort den kompletten Verkehr...
Ich kriege zwar eine IP aus dem 192.168.111.0 Netz, kann aber nichtmal das zuständige VLAN11 interface (Gateway) der monowall anpingen...?
Auf welchem interface soll sonst das captive Portal aktiviert sein?
Es gilt:
-->WLAN lnc1 interface mit statischer IP, als parent interface für die interfaces VLAN10 und VLAN11
-->VLAN10 opt3 interface mit statischer IP und aktivierten DHCP Server
-->VLAN11 opt4 interface mit statischer IP und aktivierten DHCP Server
Ergänzung:
Meine Vermutung:
In den Captive Portal Einstellungen habe ich die Option "local user manager" eingestellt und einen test Benutzer angelegt, damit sich keiner durch einfaches klicken auf den Anmelde-Button sozusagen "voucherlos" anmeldet.
Vouchers für den Internetzugriff habe ich erzeugt und funktionieren auch.
D.h aber, das VLAN11 interface lässt jeglichen Verkehr nur nach Voucher oder User Authentifizierung zu und ich verriegle mit dieser Einstellung jeden nicht authentifizierten Verkehr, also auch ein einfaches ping über die Kommandozeile?
2. Ergänzung
Vermutung bestätigt
Tippe ich im Browser die IP des Gateways, also des VLAN11 interfaces, öffnet sich die login Seite des captive portal.
Gebe ich dort einen gültigen voucher ein, komme ich an die Konfigurationsseite der monowall.
"Tür" geöffnet, dann funktioniert auch das pingen aus der Kommandozeile...
(Username=vouchercode)
Wie kriege ich es hin, dass nur das pingen über das Interface mit aktivierten Captive Portal ohne Benutzer oder Voucherauthentifizierung durchgelassen wird?
Wie unterbinde ich den Zugriff auf die monowall Konfigurationsseite aus dem VLAN11 (Gästezugang)?
"kann aber nichtmal das zuständige VLAN11 interface (Gateway) der monowall anpingen...? "
Das ist klar, denn das CP lässt erst Traffic passieren wenn der User sich korrekt authentifiziert hat am CP !
"...das VLAN11 interface lässt jeglichen Verkehr nur nach Voucher oder User Authentifizierung zu "
Aaaha... du hast es also erkannt. Eine entsprechende Firewall Regel auf diesem Interface schränkt den Verkehr dann wieder wieder so ein wie DU es haben willst. Z. B eine Regel die nur TCP 80, DNS Port 53 und den CP Port durchlässt erlaubt Usern am CP eben nur surfen und sonst nix !
..."Wie kriege ich es hin, dass nur das pingen über das Interface mit aktivierten Captive Portal ohne Benutzer oder Voucherauthentifizierung durchgelassen wird?"
Du kannst eine sog "Pass Through" Regel auf Basis der User IP oder der Mac Adresse im CP definieren. Diese IP darf dann passieren ohne CP. Das kann z.B. eine statische IP sein.
Besser ist es aber im DHCP Server der Monowall eine feste IP Reservierung einzustellen auf Basis deiner Mac Adresse und diese IP dann mit einer Pass Through Regel zu belegen.
Damit bekommst du als Admin im CP Segment immer freie Fahrt.
Um den Zugriff auf die Konfig zu regeln kannst du entweder den Webzugriff im Setup auf HTTPS und z.B. 54443 einstellen. Das bekommt so schnell keine User hin. Mit https:<monowall_ip> :54443 kannst du dann passwortgeschützt zugreifen.
Eine etwas elegantere Alternative beschreibt der Forum User tikayevent im Captive Portal Tutorial:
WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion)
Das ist klar, denn das CP lässt erst Traffic passieren wenn der User sich korrekt authentifiziert hat am CP !
"...das VLAN11 interface lässt jeglichen Verkehr nur nach Voucher oder User Authentifizierung zu "
Aaaha... du hast es also erkannt. Eine entsprechende Firewall Regel auf diesem Interface schränkt den Verkehr dann wieder wieder so ein wie DU es haben willst. Z. B eine Regel die nur TCP 80, DNS Port 53 und den CP Port durchlässt erlaubt Usern am CP eben nur surfen und sonst nix !
..."Wie kriege ich es hin, dass nur das pingen über das Interface mit aktivierten Captive Portal ohne Benutzer oder Voucherauthentifizierung durchgelassen wird?"
Du kannst eine sog "Pass Through" Regel auf Basis der User IP oder der Mac Adresse im CP definieren. Diese IP darf dann passieren ohne CP. Das kann z.B. eine statische IP sein.
Besser ist es aber im DHCP Server der Monowall eine feste IP Reservierung einzustellen auf Basis deiner Mac Adresse und diese IP dann mit einer Pass Through Regel zu belegen.
Damit bekommst du als Admin im CP Segment immer freie Fahrt.
Um den Zugriff auf die Konfig zu regeln kannst du entweder den Webzugriff im Setup auf HTTPS und z.B. 54443 einstellen. Das bekommt so schnell keine User hin. Mit https:<monowall_ip> :54443 kannst du dann passwortgeschützt zugreifen.
Eine etwas elegantere Alternative beschreibt der Forum User tikayevent im Captive Portal Tutorial:
WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion)
ok, danke
(Services: Captive portal: Pass-through MAC)
ich werde erstmal die PassThrough regel für den CP nutzen, es geht natürlich besser aber muss nicht jetzt sein.
(System: General Setup \ webGUI protocol)
Der HTTPS Zugriff auf die Konfig klingt gut.
Ist es aber sichergestellt dass ich über "https:<monowall_ip> :54443" mich auch weiterhin an die Konfig der monowall anmelden kann? nicht dass ich mich aussperre....
Kann man zu Testzwecke nicht htttp und parallel dazu https einschalten?
(Services: Captive portal: Pass-through MAC)
ich werde erstmal die PassThrough regel für den CP nutzen, es geht natürlich besser aber muss nicht jetzt sein.
(System: General Setup \ webGUI protocol)
Der HTTPS Zugriff auf die Konfig klingt gut.
Ist es aber sichergestellt dass ich über "https:<monowall_ip> :54443" mich auch weiterhin an die Konfig der monowall anmelden kann? nicht dass ich mich aussperre....
Kann man zu Testzwecke nicht htttp und parallel dazu https einschalten?
ich setze mich momentan ein wenig mit NAT aus....
mein Ziel ist es, von diversen Testrechnern mit 173er Netz-IP Adresse auf das Webinterface des Access Point zuzugreifen, der hat eine 195er Netz-IP Adresse...ohne dabei statische routen an jedem Rechner eintragen zu müssen
hatte dazu in der monowall unter Firewall: NAT: 1:1 folgendes eingetragen:
Interface External IP Internal IP
TestLAN 173.x.x.1/32 195.x.x.x/32
Das TestLAN Interface hat eine statische 173er Adresse
Die IP 173.x.x.1, die ich unter External IP eintrage, ist noch frei
Unter Internal IP gebe ich die IP des Access Point.
Das haut aber nicht hin...
Ich möchte im Browser die IP 173.x.x.1 angeben und auf das Webinterface des Access Points landen. Geht das so?
Es gilt weiterhin die Scheunentor Regel für die Firewall.
mein Ziel ist es, von diversen Testrechnern mit 173er Netz-IP Adresse auf das Webinterface des Access Point zuzugreifen, der hat eine 195er Netz-IP Adresse...ohne dabei statische routen an jedem Rechner eintragen zu müssen
hatte dazu in der monowall unter Firewall: NAT: 1:1 folgendes eingetragen:
Interface External IP Internal IP
TestLAN 173.x.x.1/32 195.x.x.x/32
Das TestLAN Interface hat eine statische 173er Adresse
Die IP 173.x.x.1, die ich unter External IP eintrage, ist noch frei
Unter Internal IP gebe ich die IP des Access Point.
Das haut aber nicht hin...
Ich möchte im Browser die IP 173.x.x.1 angeben und auf das Webinterface des Access Points landen. Geht das so?
Es gilt weiterhin die Scheunentor Regel für die Firewall.
Nein, da kann Monowall so nicht mit umgehen wenn du freie IP nimmst im Segment, da sie auf ARPs an diese IP nicht antwortet. Sie "weiss" ja nicht das sie damit als Host gemeint ist und müsste mit einem ARP Reply antworten.
Du musst die Monowall TestLAN IP Adresse selber nehmen mit dem Port TCP 80 auf die AP IP NATen...das klappt fehlerfrei.
Warum 173er IP Adressen ?? Das sind keine freien IPs sondern fest auf US Carrier registriert !!??
Oder hast du jetzt nur einen Dreckfuhler gemacht und meintest 172.??:
http://de.wikipedia.org/wiki/Private_IP-Adresse
Zu deiner Konfig Frage: "...Ist es aber sichergestellt dass ich über "https:<monowall_ip> :54443" mich auch weiterhin an die Konfig der monowall anmelden kann? "
Ja natürlich, denn damit schaltest du nur simpel und banal den Port um ! Über das LAN Interface kommst du ja imme ran, denn das hat per Default eine *.* "Scheunentor" Regel.
Bei den anderen Ports musst du dann natürlich darauf achten das due HTTP TCP Port 54443 freigeschaltet hast oder generell für deine Konfig IP Adresse alles !
IP Adresse macht aber natürlich nur Sinn wenn du immer mit einer festen IP arebeitest.
Falls alle Stricke reissen kannst du immer noch die Monowall über die Konsole resetten und eine feste sicher Konfig wieder einspielen !
Ganz aussperren kann man sich niemals, das ist Unsinn !
Du musst die Monowall TestLAN IP Adresse selber nehmen mit dem Port TCP 80 auf die AP IP NATen...das klappt fehlerfrei.
Warum 173er IP Adressen ?? Das sind keine freien IPs sondern fest auf US Carrier registriert !!??
Oder hast du jetzt nur einen Dreckfuhler gemacht und meintest 172.??:
http://de.wikipedia.org/wiki/Private_IP-Adresse
Zu deiner Konfig Frage: "...Ist es aber sichergestellt dass ich über "https:<monowall_ip> :54443" mich auch weiterhin an die Konfig der monowall anmelden kann? "
Ja natürlich, denn damit schaltest du nur simpel und banal den Port um ! Über das LAN Interface kommst du ja imme ran, denn das hat per Default eine *.* "Scheunentor" Regel.
Bei den anderen Ports musst du dann natürlich darauf achten das due HTTP TCP Port 54443 freigeschaltet hast oder generell für deine Konfig IP Adresse alles !
IP Adresse macht aber natürlich nur Sinn wenn du immer mit einer festen IP arebeitest.
Falls alle Stricke reissen kannst du immer noch die Monowall über die Konsole resetten und eine feste sicher Konfig wieder einspielen !
Ganz aussperren kann man sich niemals, das ist Unsinn !
ja, natürlich meinte ich eine 172er....sorry...
aber um es ein wenig komplizierter zu machen:
mein admin rechner und das LAN interface der monowall haben beide eine 10er IP aus dem gleichen Netz, die monowall konfiguriere ich also über diese 10er IP
wie kriege ich es jetzt über NAT an den AP mit der 192er IP zu kommen ohne statische routen unter windows einzutragen?
das LAN interface der monowall kann ich ja dafür nicht NATten...
die restlichen monowall interfaces habe alle IPs aus anderen Netzen (TLAN: 172, WAN:192,...)
aber um es ein wenig komplizierter zu machen:
mein admin rechner und das LAN interface der monowall haben beide eine 10er IP aus dem gleichen Netz, die monowall konfiguriere ich also über diese 10er IP
wie kriege ich es jetzt über NAT an den AP mit der 192er IP zu kommen ohne statische routen unter windows einzutragen?
das LAN interface der monowall kann ich ja dafür nicht NATten...
die restlichen monowall interfaces habe alle IPs aus anderen Netzen (TLAN: 172, WAN:192,...)
Nur mal ganz langsam...
Du willst aus dem LAN Interface mit 10er Netz ganz einfach auf ein WebGUI eines AP zugreifen der am WAN Port mit einer 192er Adresse hängt ??
Nichts einfacher als das:
Schalte in den General Settings das generelle Blocking der RFC 1918 IP Adressen unten aus (Haken entfernen) und fertig ist der Lack ! Das ist alles...
Wenn du das nicht machst dann werden alle Pakete aus RFC 1918 IP Netzen (Private IPs) an der FW WAN Port geblockt...damit auch deine AP Pakete
Du willst aus dem LAN Interface mit 10er Netz ganz einfach auf ein WebGUI eines AP zugreifen der am WAN Port mit einer 192er Adresse hängt ??
Nichts einfacher als das:
Schalte in den General Settings das generelle Blocking der RFC 1918 IP Adressen unten aus (Haken entfernen) und fertig ist der Lack ! Das ist alles...
Wenn du das nicht machst dann werden alle Pakete aus RFC 1918 IP Netzen (Private IPs) an der FW WAN Port geblockt...damit auch deine AP Pakete
Danke aqui, klappt soweit ganz gut bis hierhin.
Momentan kämpfe ich hiermit, es geht um den WLAN Zugriff für die Mitarbeiter mit RADIUS Authentifizierung :
-AP ist konfiguriert mit VLAN-SSID mapping
-monowall mit VLAN Interface und aktivierten DHCP Server auf diesen Interface
-MS RADIUS (IAS), IIS und Zertifikate eingerichtet.
-Client verbindet sich mit den AP über die Mitarbeiter SSID, die RADIUS Authentifizierungsanfrage des Client wird über den AP an den IAS Server gesendet, Authentifizierung mittels Benutzerdaten (Abgleich mit Active Directory) und Zertifikat erfolgreich (sehe ich im LOG des RADIUS Dienstes auf dem Server)...
mein zugelassener Client bekommt aber keine IP Adresse von der monowall zugewiesen....
Wenn ich in den Richtlinien des IAS Server eine feste IP Adresse für den Client vorgebe, dann klappt alles...ist aber nicht Sinn der Sache....
Die Vergabe der IPs soll ja dynamisch die monowall erledigen, dafür wurde ja auch das eine VLAN interface mit IP range eingerichtet...
Muss der Radius Server der monowall oder den AP irgendwie mitteilen, mein Client ist "Willkommen" und er soll eine IP bekommen?
Momentan kämpfe ich hiermit, es geht um den WLAN Zugriff für die Mitarbeiter mit RADIUS Authentifizierung :
-AP ist konfiguriert mit VLAN-SSID mapping
-monowall mit VLAN Interface und aktivierten DHCP Server auf diesen Interface
-MS RADIUS (IAS), IIS und Zertifikate eingerichtet.
-Client verbindet sich mit den AP über die Mitarbeiter SSID, die RADIUS Authentifizierungsanfrage des Client wird über den AP an den IAS Server gesendet, Authentifizierung mittels Benutzerdaten (Abgleich mit Active Directory) und Zertifikat erfolgreich (sehe ich im LOG des RADIUS Dienstes auf dem Server)...
mein zugelassener Client bekommt aber keine IP Adresse von der monowall zugewiesen....
Wenn ich in den Richtlinien des IAS Server eine feste IP Adresse für den Client vorgebe, dann klappt alles...ist aber nicht Sinn der Sache....
Die Vergabe der IPs soll ja dynamisch die monowall erledigen, dafür wurde ja auch das eine VLAN interface mit IP range eingerichtet...
Muss der Radius Server der monowall oder den AP irgendwie mitteilen, mein Client ist "Willkommen" und er soll eine IP bekommen?
Das entsprechende Tutorial dazu hast du gelesen: ???
Sichere 802.1x WLAN-Benutzer Authentisierung über Radius
Das Prozedere für dich ist analog, du musst dir nur statt Freeradius den IAS denken. Da steht eigentlich alles was zu beachten ist.
Ist damit das o.a. "Zugriffsproblem" auf die AP GUI erstmal erledigt ?
Sichere 802.1x WLAN-Benutzer Authentisierung über Radius
Das Prozedere für dich ist analog, du musst dir nur statt Freeradius den IAS denken. Da steht eigentlich alles was zu beachten ist.
Ist damit das o.a. "Zugriffsproblem" auf die AP GUI erstmal erledigt ?
das generelle Blocking der RFC 1918 IP Adressen war bereits deaktiviert, wir haben das Problem mit dem Zugriff auf die AP GUI in der Unternehmensfirewall durch geeignetes routing gelöst
das Prozedere des Tutorials habe ich beachtet, die IP Vergabe klappte zuvor für beide VLANs mit Netzwerksicherheit WPA2 PSK
Stand:
-VLAN11 für Gäste mit aktivierten captive portal, WPA2 PSK---> dynamische IP Vergabe durch monowall und Vouchergesteuerten Zugriff funktioniert
-VLAN10 für Mitarbeiter, kein captive portal, dafür aber mit IAS RADIUS Authentifizierung, RADIUS Server ist für diese SSID im AP eingetragen ---> dynamische IP Vergabe durch monowall funktioniert NICHT
das Problem mit der IP Vergabe besteht also nur für das WLAN, für das im AP die RADIUS Authentifizierung aktiviert wurde
Bemerkung:
Im WLAN Profil des Clients (mit Realtek Chip) habe ich WPA2 802.1x mit AES gewählt, im Cisco Access Point ebenfalls.
Stand:
-VLAN11 für Gäste mit aktivierten captive portal, WPA2 PSK---> dynamische IP Vergabe durch monowall und Vouchergesteuerten Zugriff funktioniert
-VLAN10 für Mitarbeiter, kein captive portal, dafür aber mit IAS RADIUS Authentifizierung, RADIUS Server ist für diese SSID im AP eingetragen ---> dynamische IP Vergabe durch monowall funktioniert NICHT
das Problem mit der IP Vergabe besteht also nur für das WLAN, für das im AP die RADIUS Authentifizierung aktiviert wurde
Bemerkung:
Im WLAN Profil des Clients (mit Realtek Chip) habe ich WPA2 802.1x mit AES gewählt, im Cisco Access Point ebenfalls.
so, nun habe ich das Ganze erstmal bezüglich Sicherheit etwas abgeschwächt und jetzt klappt es auch mit der IP Vergabe durch die monowall...
mit den Realtek WLAN Tool bin ich nicht weiter gekommen und habe mich auf das Windows WLAN Tool konzentriert
hier die Screenshots dazu:
Konfiguration des WLAN Profils über die Windows Eigenschaften von Drahtlosnetze
...und Anpassung des Sicherheitsmodus im AP (RADIUS Modus steht laut Hilfemenü des APs für WEP:
RADIUS mode utilizes RADIUS server for authentication and dynamic WEP key generation for data encryption. To utilize RADIUS mode, enter the IP address of the RADIUS server, the RADIUS Server Port (default is 1812) and the Shared Secret with the RADIUS server. Manual WEP key for RADIUS mode is no longer supported due to its weak security performance.
...)
ist mir aber alles zu unsicher!!! Möchte auf jedem Fall WPA2 Enterprise nutzen....bitte um Tipps dazu
mit den Realtek WLAN Tool bin ich nicht weiter gekommen und habe mich auf das Windows WLAN Tool konzentriert
hier die Screenshots dazu:
Konfiguration des WLAN Profils über die Windows Eigenschaften von Drahtlosnetze
...und Anpassung des Sicherheitsmodus im AP (RADIUS Modus steht laut Hilfemenü des APs für WEP:
RADIUS mode utilizes RADIUS server for authentication and dynamic WEP key generation for data encryption. To utilize RADIUS mode, enter the IP address of the RADIUS server, the RADIUS Server Port (default is 1812) and the Shared Secret with the RADIUS server. Manual WEP key for RADIUS mode is no longer supported due to its weak security performance.
...)
ist mir aber alles zu unsicher!!! Möchte auf jedem Fall WPA2 Enterprise nutzen....bitte um Tipps dazu
Na ja WEP darfst du natürlich auf dem Client auch nicht einstellen wenn der AP WPA-2 verlangt ! Logisch das dann nichts klappt.
Ausserdem ist der EAP Typ PEAP und nicht TLS auch das ist falsch bei dir. Damit schlägt dann auch die Authentisierung fehl. Hast du das Tutorial nicht gelesen ??
Lass den Radius doch einfach im Debug Modus laufen, dann siehst du all das was du falsch eingestellt hast doch schwarz auf weiss !!
Ausserdem ist der EAP Typ PEAP und nicht TLS auch das ist falsch bei dir. Damit schlägt dann auch die Authentisierung fehl. Hast du das Tutorial nicht gelesen ??
Lass den Radius doch einfach im Debug Modus laufen, dann siehst du all das was du falsch eingestellt hast doch schwarz auf weiss !!
ich habe doch zu keinem Zeitpunkt WEP und WPA2 gemischt:
entweder beide (AP und Client) auf WPA2 Enterprise (Beitrag vom 16.02) ...........................oder beide mit WEP (Beitrag vom 17.02)
entweder beide (AP und Client) auf WPA2 Enterprise (Beitrag vom 16.02) ...........................oder beide mit WEP (Beitrag vom 17.02)
das Konfigurationsproblem was ich habe liegen bei den Einstellungen für WPA2 802.1x auf der Client Seite.
abhängig vom gewählte EAP Typ, wird erwartet dass ich in den rechten Feldern "Benutzername" , "Identität", "Kennwort" etwas fest eintrage.....sind es die Windowsanmeldedaten die dann mit der Active Directory beim Anmeldeprozess verglichen werden?
abhängig vom gewählte EAP Typ, wird erwartet dass ich in den rechten Feldern "Benutzername" , "Identität", "Kennwort" etwas fest eintrage.....sind es die Windowsanmeldedaten die dann mit der Active Directory beim Anmeldeprozess verglichen werden?
Oben in deinen Screenshots steht aber ganz groß WEP !
Und auch beim EAP Type steht TLS statt PEAP odet oben ist eine Fata Morgana...
Und auch beim EAP Type steht TLS statt PEAP odet oben ist eine Fata Morgana...
hallo aqui,
bitte nicht verwechseln, es sind zwei getrennte Testszenarien gewesen:
einmal Versuch mit WPA2 Enterprise (Beitrag vom 16.02)
und
einmal Versuch mit WEP (Beitrag vom 17.02) , in der CISCO AP Konfiguration ist RADIUS als Sicherheitsmodus zu lesen, dass steht aber laut Hilfemenü des APs für dynamische WEP und NICHT für WPA2, wie man vermuten würde
bitte nicht verwechseln, es sind zwei getrennte Testszenarien gewesen:
einmal Versuch mit WPA2 Enterprise (Beitrag vom 16.02)
und
einmal Versuch mit WEP (Beitrag vom 17.02) , in der CISCO AP Konfiguration ist RADIUS als Sicherheitsmodus zu lesen, dass steht aber laut Hilfemenü des APs für dynamische WEP und NICHT für WPA2, wie man vermuten würde
so, und nun zu den Einstellungen mit der WPA2 Konfiguration:
ja, dort hatte ich es auf TLS eingestellt, wenn PEAP richtig sein soll gebe ich mich natürlich damit einverstanden
ich muss aber dazu meine Frage wiederholen: was trägt man in den rechten Feldern "Benutzername" , "Identität", "Kennwort" ?
ja, dort hatte ich es auf TLS eingestellt, wenn PEAP richtig sein soll gebe ich mich natürlich damit einverstanden
ich muss aber dazu meine Frage wiederholen: was trägt man in den rechten Feldern "Benutzername" , "Identität", "Kennwort" ?
Ja PEAP ist zwingend. Bei Usernamen trägst du den ein den du auf dem Radius vergeben hast !
